MongoDB против Кассандры [закрыто]


739

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

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

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

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

4
Доступна официальная статистика производительности. Кассандра против MongoDB против HBase
Рави

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

2
Это большой вопрос на самом деле. Интересно, есть ли обновленная версия этого? Этот очень старый сейчас
slashdottir

Ответы:


584

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

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

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

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

Не беспокоиться о «масштабной» масштабируемости

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

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

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

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


86
Абсолютно другой комментарий недостаточно велик, но ... Cassandra - это линейно масштабируемый (амортизируемый постоянный время чтения и записи) динамический гибрид Google / Google, который обеспечивает быструю запись независимо от размера данных. Его набор функций минималистичен, немного больше, чем у упорядоченного хранилища значений ключей. MongoDB - это многофункциональное (и быстрое) хранилище документов за счет долговечности и гарантирует сохранение записей (поскольку они не сразу записываются на диск). Это разные звери с разной философией, MongoDB ближе к замене RDMS ...
Майкл

28
в то время как Cassandra находится на более низком уровне, но допускает масштабирование uber (см. Twitter / Digg / Facebook), но вам нужно быть осторожным в том, как вы выкладываете свои данные, строите вторичные индексы и т. д., поскольку гибкие запросы не допускаются.
Майкл

11
Поскольку все упомянули здесь твиттер в отношении Кассандры: они не используют Кассандру для постоянных твитов, они все еще используют MySQL здесь ( engineering.twitter.com/2010/07/cassandra-at-twitter-today.html ). Хорошо, но я могу представить, что они все еще хранят много данных для других целей в Кассандре.
Н6.

7
Похоже, что глобальная блокировка записи могла быть удалена в Mongo 2.2 ...
Мэтт Фармер

16
Еще до того, как мой проект вышел в свет, я чувствую болевые точки Mongodb. Горячее резервирование является основным требованием. Чтобы выполнить горячее резервное копирование на сервере Linux, вы должны сначала настроить раздел LVM (не так часто) и делать снимок перед каждым сеансом резервного копирования. Другим простым способом является использование платного резервного копирования Mongodb. Но эта услуга стоит дорого (2,3 $ / ГБ / месяц). Вскоре вам понадобится репликация для отказоустойчивости. В версии с открытым исходным кодом узлы могут обмениваться данными только в виде открытого текста. Для SSL вы должны пойти с выпуском Entprise. И это 10000 долларов. Прощай, Монгодб. Рефакторинг моего кода Кассандре.
Картик Санкар

146

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

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

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

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

{
   FirstName: "John",
   LastName: "Smith",
   Email: "john@smith.com",
   Groups: ["Admin", "User", "SuperUser"]
}

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

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

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


54
Обновление (8 августа 2011 г.). В центре обработки данных Amazon EC2 в Ирландии прошлой ночью произошел инцидент, связанный с молнией, и, разбираясь с возможностями восстановления нашего сервера, я обнаружил один довольно важный момент: если у вас есть набор репликации из двух серверов (и они легко установить), убедитесь, что у вас есть узел Арбитр, поэтому, если один из них выходит из строя, другой не паникует и не глохнет во вторичном режиме! Поверьте мне, это большая проблема, чтобы разобраться с большой базой данных.
Ричард К.

8
чтобы добавить то, что сказал @Richard K, у вас должен быть узел арбитра, когда у вас есть четное количество узлов (первичное + вторичное) в наборе реплик.
Amareswar

В добавок к этому рассмотрим mongodb, когда в аналитике данных должно быть больше агрегирования.
user1503117

As long as you think about indexes carefully, it can absolutely scream along, speed-wise.Подождите, пока ваша физическая память не будет заполнена, и ОС начнет
сбой

117

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

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


8
Я абсолютно согласен. Я использую mongodb + mysql в одном из будущих продуктов, которые я создаю. Это грядущее облако финансовых продуктов. mysql используется там, где нам абсолютно необходимы транзакционные возможности. mongodb используется для хранения некомпьютерных сложных структур данных, которые просто необходимо извлекать при необходимости. пока работает хорошо. :)
Ram на Rails-n-React

Я также использовал такой двойной подход в большинстве своих проектов, а в некоторых других файлов смонтированная файловая система NFS использовалась вместе с PostgreSQL для сейсмических блобов, приближающихся к 1 Гб в некоторых случаях. Путь - это своего рода запрос к базе данных значений ключей.
Аудрюс Мескаускас

1
Вот ссылка на вопрос, который я задал о том, как спроектировать базы данных sql и nosql: dba.stackexchange.com/questions/102053/… Я мог бы использовать некоторые идеи, которые у вас могут быть
j будет

Он уже сбежал из транзакций навсегда => теперь возможна бесконечная масштабируемость .. в противном случае -> нет :)
bodrin

1
Это не очень хорошее решение, если ваши данные распространяются
Esteban Verbel

60

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

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

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


13
Он использует шардинг, что означает, что его данные вручную распределены по серверам. Mongodb может автоматизировать разбиение, что может быть полезным.
fabspro

18
Он также хранит в RDBMS в основном JSON-объекты, что делает реляционный дизайн (функции) бесполезным.
Дамир Сударевич

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

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

20

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

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

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


22
AFAIK, то же самое относится и к Кассандре. Унтар, запусти демона. Тестовый кластер настроен и готов к работе!
просит

13

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

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

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

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


4
В конце дня это сравнение яблок и апельсинов. Обе базы данных имеют свои сильные стороны. Вот некоторые вещи , чтобы рассмотреть - модель объекта, вторичные индексы, масштабируемость записи, высокая avaialability и т.д. имеют записи в блоге , что объясняет стратегические различия на высоком уровне между MongoDB и Cassandra здесь - scalegrid.io/blog/cassandra-vs-mongodb
Dharshan
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.