Какую базу данных вы бы использовали для регистрации (т.е. замену logs-файла) - PullRequest
6 голосов
/ 25 ноября 2010

После анализа некоторых гигабайт лог-файлов с помощью grep и тому подобного, мне стало интересно, как сделать это проще, используя базу данных для входа в систему. Какая база данных будет подходящей для этой цели? Конечно, база данных SQL vanillia работает, но предоставляет множество транзакционных гарантий и т. Д., Которые вам здесь не нужны и которые могут замедлить работу, если вы работаете с гигабайтами данных и очень высокой скоростью вставки. Итак, база данных NoSQL, которая может быть правильным ответом (сравните этот ответ для некоторых предложений). Некоторые требования к базе данных будут:

  • Возможность справиться с гигабайтами или даже терабайтами данных
  • Быстрая вставка
  • Должно быть возможно несколько индексов для каждой записи (например, время, идентификатор сеанса, URL и т. Д.)
  • Если возможно, данные хранятся в сжатом виде, поскольку файлы журналов обычно чрезвычайно повторяющиеся.

Обновление: для этого уже есть несколько SO-вопросов: Предложение базы данных для обработки / составления отчетов по большому количеству данных типа файла журнала и Что такое хорошие решения для NoSQL и нереляционных баз данных для база данных аудита / ведения журнала . Однако мне любопытно, какие базы данных соответствуют каким требованиям.

Ответы [ 3 ]

5 голосов
/ 02 декабря 2010

После того, как я попробовал множество решений nosql, мои лучшие ставки будут:

  • riak + riak поиск отличной масштабируемости
  • ненормализованные данные в mysql / postgresql
  • mongoDB, если вы не против подождать
  • couchdb, если вы ЗНАЕТЕ, что ищете

Riak + Riak Search легко масштабируется (ДЕЙСТВИТЕЛЬНО!) И позволяет вам свободно обрабатывать ваши данные. Вы также можете легко смешивать схемы данных и, возможно, даже сжимать данные с помощью innostore в качестве бэкэнда.

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

mysql / postgresql по-прежнему довольно быстр и позволяет выполнять запросы произвольной формы благодаря обычным индексам дерева b +. Посмотрите на postgres частичные индексы , если некоторые поля не отображаются в каждой записи. Они также предлагают сжатые таблицы, и поскольку схема исправлена, вы не сохраняете имена строк снова и снова (это обычно происходит для большинства решений nosql)

CouchDB хороша, если вы уже знаете запросы, которые хотите видеть, их инкрементные карты / уменьшенные представления являются отличной системой для этого.

3 голосов
/ 25 ноября 2010

Есть много разных вариантов, которые вы можете посмотреть. Вы можете использовать Hive для аналитики и Flume для использования и загрузки файлов журнала. MongoDB также может быть хорошим вариантом для вас, взгляните на эту статью о аналитике журналов с MongoDB, Ruby и Google Charts

1 голос
/ 25 ноября 2010

В зависимости от ваших потребностей Splunk может быть хорошим вариантом.Это больше, чем просто база данных, но вы получаете все виды отчетов.Кроме того, он предназначен для замены файла журнала, поэтому они уже решили проблемы с масштабированием.

...