Как я должен сохранить чрезвычайно большие объемы транспортных данных для легкого извлечения?
для транспортной системы учета я должен сохранить большой объем наборов данных об интернет-пакетах, отправленных через наш маршрутизатор шлюза (содержащий метку времени, идентификатор пользователя, место назначения или исходный IP, число байтов, и т.д.).
Эти данные должны храниться в течение некоторого времени, по крайней мере несколько дней. Легкое извлечение должно быть возможным также.
Что хороший путь состоит в том, чтобы сделать это? У меня уже есть некоторые идеи:
Создайте файл для каждого пользователя и день и добавьте каждый набор данных к нему.
- Преимущество: это, вероятно, очень быстро, и данные легко найти, учитывая последовательное расположение файла.
- Недостаток: не легко возможно видеть, например, весь трафик UDP всех пользователей.
Используйте базу данных
- Преимущество: очень легко найти определенные данные с правильным SQL-запросом.
- Недостаток: я не уверен, существует ли механизм базы данных, который может эффективно обработать таблицу с возможно сотнями миллионов наборов данных.
Возможно, возможно объединить два подхода: Используя файл базы данных SQLite для каждого пользователя.
- Преимущество: было бы легко получить информацию для одного пользователя, использующего SQL-запросы на его файле.
- Недостаток: Получение полной информации все еще было бы трудным.
Но возможно у кого-то еще есть очень хорошая идея?
Заранее большое спасибо.
3 ответа
Прежде чем что-либо делать, получите The Data Warehouse Toolkit .
Вы выполняете работу по хранению данных, вам нужно заниматься ею как с работой по хранению данных. Вам нужно будет узнать о правильных шаблонах проектирования для такого рода вещей.
[Обратите внимание, что хранилище данных не означает безумно большой, дорогой или сложный. Это означает звездообразную схему и умные способы обработки больших объемов данных, которые никогда не обновляются.]
Базы данных SQL медленные, но это хорошо для гибкого поиска.
Файловая система работает быстро. Ужасно обновлять, но вы не обновляетесь, вы просто накапливаете.
Типичный подход DW для этого - сделать это.
Определите «звездообразную схему» для своих данных. Измеримые факты и атрибуты («измерения») этих фактов. Ваш факт составляет # байтов. Все остальное (адрес, временная метка, идентификатор пользователя и т. Д.) Является измерением этого факта.
Создайте размерные данные в основной базе данных измерений. Он относительно небольшой (IP-адреса, пользователи, измерение даты и т. Д.). Каждое измерение будет иметь все атрибуты, которые вы, возможно, захотите узнать. Это растет, люди всегда добавляют атрибуты к размерам.
Создайте процесс «загрузки», который берет ваши журналы, разрешает измерения (время, адреса, пользователи и т. Д.) И объединяет ключи измерений с мерами (количество байтов). Это может обновить размер, чтобы добавить нового пользователя или новый адрес. Как правило, вы читаете строки фактов, выполняете поиск и записываете строки фактов, с которыми связаны все соответствующие FK.
Сохраните эти загрузочные файлы на диск. Эти файлы не обновляются.Они просто накапливаются. Используйте простые обозначения, например CSV, чтобы их можно было легко загрузить массово.
Если кто-то хочет провести анализ, создайте для него информационную витрину.
Для выбранного IP-адреса или временного интервала или чего-то еще, получите все соответствующие факты, а также связанные данные основного измерения и выполните массовую загрузку витрины данных.
Вы можете выполнять любые SQL-запросы на этом киоске. Большинство запросов перейдут к SELECT COUNT (*) и SELECT SUM (*) с различными GROUP BY и HAVING и WHERE пункты.
Итак, вы попали в один из случаев, когда у вас намного операций записи намного больше, чем чтения, вы хотите, чтобы ваши записи не блокировали вас, и вы хотите, чтобы ваши чтения были «достаточно быстрыми», но не критичными. . Это типичный вариант использования бизнес-аналитики.
Вероятно, вам следует использовать базу данных и хранить данные в виде «денормализованной» схемы, чтобы избежать сложных объединений и множественных вставок для каждой записи. Думайте о своей таблице как об огромном файле журнала.
В этом случае некоторые из «новых и модных» баз данных NoSQL, вероятно, именно то, что вам нужно: они обеспечивают смягченные ограничения ACID, о которых вам не следует особо беспокоиться (в случае сбоя вы можете потерять последние строки вашего журнала), но они работают намного лучше для вставки, потому что им не нужно синхронизировать журналы на диске при каждой транзакции.
Я думаю, что правильный ответ действительно зависит от определения "набора данных". Как вы упомянули в своем вопросе, вы сохраняете отдельные наборы информации для каждой записи; отметка времени, идентификатор пользователя, IP-адрес назначения, IP-адрес источника, количество байтов и т. д.
SQL Server прекрасно справляется с хранением данных такого типа с сотнями миллионов записей без каких-либо серьезных затруднений. Конечно, для этого типа ведения журнала потребуется хорошее оборудование, но оно не должно быть слишком сложным.
Любое другое решение, на мой взгляд, очень усложнит составление отчетов, и, судя по всему, это важное требование.