MongoDB против Cassandra

Я оцениваю, какой вариант миграции может быть лучшим.

В настоящее время я использую сегментированный MySQL (горизонтальный раздел), и большая часть моих данных хранится в больших двоичных объектах JSON. У меня нет сложных SQL-запросов (уже перенесенных после того, как я разбил свой БД).

Прямо сейчас кажется, что и MongoDB, и Cassandra были бы вероятными вариантами. Моя ситуация:

  • Много чтений в каждом запросе, меньше регулярных записей
  • Не беспокоит "массовая" масштабируемость
  • Больше заботятся о простой настройке, обслуживании и коде
  • Свести к минимуму стоимость оборудования / сервера

person ming yeow    schedule 23.05.2010    source источник
comment
Доступна официальная статистика тестов производительности. Cassandra против MongoDB против HBase   -  person Ravi    schedule 11.11.2014
comment
›Много чтений в каждом запросе, меньше регулярных записей =› Ищите CQRS (отделите свои чтения от записей, возможно, без использования источников событий, но проверьте, можете ли вы обновить асинхронную модель чтения .. синхронизация также может работать .. это зависит от вашего использования -случаи)   -  person bodrin    schedule 14.10.2015
comment
На самом деле это отличный вопрос. Интересно, есть ли его обновленная версия? Этот сейчас очень старый   -  person slashdottir    schedule 01.08.2018


Ответы (6)


Много чтений в каждом запросе, меньше обычных записей

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

Механизм хранения Cassandra обеспечивает запись в постоянное время независимо от того, насколько велик ваш набор данных. Запись более проблематична в MongoDB, отчасти из-за механизма хранения на основе b-дерева, но больше из-за блокировка с несколькими уровнями детализации.

Для аналитики MongoDB предоставляет настраиваемую реализацию map / reduce; Cassandra обеспечивает встроенную поддержку Hadoop, в том числе для Hive (хранилище данных SQL, построенное на Hadoop map / reduce) и Pig (специфичный для Hadoop язык анализа, который, по мнению многих, лучше подходит для отображения / сокращения рабочих нагрузок, чем SQL). Cassandra также поддерживает использование Spark.

Не беспокойтесь о "массовой" масштабируемости

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

Больше заботьтесь о простой настройке, обслуживании и коде

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

Если в настоящее время вы используете большие двоичные объекты JSON, MongoDB безумно хорошо подходит для вашего варианта использования, учитывая, что он использует BSON для хранения данных. Вы сможете иметь более богатые и запрашиваемые данные, чем в вашей нынешней базе данных. Это была бы самая значительная победа для Монго.

person Michael    schedule 24.05.2010
comment
Что вы подразумеваете под соответствующими доменами - считаете ли вы их отдельными типами? спасибо за отличные ответы! - person ming yeow; 24.05.2010
comment
Совсем другое, комментарий недостаточно велик, но ... Cassandra - это линейно масштабируемый (амортизируемое постоянное время чтения и записи) гибрид Dynamo / Google Bigtable, который обеспечивает быструю запись независимо от размера данных. Его набор функций минималистичен, немного больше, чем у упорядоченного хранилища значений ключей. MongoDB - это многофункциональное (и быстрое) хранилище документов за счет надежности и гарантии сохранения записи (поскольку они не сразу записываются на диск). Это разные звери с разной философией, MongoDB ближе к замене RDMS ... - person Michael; 25.05.2010
comment
в то время как Cassandra находится на более низком уровне, но позволяет убер-масштабирование (см. Twitter / Digg / Facebook), но вам придется осознанно подходить к размещению данных, построению вторичных индексов и т. д., поскольку гибкие запросы не допускаются. - person Michael; 25.05.2010
comment
Cassandra, вы получите аналогичную производительность чтения, если установка не использует несколько узлов в кластере, просто наличие 3 узлов с коэффициентом репликации 3 даст вам аналогичную производительность, поскольку все узлы имеют все данные. поэтому коэффициент производительности нельзя сравнивать с mongodb, например, от яблока до яблока - person mamu; 12.09.2010
comment
Поскольку все упомянули здесь твиттер в связи с Cassandra: они не используют Cassandra для сохранения твитов, они все еще используют MySQL здесь (engineering.twitter.com/2010/07/cassandra-at-twitter-today.html). Хорошо, но я могу представить, что они все еще хранят много данных для других целей в Кассандре. - person H6.; 13.01.2012
comment
Для тех, кто хочет хранить JSON в больших двоичных объектах, но также хочет масштабов Cassandra, проекта usergrid (github.com/usergrid / stack) - это хранилище JSON, расположенное на Cassandra. Каждое поле неявно индексируется, как и в MongoDB. Все с открытым исходным кодом. Вы можете разместить это самостоятельно; в качестве альтернативы Apigee предоставляет бесплатную услугу. Недавно apigee опубликовал демонстрационный проект, который позволяет клиентам mongodb сохранять данные в usergrid без изменений. (эмуляция протокола на уровне проводов) - person Cheeso; 16.09.2012
comment
Похоже, глобальная блокировка записи могла быть удалена в Mongo 2.2 ... - person Matt Farmer; 18.10.2012
comment
Стоит отметить, что вы не можете использовать более одного индекса при выполнении запроса в MongoDB. Еще не уверен насчет Кассандры. - person Vladimir Prudnikov; 28.10.2012
comment
@MattF, но блокировка на уровне базы данных, на мой взгляд, не намного лучше. Я не могу этого понять .. только эмоции. - person OZ_; 07.01.2013
comment
Какой ваш комментарий об использовании mongodb для использования в приложении для чтения RSS? - person ; 11.04.2013
comment
MongoDB 2.2.x имеет блокировку уровня базы данных. Но в 2.6.x они изменили архитектуру, и в следующих выпусках будет поддерживаться блокировка на уровне коллекции. - person minhas23; 05.06.2014
comment
Еще до того, как мой проект был запущен, я чувствую болевые точки Mongodb. Горячее резервное копирование - основное требование. Чтобы выполнить горячее резервное копирование на сервере Linux, вам необходимо сначала настроить раздел LVM (не так часто) и делать снимок перед каждым сеансом резервного копирования. Еще один простой способ - использовать платную службу резервного копирования Mongodb. Но эта услуга стоит дорого (2,3 доллара за ГБ в месяц). Скоро вам понадобится набор реплик для отказоустойчивости. В версии с открытым исходным кодом узлы могут обмениваться данными только в виде открытого текста. Для SSL вам нужно использовать версию Entprise. А это 10 000 $. Прощай, Mongodb. Рефакторинг моего кода для Cassandra. - person Karthik Sankar; 02.10.2014
comment
Теперь в движке Wired Tiger MongoDB нет глобальной блокировки записи. - person Evgeni Nabokov; 04.11.2015
comment
Начиная с MongoDB 3.2, по умолчанию используется механизм хранения Wired Tiger, который использует параллелизм на уровне документа для записи (MMAPv2 использует параллелизм на уровне коллекции) - person thomas legrand; 06.01.2016

Я активно использовал MongoDB (последние 6 месяцев), создавая иерархическую систему управления данными, и могу поручиться как за простоту настройки (установить, запустить, использовать!), Так и за скорость. Если вы внимательно подумаете об индексах, он будет просто кричать, если говорить о скорости.

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

Настоящим свингером для меня, когда мы оценивали базы данных NoSQL, были запросы - Cassandra в основном представляет собой гигантское хранилище ключей / значений, а запросы немного неудобны (по крайней мере, по сравнению с MongoDB), поэтому для производительности вам придется дублировать довольно много данных как своего рода ручной указатель. MongoDB, с другой стороны, использует модель «запрос по примеру».

Например, предположим, что у вас есть Коллекция (на языке MongoDB для эквивалента таблицы RDMS), содержащая пользователей. MongoDB хранит записи как документы, которые в основном представляют собой двоичные объекты JSON. например:

{
   FirstName: "John",
   LastName: "Smith",
   Email: "[email protected]",
   Groups: ["Admin", "User", "SuperUser"]
}

Если вы хотите найти всех пользователей по имени Смит, у которых есть права администратора, вам просто нужно создать новый документ (в консоли администратора с помощью Javascript или в рабочей среде с использованием языка по вашему выбору):

{
   LastName: "Smith",
   Groups: "Admin"
}

... а затем запустите запрос. Вот и все. Добавлены операторы для сравнения, фильтрации RegEx и т. Д., Но все это довольно просто, и документация на основе Wiki довольно хороша.

person Richard K.    schedule 01.07.2010
comment
Обновление (8 августа 2011 г.): В центре обработки данных Amazon EC2 в Ирландии вчера вечером произошел инцидент, связанный с молнией, и, разбираясь с восстановлением нашего сервера, я обнаружил один очень важный момент: если у вас есть набор репликации из двух серверов (а они их легко настроить), убедитесь, что у вас есть узел Arbiter, поэтому, если один из них выйдет из строя, другой не паникует и не останавливается в дополнительном режиме! Поверьте, разобраться с большой базой данных - это настоящая головная боль. - person Richard K.; 09.08.2011
comment
Чтобы добавить то, что сказал @Richard K, у вас должен быть узел-арбитр, когда у вас четное количество узлов (первичный + вторичный) в наборе реплик. - person Amareswar; 04.02.2013
comment
К тому же рассмотрите mongodb, когда необходимо выполнить дополнительную агрегацию для анализа данных. - person user1503117; 01.10.2015
comment
As long as you think about indexes carefully, it can absolutely scream along, speed-wise. Подождите, пока ваша физическая память не заполнится, и ОС начнет сбой страницы lol - person sturcotte06; 21.07.2019

Почему стоит выбирать между традиционной базой данных и хранилищем данных NoSQL? Используйте оба! Проблема с решениями NoSQL (за пределами начальной кривой обучения) заключается в отсутствии транзакций - вы делаете все обновления MySQL и заставляете MySQL заполнять хранилище данных NoSQL для чтения - тогда вы извлекаете выгоду из сильных сторон каждой технологии. Это добавляет сложности, но у вас уже есть сторона MySQL - просто добавьте в смесь MongoDB, Cassandra и т. Д.

Хранилища данных NoSQL обычно масштабируются лучше, чем традиционная БД для тех же самых спецификаций - есть причина, по которой Facebook, Twitter, Google и большинство стартапов используют решения NoSQL. Это не просто компьютерные фанаты, увлекающиеся новыми технологиями.

person Jason Grant Taylor    schedule 17.04.2012
comment
Я абсолютно согласен. Я использую mongodb + mysql в одном из разрабатываемых мной будущих продуктов. Это грядущее облако финансовых продуктов. mysql используется там, где нам абсолютно необходимы транзакционные возможности. mongodb используется для хранения сложных структур данных, не связанных с вычислением, которые просто нужно вытащить при необходимости. пока работает хорошо. :) - person Ram on Rails React Native; 19.07.2013
comment
Я также использовал такой двойной подход в большинстве своих проектов, а в некоторых других смонтированная файловая система NFS использовалась вместе с PostgreSQL для сейсмических блобов размером около 1 Гб в некоторых случаях. Путь - это своего рода запрос к базе данных значений ключей. - person Audrius Meskauskas; 28.08.2014
comment
Вот ссылка на вопрос, который я задал о том, как создавать базы данных как sql, так и nosql: dba.stackexchange.com/questions/102053/ Мне бы хотелось кое-что узнать, возможно, у вас есть - person j will; 20.05.2015
comment
Он уже ускользнул от транзакций навсегда = ›теперь возможна бесконечная масштабируемость .. иначе -› нет :) - person bodrin; 14.10.2015
comment
Если вы добавите MySQL, его будет громоздко масштабировать линейно, как кассандру. Вы можете получить единую точку отказа и неуклюжий способ восстановления данных после сбоя сервера. - person Rafael Sanches; 11.03.2016
comment
вы делаете все обновления MySQL и заставляете MySQL заполнять хранилище данных NoSQL для чтения. Разве NoSQL не оптимизирован для записи, а не чтения? Из datastax на Кассандре: Кассандра - это оптимизирован для высокой пропускной способности записи, и почти все записи одинаково эффективны. Если вы можете выполнять дополнительные операции записи для повышения эффективности запросов на чтение, это почти всегда хороший компромисс. Чтения обычно дороже и их намного сложнее настраивать. - person socom1880; 07.09.2016
comment
CQRS вписывается в это. - person Viku; 13.03.2018
comment
Это не лучшее решение, если ваши данные распространяются - person Esteban Verbel; 25.10.2018
comment
Начиная с версии 4.0, mongodb поддерживает многодокументные транзакции со всеми свойствами ACID. - person Grigori Melnik; 08.01.2019

Я, наверное, покажусь странным, но я думаю, что вам нужно оставаться с MySQL. Вы не описали реальную проблему, которую необходимо решить, а MySQL / InnoDB - отличное хранилище данных даже для данных blob / json.

Среди веб-инженеров есть распространенный трюк: пытаться использовать больше NoSQL, как только приходит понимание, что не все функции СУБД используются. Само по себе это не является веской причиной, поскольку в большинстве случаев базы данных NoSQL имеют довольно плохие механизмы обработки данных (то, что MySQL называет механизмом хранения).

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

person Kostja    schedule 23.02.2012
comment
Он использует сегментирование, что означает, что его данные вручную распределяются по серверам. Mongodb может автоматизировать сегментирование, что может быть преимуществом. - person fabspro; 14.02.2013
comment
Он также хранит в основном капли JSON в СУБД, делая реляционный дизайн (функции) бесполезным. - person Damir Sudarevic; 22.03.2013
comment
Модель данных и автоматическое сегментирование действительно различаются, но при выборе базы данных вам нужно обратить внимание на механизм хранения в первую очередь, а во вторую - все остальное. Как будет работать механизм хранения при резком скачке нагрузки? Как функция автошардинга будет работать при всплеске потока данных? Прежде чем передать контроль над базой данных для этих важных аспектов, вам лучше убедиться, что она способна справиться с этой задачей. - person Kostja; 30.04.2013
comment
Реляционная модель - одна из наиболее хорошо продуманных, эффективных для реализации и экономичных моделей данных. Отказ от использования реляционных функций дизайна может относиться к ограничениям, триггерам или ссылочной целостности, но все это оплачивается по факту использования. - person Kostja; 12.07.2013

Я не использовал Cassandra, но я использовал MongoDB и считаю, что это круто.

Если вам нужна простая настройка, вот и все: вы просто распаковываете MongoDB и запускаете демон mongod, и все ... он работает.

Очевидно, это только начало, но начать это легко.

person dalton    schedule 23.05.2010
comment
AFAIK, то же самое относится и к Кассандре. Унтар, запускай демон. Тестовый кластер настроен и готов к работе! - person asgs; 04.06.2015

Вчера видел презентацию на mongodb. Я могу с уверенностью сказать, что установка была «простой», достаточно просто распаковать ее и запустить. Сделанный.

Я считаю, что и mongodb, и cassandra будут работать практически на любом обычном Linux-оборудовании, поэтому вы не найдете особых препятствий в этой области.

Я думаю, что в этом случае, в конце концов, все будет сводиться к тому, с чем вы лично чувствуете себя более комфортно и какой набор инструментов вам больше нравится. Что касается презентации на mongodb, докладчик указал, что набор инструментов для mongodb был довольно легким и что не было много (они сказали, что действительно) инструментов, похожих на то, что доступно для MySQL. Это, конечно, был их опыт, так что YMMV. Одна вещь, которая мне нравилась в mongodb, заключалась в том, что для нее, казалось, было много языковой поддержки (Python и .NET - это два, которые я в основном использую).

Список сайтов, использующих mongodb, довольно впечатляет, и я знаю, что твиттер только что переключился использовать кассандру.

person GrayWizardx    schedule 23.05.2010
comment
В конце концов, это сравнение яблок и апельсинов. Обе базы данных имеют свои сильные стороны. Вот некоторые вещи, которые следует учитывать - объектная модель, вторичные индексы, масштабируемость записи, высокая доступность и т. Д. Есть сообщение в блоге, в котором объясняются стратегические различия высокого уровня между mongodb и cassandra здесь - scalegrid.io/blog/cassandra-vs-mongodb - person Dharshan; 14.08.2016