Аналитика - mongodb или кассандра - PullRequest
8 голосов
/ 06 марта 2011

Сегодня я пользуюсь mongodb, и я очень доволен этим. Мне нужно найти решение для журнала событий. Журнал включает в себя логины содержания и кликов (например, система рекламы). Это много пишет и мало читает (в основном для ежедневных отчетов). Кажется, что-то вроде Casandra - лучшее решение, чем Mongodb, что кажется лучше для документно-ориентированной структуры данных Какие-нибудь мысли ?

Ответы [ 4 ]

6 голосов
/ 07 марта 2011

Одной из приятных особенностей Cassandra является его поддержка Hadoop map / lower, которая дает ему доступ к очень надежной экосистеме (например, Pig) инструментов, примеров и т. Д.

В зависимости отобъем данных и сценарий использования, вы также можете воспользоваться функцией устаревших столбцов (http://www.datastax.com/dev/blog/whats-new-cassandra-07-expiring-columns).

Gemini также недавно открыла свой инструмент для обработки журналов Cassandra в реальном времени, который может быть аналогичен тому, что выхочу (http://www.thestreet.com/story/11030367/1/gemini-releases-real-time-log-processing-based-on-flume-and-cassandra.html, https://github.com/geminitech/logprocessing).

4 голосов
/ 06 марта 2011

Мы использовали mongodb в одном из проектов для записи журнала событий для распределенного приложения. Он работает очень хорошо, и имеет смысл заранее сделать некоторые расчеты относительно объема памяти, шардинга и других факторов.

В качестве рекомендации, используйте ограниченный сбор и выполняйте операцию mapreduce каждые 24 часа или около того, чтобы уменьшить количество журналов до сводной таблицы требуемых значений. Я заметил, что из-за отсутствия схем, документы в mongodb могут привести к очень быстрому увеличению размера файла базы данных.

1 голос
/ 20 апреля 2016

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

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

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

Что касается доступа к данным, они также совершенно разные. Cassandra предоставляет CQL (akka SQL), который не поддерживает объединение, группирование и т. Д. В отличие от Cassandra CQL, MongoDB использует JavaScript, Json, которыйиспользует собственную реализацию map / проводить для операций соединения.

Подводя итог, я думаю, вам следует учитывать все эти факты, когда вы выбираете одну из этих баз данных.С моей точки зрения, Cassandra хорошо подходит для вашей задачи, но вы должны хорошо подумать о модели и типах запросов, которые будут использоваться, прежде чем начинать работу с Cassandra

PS Я советую рассматривать движки SQL как Apache Drill дляMongoDb и PrestoDB для Cassandra для целей анализа

1 голос
/ 14 апреля 2011

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...