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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я широко использовал 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 довольно хороша.

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

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

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

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

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

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

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

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

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

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

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

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