Хранение и анализ журналов выбора базы данных - PullRequest
Новая
       5

Хранение и анализ журналов выбора базы данных

3 голосов
/ 26 декабря 2011

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

Я хотел бы знать, какую базу данных выбрать, которая позволит и быстро выполнить ряд ключевых задач:

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

И любая другая помощь также будет принята с благодарностью. Код включен.

Ответы [ 2 ]

2 голосов
/ 26 декабря 2011

По моим наблюдениям, MongoDB работает в несколько раз лучше, чем RDBS, для задачи, которую вы описываете - огромное хранилище журналов.Особенно хорошими исполнителями являются закрытые коллекции.Основное отставание в производительности с RDBS, которое я видел, - это время вставки.Огромным недостатком RDBS является схема, которая является основной проблемой для обновления при необходимости.По этим причинам мы начали двигаться в сторону MongoDB - посмотрите logFaces .Если вы создаете свой собственный инструмент для сообщества открытого исходного кода - постарайтесь убедиться, что он будет работать с ЛЮБОЙ базой данных, а не только с конкретным брендом.Но тогда это становится не такой тривиальной задачей:)

(для раскрытия информации - я - первоначальный автор logFaces, поэтому мнение может быть предвзятым)

1 голос
/ 26 декабря 2011

Хранение только событий звучит как простая модель, так что вы можете взглянуть на NoSQL базы данных. Я думаю, что хранилища ключей / больших таблиц для действительно больших объемов данных в этом случае будут лучше, чем базы данных на основе документов.

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

...