MongoDB для хранения разных (схемных) файлов журналов

Question

Считаете ли вы, что использование базы данных MongoDB Json для хранения файлов журнала из приложения - это хорошая идея и почему?

Единственное преимущество для меня - абстракция схемы, но я думаю, что это также слабость, которую мы не можем обеспечить целостностью файла журнала.

Answer 1

Очевидно, что я предвзят (я работаю на MongoDB), но я думаю, что это очень хорошо работает для журналов.

Причины:

• Это быстро для вставок и обновлений ... вы можете делать тысячи в секунду
• Как и обычные запросы, вы можете запускать аналитику и создавать отчеты, используя JavaScript. Вы могли бы иметь работу cron, работающую ночью MapReduce вещи в ваши журналы.
• Вы можете использовать ограниченные коллекции, которые являются коллекциями, которые действуют как очереди, чтобы хранить только последние N КБ / МБ / ГБ журналов

Я не уверен, что вы имеете в виду, что означает "обеспечить целостность файла журнала" ... Вы имеете в виду, что беспокоитесь о том, что не знаете, какие поля есть у документа, который вы извлекаете? Если это так, я думаю, вы обнаружите, что работать с пустыми полями в реляционной базе данных гораздо сложнее и гораздо более гибко.

См. Также: сообщение в блоге MongoDB о регистрации .

Answer 2

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

Возможно, вы захотите взглянуть на слайды из презентации о поведении приложений журналирования в MongoDB , которую я дал на Mongo SV и на последнем собрании MongoDB SF, для получения дополнительной информации о том, почему я так думаю хорошо подходит для ведения журнала, а также для получения информации о библиотеках для Java, Python, Ruby, PHP и C #, которые поддерживают ведение журнала в MongoDB.

Теперь я главный коммиттер в log4mongo-java, приложениях Log4J для MongoDB. Так что, наверное, не слишком удивительно, что это то, что я использую.

Что касается целостности журнала, я предполагаю, что вы имеете в виду уверенность в том, что он не был изменен после его записи. У вас есть один вариант, по крайней мере с log4mongo-java, - хранить события регистрации в базе данных, которая требует аутентификации. Это в некоторой степени ограничит число пользователей, которые могут добавлять, удалять или обновлять события.

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