Какая база данных достаточно хороша для регистрации приложения? - PullRequest
5 голосов
/ 08 октября 2011

Я пишу веб-приложение с nodeJS, которое может использоваться другими приложениями для хранения журналов и последующего доступа в веб-интерфейсе или самими приложениями, предоставляющими API. Похож на Graylog2 , но схема свободна.

Я уже пробовал couchDB, в которой каждый документ был бы документом журнала, но так как я на самом деле не использую ревизии, мне кажется, я не использую все его функции. И кроме того, я думаю, что если журналы превышают лимит, в couchDB будет довольно сложно управлять.

Что я действительно ищу, так это большой массив журналов, которые можно сортировать, фильтровать, искать и накладывать на них. Затем последние события этого доступны. Он должен быть свободен от схемы, и запись в него должна быть неблокирующей.

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

Я уже видел этот вопрос, но не удовлетворен ответами.

Edit: По некоторым причинам я не могу использовать Cassandra в производстве, сейчас я пробую MongoDB.

Еще одна причина использовать mongoDB: http://www.slideshare.net/WombatNation/logging-app-behavior-to-mongo-db

Больше правок:

Это похоже на graylog2, но я хочу сделать различие, вместо того, чтобы иметь поле сообщения, иметь поля, определенные клиентом, поэтому я хочу, чтобы оно было свободным от схемы, и из-за этого мне может понадобиться запрашивать в пользовательских полях. Мы можем построить его на SQL, но запрос к пользовательским полям будет заново изобретать колесо. То же самое относится и к файлам.

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

Ответы [ 3 ]

3 голосов
/ 04 апреля 2012

Где это будет храниться и как его искать?

Я думаю, это зависит от того, с каким количеством данных вы имеете дело.Если у вас есть огромное количество журналов (терабайт и петабайт в день), то Apache Kafka, который предназначен для одновременной обработки данных HDFS, является интересным решением - все еще на стадии инкубации.Я полагаю, что если вы хотите использовать сообщения Kafka с MongoDb, вам нужно разработать собственный адаптер, чтобы использовать его как потребителя определенной темы Kafka.Хотя данные MongoDb (например, осколки и реплики) распространяются, это может быть последовательный процесс приема каждого сообщения.Таким образом, могут быть узкие места или даже условия гонки в зависимости от скорости и объема трафика сообщений.Kafka оптимизирован для прокачки и добавления этих данных к узлам HDFS с использованием брокеров сообщений FAST.Затем, попав в HDFS, вы можете отображать / сокращать для анализа вашей информации различными способами.

Если MongoDb может справиться с нагрузкой при приеме внутрь, то это отличное масштабируемое решение для поиска в реальном времени информации, особенно документов.В противном случае, если у вас есть больше времени для обработки данных (т. Е. Пакетных процессов, которые занимают часы, а иногда и дни), тогда Hadoop или какая-либо другая база данных Map Reduce гарантирована.Наконец, Kafka может распространять эту массу сообщений и подключать этот пожарный шланг к различным потребителям.В целом, эти новые технологии распределяют нагрузку и огромные объемы данных по дешевому оборудованию, используя программное обеспечение для управления сбоями и восстановления с очень низкой вероятностью потери данных.

Даже при небольшом объеме данных MongoDb является хорошимвозможность традиционных решений для реляционных баз данных, которые требуют больше ресурсов разработчика для проектирования, создания и обслуживания.

2 голосов
/ 09 октября 2011

Рассматривали ли вы Apache Kafka ?

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

2 голосов
/ 08 октября 2011

Общий подход

У вас впереди много работы. Какую бы базу данных вы не использовали, у вас есть много возможностей, которые вы должны построить поверх основы БД. Вы сделали хорошее исследование обо всех ваших вариантах. Похоже, вы подозреваете, что у всех есть свои плюсы и минусы, но все они несовершенны. Ваше подозрение верно. На этом этапе, вероятно, пришло время начать писать код.

Вы можете просто выбрать один из них и начать создавать приложение. Если ваше предположение было верным, что плюсы и минусы уравновешены и все примерно одинаково, то почему бы просто не начать строительство немедленно? Когда вы сталкиваетесь с трудностью X в своей базе данных, помните, что это дало вам удобство Y и Z, и это просто жизнь.

Вы также можете установить фундаментальное ядро ​​ вашего приложения и внедрить различные прототипы в каждую из баз данных. Это может дать вам истинное понимание, чтобы помочь различать базы данных для вашего конкретного приложения. Например, помимо интерфейса, вопросов индексации и запросов, как насчет развертывания? Как насчет резервного копирования? Как насчет обслуживания и безопасности? Возможно, «потеря» времени на создание одного и того же прототипа на каждой платформе сделает ответ для вас очень ясным.

Заметки о CouchDB

Полагаю, CouchDB - это "NoSQL", если вы так говорите. Другие вещи, которые "не SQL" включают бананы, стихи и крикет. Это не очень значимое слово. У нас есть языки общего назначения и предметно-ориентированные языки; аналогично CouchDB является доменной базой данных . Это может сэкономить ваше время, если вам нужны следующие функции:

  • Встроенный веб-API: клиенты могут запрашивать напрямую
  • Инкрементное уменьшение карты: CouchDB запускает задание один раз, но вы можете запрашивать его повторно бесплатно. Обновления набора данных немедленно отражаются на карте / сокращают результат без полной повторной обработки
  • Легко начать с малого, но расширить до больших кластеров без изменения кода приложения.
...