Кассандра против MongoDB
Вы рассматриваете Cassandra или MongoDB в качестве хранилища данных для вашего следующего проекта? Хотите сравнить две базы данных? Cassandra и MongoDB являются базами данных «NoSQL», но реальность такова, что они очень разные. У них очень разные сильные стороны и ценностные предложения, поэтому любое сравнение должно быть нюансированным. Давайте начнем с начальных требований… Ни одна из этих баз данных не заменяет СУБД, и они не являются базами данных «ACID». Поэтому, если у вас есть транзакционная рабочая нагрузка, где нормализация и согласованность являются основными требованиями, ни одна из этих баз данных не подойдет вам. Вам лучше придерживаться традиционных реляционных баз данных, таких как MySQL, PostGres, Oracle и т. Д. Теперь, когда у нас нет реляционных баз данных, давайте рассмотрим основные различия между Cassandra и MongoDB, которые помогут вам принять решение. В этой статье я не буду обсуждать конкретные функции, но укажу некоторые стратегические различия высокого уровня, которые помогут вам сделать свой выбор.
- Выразительная модель объекта
MongoDB поддерживает богатую и выразительную объектную модель. Объекты могут иметь свойства, а объекты могут быть вложены друг в друга (для нескольких уровней). Эта модель очень «объектно-ориентирована» и может легко представлять любую объектную структуру в вашем домене. Вы также можете индексировать свойство любого объекта на любом уровне иерархии - это поразительно мощно! Cassandra, с другой стороны, предлагает довольно традиционную структуру таблицы со строками и столбцами. Данные более структурированы, и каждый столбец имеет определенный тип, который можно указать при создании.
Вердикт: если вашему проблемному домену нужна модель с богатыми данными, то MongoDB подойдет вам лучше.
- Вторичные индексы
Вторичные индексы - это первоклассная конструкция в MongoDB. Это позволяет легко индексировать любое свойство объекта, хранящегося в MongoDB, даже если оно вложено. Это позволяет легко выполнять запросы на основе этих вторичных индексов. Кассандра имеет только краткую поддержку вторичных индексов. Вторичные индексы также ограничены одиночными столбцами и сравнениями на равенство. Если вы в основном будете запрашивать по первичному ключу, то Cassandra будет работать для вас хорошо.
Вердикт: если вашему приложению нужны вторичные индексы и требуется гибкость в модели запросов, тогда MongoDB лучше подходит для вас.
- Высокая доступность
MongoDB поддерживает модель «один мастер». Это означает, что у вас есть главный узел и несколько подчиненных узлов. В случае, если мастер выходит из строя, один из рабов выбирается в качестве мастера. Этот процесс происходит автоматически, но это занимает время, обычно 10-40 секунд. В это время выборов нового лидера ваш набор реплик не работает и не может принимать записи. Это работает для большинства приложений, но в конечном итоге зависит от ваших потребностей. Кассандра поддерживает модель «несколько мастеров». Потеря одного узла не влияет на способность кластера принимать записи - таким образом, вы можете достичь 100% безотказной работы для записи.
Вердикт: если вам нужно 100% безотказной работы, Cassandra вам лучше подойдет.
- Масштабируемость записи
MongoDB с его моделью «один мастер» может принимать записи только на основной. Вторичные серверы могут использоваться только для чтения. Таким образом, в сущности, если у вас есть набор реплик из трех узлов, только мастер выполняет запись, а два других узла используются только для чтения. Это сильно ограничивает масштабируемость записи. Вы можете развернуть несколько сегментов, но по существу только 1/3 ваших узлов данных может выполнять запись. Cassandra с ее моделью «нескольких мастеров» может записывать записи на любом сервере. По сути, ваша масштабируемость записи ограничена количеством серверов в кластере. Чем больше серверов в кластере, тем лучше он будет масштабироваться.
Вердикт: если ваша задача - масштабируемость записи, Cassandra вам больше подойдет.
- Поддержка языка запросов
Cassandra поддерживает язык запросов CQLЭто очень похоже на SQL.Если у вас уже есть команда аналитиков данных, они смогут перенести большинство своих навыков SQL, что очень важно для крупных организаций.Однако CQL не является полноценным ANSI SQL - у него есть несколько ограничений (нет поддержки объединения, нет предложений OR) и т. Д. MongoDB на данный момент не поддерживает язык запросов.Запросы структурированы как фрагменты JSON.
Вердикт: если вам нужна поддержка языка запросов, Cassandra подойдет вам лучше.
Тесты производительности Давайте поговорим о производительности.На данный момент вы, вероятно, ожидаете сравнения производительности баз данных.Я сознательно не включил показатели производительности в сравнение.В любом сравнении мы должны убедиться, что проводим сравнение между яблоками и яблоками.
Модель базы данных - модель / схема базы данных тестируемого приложения имеет большое значение.Некоторые схемы хорошо подходят для MongoDB, а некоторые - для Cassandra.Поэтому при сравнении баз данных важно использовать модель, которая достаточно хорошо работает для обеих баз данных.
Характеристики нагрузки - характеристики эталонной нагрузки очень важны.Например, в тестах с интенсивной записью я бы ожидал, что Кассандра будет курить MongoDB.Однако в тестах с интенсивным чтением MongoDB и Cassandra должны быть похожими по производительности. Требования согласованности - это сложный вопрос.Необходимо убедиться, что указанные требования согласованности чтения / записи идентичны в обеих базах данных и не смещены в отношении одного участника.Очень часто в ряде тестов «Маркетинг» ручки настраиваются, чтобы поставить в невыгодное положение другую сторону.Поэтому обратите пристальное внимание на параметры согласованности.
Последнее, что следует иметь в виду, - то, что эталонная загрузка может отражать или не отражать производительность вашего приложения.Поэтому для того, чтобы тесты были полезны, очень важно найти тестовую нагрузку, которая отражает характеристики производительности вашего приложения.Вот некоторые тесты, на которые вы могли бы обратить внимание: - Тесты производительности NoSQL - Cassandra против MongoDB против Couchbase против HBase
Простота использования Если бы вы задали этот вопрос пару лет назад, MongoDB станет победителем.Это довольно простая задача, чтобы запустить MongoDB.Однако в последние пару лет Cassandra добилась больших успехов в этом аспекте продукта.Приняв CQL в качестве основного интерфейса для Cassandra, он сделал еще один шаг вперед - легионам программистов SQL стало очень просто использовать Cassandra очень просто.
Вердикт: оба вариантадовольно прост в использовании и наращивает.
Собственное агрегирование MongoDB имеет встроенную платформу агрегации для запуска конвейера ETL для преобразования данных, хранящихся в базе данных.Это отлично подходит для небольших и средних заданий, но по мере усложнения обработки ваших данных становится сложно отлаживать структуру агрегирования.Кассандра не имеет встроенной структуры агрегации.Для этого используются внешние инструменты, такие как Hadoop, Spark.
Модели без схемы В MongoDB вы можете не применять никакие схемы к своим документам.Хотя это было по умолчанию в предыдущих версиях, в более новой версии у вас есть возможность применить схему для ваших документов.Каждый документ в MongoDB может иметь различную структуру, и ваше приложение должно интерпретировать данные.Хотя это не относится к большинству приложений, в некоторых случаях важна дополнительная гибкость.Cassandra в более новых версиях (с CQL в качестве языка по умолчанию) обеспечивает статическую типизацию.Вам необходимо определить тип самого столбца заранее.