Как мне хранить очень большие объемы данных о трафике, чтобы их можно было легко найти?

Question

для системы учета трафика мне нужно хранить большие объемы наборов данных об интернет-пакетах, отправленных через наш шлюз-маршрутизатор (содержащие метку времени, идентификатор пользователя, IP-адрес назначения или источника, количество байтов и т. д.).

Эти данные необходимо хранить некоторое время, по крайней мере, несколько дней.Также должен быть возможен простой поиск.

Каков хороший способ сделать это?У меня уже есть некоторые идеи:

• Создайте файл для каждого пользователя и дня и добавьте в него каждый набор данных.

  • Преимущество:Вероятно, это очень быстро, и данные легко найти при наличии единообразного макета файла.
  • Недостаток:Нелегко увидеть, например.весь UDP-трафик всех пользователей.

• Используйте базу данных

  • Преимущество:Очень легко найти конкретные данные с помощью правильного SQL-запроса.
  • Недостаток:Я не уверен, существует ли механизм базы данных, который может эффективно обрабатывать таблицы, возможно, с сотнями миллионов наборов данных.

• Возможно, можно объединить два подхода:Использование файла базы данных SQLite для каждого пользователя.

  • Преимущество:Было бы легко получить информацию об одном пользователе, используя SQL-запросы к его файлу.
  • Недостаток:Получить общую информацию по-прежнему будет сложно.

Но, возможно, у кого-то еще есть очень хорошая идея?

Большое спасибо заранее.

Answer 1

Сначала получите Инструментарий хранилища данных прежде чем что-либо сделать.

Вы выполняете работу по хранению данных, и вам нужно относиться к ней как к работе по хранению данных.Вам нужно будет прочитать о правильных шаблонах проектирования для такого рода вещей.

[Обратите внимание, что хранилище данных не означает безумно большое, дорогое или сложное.Это означает звездообразную схему и разумные способы обработки больших объемов данных, которые никогда не обновляются.]

1. Базы данных SQL работают медленно, но эта медленность хороша для гибкого поиска.

2. Файловая система быстрая.Это ужасная штука для обновления, но вы не обновляетесь, а просто накапливаете.

Типичный подход DW заключается в следующем.

1. Определите «звездную схему» для ваших данных.Измеримые факты и атрибуты («размеры») этих фактов.Ваш факт выглядит как # байт.Все остальное (адрес, временная метка, идентификатор пользователя и т. д.) является измерением этого факта.

2. Создайте данные измерений в главной базе данных измерений.Оно относительно небольшое (IP-адреса, пользователи, измерение даты и т. д.). Каждое измерение будет иметь все атрибуты, которые вы, возможно, захотите узнать.Это растет, люди постоянно добавляют атрибуты к измерениям.

3. Создайте процесс «загрузки», который берет ваши журналы, определяет измерения (время, адреса, пользователи и т. д.) и объединяет ключи измерений с измерениями (количество байтов).Это может привести к обновлению измерения для добавления нового пользователя или нового адреса.Обычно вы читаете строки фактов, выполняете поиск и записываете строки фактов, которые имеют все соответствующие FK, связанные с ними.

4. Сохраните эти загрузочные файлы на диске.Эти файлы не обновляются.Они просто накапливаются.Используйте простую запись, например CSV, чтобы можно было легко загружать их.

Если кто-то хочет провести анализ, создайте для него витрину данных.

Для выбранного IP-адреса, временного интервала или чего-то еще получите все соответствующие факты, а также связанные данные основного измерения и массовую загрузку витрины данных.

На этом рынке вы можете выполнять любые SQL-запросы, которые захотите.Большая часть запросов перейдет к SELECT COUNT(*) и SELECT SUM(*) с различными GROUP BY и HAVING и WHERE статьи.

Answer 2

Я думаю, что правильный ответ действительно зависит от определения «набора данных».Как вы упомянули в своем вопросе, вы храните отдельные наборы информации для каждой записи;временная метка, идентификатор пользователя, IP-адрес назначения, IP-адрес источника, количество байтов и т. д.

SQL Server прекрасно способен без каких-либо особых трудностей обрабатывать этот тип хранилища данных с сотнями миллионов записей.Конечно, для этого типа ведения журнала потребуется хорошее оборудование, но оно не должно быть слишком сложным.

Любое другое решение, на мой взгляд, очень усложнит отчетность, и, судя по всему, это важное требование.

Answer 3

Итак, вы находитесь в одном из случаев, когда у вас есть много больше активности записи, чем чтения, вы хотите, чтобы ваши записи не блокировали вас, и вы хотите, чтобы ваши чтения были «достаточно быстрыми», но не критическими.Это типичный вариант использования бизнес-аналитики.

Вероятно, вам следует использовать базу данных и хранить свои данные в виде «денормализованной» схемы, чтобы избежать сложных объединений и множественных вставок для каждой записи.Думайте о своей таблице как об огромном файле журнала.

В этом случае некоторые из «новых и модных» баз данных NoSQL, вероятно, являются тем, что вы ищете:они предоставляют смягченные ограничения ACID, о которых здесь не следует сильно возражать (в случае сбоя вы можете потерять последние строки вашего журнала), но они работают намного лучше при вставке, поскольку им не нужно синхронизировать журналы на диске в каждая транзакция.