Есть ли у вас опыт работы с базами данных NoSQL для масштабируемых приложений? Я провел некоторое исследование по базам данных NoSQL для регистрации и обнаружил, что MongoDB, по-видимому, является хорошим выбором. Кроме того, я нашел log4mongo-net, который, кажется, очень простой вариант.Какую базу данных NoSQL следует использовать для ведения журнала?
Вы бы рекомендовали такой подход? Есть ли другие предложения?
Я решил пересмотреть этот принятый ответ, поскольку состояние искусства значительно изменилось за последние 18 месяцев, и существуют гораздо лучшие альтернативы.
Новый ответ
MongoDB является подпаритет выбор для масштабируемого решения протоколирования. Для этого есть обычные причины (например, производительность записи под нагрузкой). Я хотел бы предложить еще один вариант, который заключается только в том, что он разрешает только один вариант использования в решении для регистрации.
Сильное решение протоколирования должен охватывать по крайней мере, следующие этапы:
MongoDB как выбор только разрешает использование Хранения (хотя и немного плохо). После анализа всей цепочки есть более подходящие решения.
@ KazukiOhta упоминает несколько вариантов. Я предпочитаю конец конечного раствора в эти дни включает в себя:
T он в основе использования ElasticSearch для хранения данных журнала использует текущее лучшее решение NoSQL для породы для ведения журнала и поиска. Тот факт, что Logstash-Forwarder/Logstash/ElasticSearch/Kibana3 находится под зонтиком ElasticSearch, делает еще более убедительный аргумент.
Поскольку Logstash также может выступать в качестве прокси-сервера Graphite, очень сложная цепочка может быть создана для связанной задачи сбора и анализа показателей (а не только журналов).
Старый Ответ
MongoDB Capped Collections чрезвычайно популярны и suitable for logging, с дополнительным бонусом быть «схемы меньше», которая, как правило, семантический, пригодный для лесозаготовок. Часто мы знаем только то, что мы хотим хорошо записывать в проект, или после того, как определенные проблемы были обнаружены в процессе производства. Реляционные базы данных или строгие схемы, как правило, трудно изменить в этих случаях, и попытки сделать их «гибкими» имеют тенденцию просто делать их «медленными» и трудными в использовании или понимании.
Но если вы хотите manage your logs in the dark and have lasers going and make it look like you're from space всегда есть Graylog2, который использует MongoDB в рамках общей инфраструктуры, но обеспечивает намного больше на вершине, такие как общий, расширяемый формат, выделенный сервер сбора журнала, распределенная архитектуру и фанки UI.
Необходимо указать, какие сообщения в журналах создаются вашим приложением. Если вы только регистрируете партии и множество простых сообщений журнала, MongoDB - очень хороший выбор, поскольку он масштабируется так хорошо. Но если вам нужен сложный материал аутентификации или много иерархии, я бы использовал традиционные rdbms.
Я видел, что многие компании используют MongoDB для хранения журналов приложений. Его привязка к схеме очень гибкая для журналов приложений, при которых схема имеет тенденцию меняться время от времени. Кроме того, его функция Capped Collection действительно полезна, поскольку она автоматически очищает старые данные, чтобы данные вставлялись в память.
Люди собирают журналы с помощью обычной группировки или MapReduce, но это не так быстро. В частности, MapReduce MongoDB работает только в одном потоке, и его накладные расходы на JavaScript огромны. New aggregation framework может решить эту проблему.
Когда вы используете MongoDB для регистрации, проблема заключается в том, что блокирует конкуренцию высокой пропускной способностью записи. Хотя по умолчанию вкладка MongoDB имеет стиль «огонь-и-забыть», вызов большого количества вставки() вызывает тяжелую реакцию блокировки записи. Это может повлиять на производительность приложения и не позволяет читателям собирать/фильтровать сохраненные журналы.
Одним из решений может быть с использованием структуры коллектора журнала, такие как Fluentd, Logstash или Flume. Предполагается, что эти демоны запускаются на каждом узле приложения и берут журналы из процессов приложений.
Они буфера журналов и асинхронно записывает данные в другие системы, такие как MongoDB/PostgreSQL/и т.д. запись производится партиями, так что это намного эффективнее, чем писать непосредственно из Программы. Эта ссылка описывает, как помещать журналы в Fluentd из программы PHP.
Вот некоторые учебники о MongoDB + Fluentd.
проблема MongoDB является он начинает замедление, когда объем данных превышает размер памяти. В этот момент вы можете переключиться на другие решения, такие как Apache Hadoop или Cassandra.Если у вас есть распределенный уровень журналирования, упомянутый выше, вы можете мгновенно переключиться на другое решение по мере роста. В этом руководстве описывается, как хранить журналы в HDFS с помощью Fluentd.
Graylog2, удивительным. Спасибо за совет! – ikrain
Как предупреждение, мы столкнулись с серьезными проблемами с MongoDB при написании более нескольких тысяч событий в секунду для регистрации коллекций. Недостатком письменной работы MongoDB может быть преступник. –
О Graylog2, пожалуйста, примите к сведению: «Все работает на существующей JVM в вашем центре обработки данных». Если вы пропустите это, вы ничего не увидите, пока не увидите в третьем или четвертом параграфе инструкции по установке пакета загрузки («Вы также должны использовать Java 7!»). Я всегда думаю, что забавно, как проекты на Java просто забывают упомянуть, что они являются проектами на основе Java при их продаже. Просто ИМО. – L0j1k