Вопрос по .net, mongodb – Какую базу данных NoSQL я должен использовать для регистрации?

41

Есть ли у вас опыт входа в базы данных NoSQL для масштабируемых приложений? Я провел некоторое исследование баз данных NoSQL для регистрации и обнаружил, что MongoDB, кажется, является хорошим выбором. Кроме того, я нашелlog4mongo-сеть что кажется очень простым вариантом.

Вы бы порекомендовали такой подход? Есть ли другие предложения?

Ваш Ответ

3   ответа
53

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

New Answer

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

Надежное решение для ведения журнала должно охватывать как минимум следующие этапы:

  • Collection
  • Transport
  • Processing
  • Storage
  • Search
  • Visualisation

MongoDB как выбор только решает вариант использования хранилища (хотя и несколько плохо). После анализа всей цепочки появляются более подходящие решения.

@KazukiOhta упоминает несколько вариантов. Мое предпочтительное сквозное решение в эти дни включает в себя:

Базовое использование ElasticSearch для хранения данных журналов использует лучшее на сегодняшний день решение NoSQL для случая использования журналирования и поиска. Тот факт, что Logstash-Forwarder / Logstash / ElasticSearch / Kibana3 находятся под эгидойElasticSearch делает для еще более убедительного аргумента.

Поскольку Logstash также может выступать в качестве прокси-сервера Graphite, очень похожая цепочка может быть построена для связанной проблемы сбора и анализа метрик (а не только логов).

Old Answer

MongoDBЗакрытые Коллекции чрезвычайно популярны иподходит для регистрациис дополнительным бонусом «меньше схемы», что обычно является семантической пригодностью для ведения журнала. Зачастую мы знаем только то, что хотим хорошо войти в проект или после того, как были обнаружены определенные проблемы в производстве. Реляционные базы данных или строгие схемы, как правило, трудно изменить в этих случаях, и они пытаются сделать их «гибкими». имеет тенденцию просто делать их "медленными" и трудно использовать или понять.

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

Error: User Rate Limit Exceeded
Error: User Rate Limit ExceededrawError: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded ikrain
Error: User Rate Limit Exceeded
0

какие журнальные сообщения генерирует ваше приложение. Если вы регистрируете только большое количество простых сообщений журнала, MongoDB - очень хороший выбор, поскольку он так хорошо масштабируется. Но если вам нужны сложные средства аутентификации или много иерархии, я бы использовал традиционные rdbms.

18

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

Люди агрегируют журналы с помощью обычной группировки или MapReduce, но это не так быстро. В частности, MapReduce MongoDB работает только в пределах одного потока, и его накладные расходы на выполнение JavaScript огромны.Новая структура агрегации мог решить эту проблему.

Когда вы используете MongoDB для ведения журнала, проблема заключается вlock contention по высокой производительности записи. Хотя вставка MongoDB по умолчанию работает по принципу «забей и забывай», вызов большого количества функций insert () приводит к серьезному конфликту блокировки записи. Это может повлиять на производительность приложения и помешать читателям объединять / фильтровать сохраненные журналы.

Одним из решений может быть использованиеlog collector framework такие какFluentd, Logstash, или жеакведук, Предполагается, что эти демоны запускаются на всех узлах приложения и получают журналы от процессов приложения.

Fluentd plus MongoDB

Они буферизируют логи иasynchronously записывает данные в другие системы, такие как MongoDB / PostgreSQL / и т. д. Запись выполняетсяbatchesтак что это намного эффективнее, чем писать прямо из приложений. Эта ссылка описывает, как поместить логи в программу Fluentd из PHP.

Fluentd: Data Import from PHP Applications

Вот несколько учебных пособий о MongoDB + Fluentd.

Fluentd + MongoDB: The Easiest Way to Log Your Data Effectively on 10gen blog Fluentd: Store Apache Logs into MongoDB

Проблема MongoDB заключается в том, что он начинает замедляться, когда объем данных превышает объем памяти. На этом этапе вы можете переключиться на другие решения, такие какApache Hadoop или жеCassandra, Если у вас есть распределенный уровень ведения журнала, упомянутый выше, вы можете мгновенно переключиться на другое решение по мере роста. В этом руководстве описывается, как сохранять журналы в HDFS с помощью Fluentd.

Fluentd: Fluentd + HDFS: Instant Big Data Collection

Похожие вопросы