Как хранить чрезвычайно большие объемы данных о трафике для удобного поиска?

Question

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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

Типичный подход DW для этого состоит в том, чтобы сделать это.

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

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

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

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

Когда кто-то хочет провести анализ, создайте им datamart.

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

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

Answer 2

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

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

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

Answer 3

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

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

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