Когда НЕ использовать Кассандру?

В последнее время было много разговоров, связанных с Cassandra.

Twitter, Digg, Facebook и т.д. все это используют.

Когда имеет смысл:

используйте Cassandra,
не использовать Cassandra и
используйте RDMS вместо Cassandra.

Ответ 1

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

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

Зачем использовать NoSQL

В случае с RDBMS сделать выбор довольно легко, потому что все базы данных, такие как MySQL, Oracle, MS SQL, PostgreSQL в этой категории, предлагают практически одинаковые решения, ориентированные на свойства ACID. Когда дело доходит до NoSQL, решение становится трудным, потому что каждая база данных NoSQL предлагает различные решения, и вы должны понять, какая из них лучше всего подходит для ваших приложений/системных требований. Например, MongoDB подходит для случаев, когда ваша система требует хранилища документов без схемы. HBase может подойти для поисковых систем, анализирующих данные журналов или для любого другого места, где требуется сканирование огромных двумерных таблиц без объединения. Redis создан для обеспечения поиска в памяти различных структур данных, таких как деревья, очереди, связанные списки и т.д., И может хорошо подходить для создания списков лидеров в режиме реального времени, системы Pub-Sub. Точно так же есть другие базы данных в этой категории (включая Cassandra), которые подходят для различных постановок задач. Теперь давайте перейдем к исходным вопросам и ответим на них один за другим.

Когда использовать Кассандру

Будучи частью семейства NoSQL, Cassandra предлагает решение проблем, когда одним из ваших требований является наличие очень тяжелой системы записи, и вы хотите иметь достаточно отзывчивую систему отчетов поверх этих хранимых данных. Рассмотрим вариант использования веб-аналитики, в котором данные журнала хранятся для каждого запроса, и вы хотите построить вокруг него аналитическую платформу для подсчета посещений в час, по браузеру, по IP и т.д. В режиме реального времени. Вы можете обратиться к этому сообщению в блоге, чтобы узнать больше о случаях использования Cassandra.

Когда использовать RDMS вместо Cassandra

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

Когда не стоит использовать Кассандру

Я не думаю, что на это нужно отвечать, если приведенное выше объяснение имеет смысл.

Ответ 2

При оценке распределенных систем данных вы должны рассмотреть теорему CAP - вы можете выбрать два из следующих: согласованность, доступность и допустимость разделов.

Cassandra - это доступная, устойчивая к перегородке система, которая поддерживает возможную согласованность. Для получения дополнительной информации см. Это сообщение в блоге я написал: Visual Guide для NoSQL Systems.

Ответ 3

Cassandra - это ответ на конкретную проблему: что вы делаете, когда у вас так много данных, что они не подходят на одном сервере? Как вы храните все свои данные на многих серверах и не разбиваете свой банковский счет и не делаете своих разработчиков безумными? Facebook получает 4 терабайта новых сжатых данных КАЖДЫЙ ДЕНЬ. И это число, скорее всего, будет расти более чем в два раза в течение года.

Если у вас нет таких данных или у вас есть миллионы, чтобы заплатить за установку кластера Enterprise Oracle/DB2 и специалистов, необходимых для его настройки и поддержки, тогда вы в полной мере работаете с базой данных SQL.

Однако Facebook больше не использует cassandra и теперь использует MySQL почти исключительно для перемещения разделов в стеке приложений для повышения производительности и лучшего контроля.

Ответ 4

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

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

Ответ 5

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

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

Кроме того, недавно (спустя несколько лет после того, как этот вопрос был первоначально задан), был выпущен клон Cassandra под названием Scylla (см. https://en.wikipedia.org/wiki/Scylla_(database)). Scylla - это повторная реализация Cassandra на С++ с открытым исходным кодом, которая утверждает, что имеет значительно более высокую пропускную способность и более низкую задержку, чем оригинальная Java Cassandra, хотя она в основном совместима с ней (в функциях, API и форматах файлов). Поэтому, если вы уже рассматриваете Cassandra, вы можете также рассмотреть Scylla.

Ответ 6

Говоря с кем-то посреди развертывания Cassandra, он не справляется со многими из многих. Они делают взломанную работу, чтобы выполнить свое первоначальное тестирование. Я поговорил с консультантом Cassandra об этом, и он сказал, что не будет рекомендовать его, если у вас возникла эта проблема.

Ответ 7

Вы должны задать себе следующие вопросы:

(Volume, Velocity) Будете ли вы писать и читать тонны информации, настолько много информации, что ни один компьютер не сможет справиться с записями.
(Global) Вам понадобятся такие возможности записи и чтения по всему миру, чтобы записи в одной части мира были доступны в другой части мира?
(Надежность) Нужна ли вам эта база данных, чтобы она постоянно работала и никогда не выходила из строя независимо от того, какое облако, какая страна, VM, Container или Bare metal?
(Возможность масштабирования) Вам нужна эта база данных, чтобы можно было легко продолжать расти и линейно масштабировать
(Согласованность) Требуется ли согласованность TUNABLE, когда некоторые записи могут происходить асинхронно, а другие должны быть сертифицированы?
(Навык) Готовы ли вы сделать то, что нужно, чтобы изучить эту технологию и моделирование данных, которое связано с созданием глобально распределенной базы данных, которая может быть быстрой для всех и везде?

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

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

Ответ 8

Тяжелый запрос на один запрос против gazillion light - еще один момент для рассмотрения, в дополнение к другим ответам здесь. Сложнее автоматически оптимизировать один запрос в DB в стиле NoSql. Я использовал MongoDB и столкнулся с проблемами производительности при попытке вычислить сложный запрос. Я не использовал Cassandra, но я ожидаю, что у нее будет такая же проблема.

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

Для одного очень тяжелого запроса любой современный RDBMS-движок может выполнить приличную работу, распараллеливая части запроса и использовать как можно больше CPU и памяти, которые вы бросаете на нее (на одной машине). Базы данных NoSql не располагают достаточной информацией о структуре данных, чтобы иметь возможность делать допущения, которые позволят действительно интеллектуальную распараллеливание большого запроса. Они позволяют вам легко масштабировать больше серверов (или ядер), но как только запрос попадает на уровень сложности, вы в основном вынуждены разделить его вручную на части, которые движок NoSql знает, как справляться разумно.

По моему опыту с MongoDB, в конце концов из-за сложности запроса было мало того, что Mongo мог бы сделать, чтобы оптимизировать его и запустить его части по нескольким данным. Mongo распараллеливает несколько запросов, но не очень хорошо оптимизирует один.

Ответ 9

@Paco Извините, что разрывает ваш пузырь, но особенно с финансовыми данными, последовательность транзакций - CRITICAL. Как было отмечено в таких базах данных, как Cassandra, неудавшийся script может оставить побочные эффекты, которые могут включать в себя одну обновленную таблицу, а другую нет. Один пример: 100 фунтов стерлингов переходят из учетной записи пользователя 1 в учетную запись пользователя 2. С каждой учетной записью регистрируется транзакция, показывающая, что она удалена из одной и добавлена к другой. Конечно, это зависит от вашего дизайна. В другом сценарии платеж берется банку. Средства должны быть удалены с одного счета и добавлены в другой. Отсутствие согласованности оставило бы потенциал для денег "пропадать" из системы или быть двойным. В любом случае, банк находится в беде.

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

Отсутствие поддержки соединения через cassandra также ограничивает ее использование, если с ним не используются другие приложения. В этой заметке так не хватает функций триггера, внешних ключей и т.д. Все это в конечном итоге сводится к тому, что вам нужно. Если вы, например, являетесь провайдером поиска и имеете огромную клиентскую базу, Cassandra может быть идеально подходит. Для OLTP и некоторых случаев отчетности, с другой стороны, или меньших объемов нагрузки, это может быть полное несоответствие требованиям.

Ответ 10

Давайте прочитаем несколько реальных случаев:

http://planetcassandra.org/apache-cassandra-use-cases/

В этой статье: http://planetcassandra.org/blog/post/agentis-energy-stores-over-15-billion-records-of-time-series-usage-data-in-apache-cassandra

Они разработали причину, по которой они не выбрали MySql, потому что синхронизация базы данных слишком медленная.

(Также из-за фиксации с двумя фразами, FK, PK)

Кассандра основана на газете Amazon Dynamo

Особенности:

СтабильностьВысокая доступность

Резервное копирование работает хорошо

Читать и писать лучше, чем HBase (клон BigTable в Java).

вики http://en.wikipedia.org/wiki/Apache_Cassandra

Их заключение таково:

We looked at HBase, Dynamo, Mongo and Cassandra. 

Cassandra was simply the best storage solution for the majority of our data.

По состоянию на 2018 год,

Я бы порекомендовал использовать ScyllaDB для замены классической кассандры, если вам нужна поддержка спины.

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

Ответ 11

Другая ситуация, облегчающая выбор, - это когда вы хотите использовать функцию агрегата, такую как sum, min, max и т.д. и сложные запросы (например, в финансовой системе, упомянутой выше), тогда реляционная база данных, вероятно, более удобна, чем база данных nosql поскольку оба варианта невозможны на nosql databse, если вы не используете действительно много инвертированных индексов. Когда вы используете nosql, вам придется выполнять совокупные функции в коде или хранить их отдельно в своем собственном столбце, но это делает его довольно сложным и снижает производительность, полученную вами при использовании nosql.

Ответ 12

Если вам нужна полностью совместимая база данных с семантикой SQL, Cassandra НЕ является решением для вас. Cassandra поддерживает поиск по ключевым словам. Он не поддерживает SQL-запросы. Данные в Кассандре "в конечном итоге последовательны". Параллельный поиск данных может быть непоследовательным, но в конечном итоге поиск согласуется.

Если вам нужна строгая семантика и нужна поддержка SQL-запросов, выберите другое решение, такое как MySQL, PostGres или используйте Cassandra с Solr.

Ответ 13

Кассандра - хороший выбор, если:

Вам не нужны свойства ACID из вашей БД.
Было бы огромное и огромное количество записей в БД.
Требуется интеграция с Big Data, Hadoop, Hive и Spark.
Необходим анализ данных в реальном времени и генерация отчетов.
Требуется внушительный отказоустойчивый механизм.
Существует требование однородной системы.
Существует множество настроек для тюнинга.

Ответ 14

Здесь я сосредоточусь на некоторых важных аспектах, которые могут помочь вам решить, действительно ли вам нужна Кассандра. Список не является исчерпывающим, только некоторые из пунктов, которые я имею в верхней части моего mind-

Не рассматривайте Кассандру в качестве первого выбора, когда у вас есть строгие требования к отношениям (по всему набору данных).
Кассандра по умолчанию является системой AP (из CAP). Но он поддерживает настраиваемую согласованность, что означает, что он также может быть настроен для поддержки в качестве CP. Так что не игнорируйте это только потому, что вы где-то читали, что это AP, и вы ищете системы CP. Cassandra более точно называется "настраиваемой последовательностью", что означает, что она позволяет вам легко определять уровень согласованности. требуется в соответствии с уровнем доступности.
Не используйте Cassandra, если ваш масштаб невелик или вы можете иметь дело с нераспределенной БД.
Задумайтесь, если ваша команда думает, что все ваши проблемы будут решены, если вы используете распределенные БД, такие как Cassandra. Начать с этих БД очень просто, так как они имеют много значений по умолчанию, но их оптимизация и освоение для решения конкретной проблемы потребует значительных (если не много) инженерных усилий.
Кассандра ориентирована на столбцы, но в то же время каждая строка также имеет уникальный ключ. Таким образом, было бы полезно думать об этом как о индексированном, ориентированном на строки хранилище. Вы даже можете использовать его как хранилище документов.
Кассандра не заставляет вас определять поля заранее. Итак, если вы находитесь в режиме запуска или ваши функции развиваются (как в Agile) - Cassandra обнимает его. Так что лучше сначала подумайте о запросах, а затем подумайте о данных, чтобы ответить на них.
Cassandra оптимизирована для действительно высокой пропускной способности при записи. Если ваш вариант использования слишком тяжел для чтения (например, кеш), то Cassandra может оказаться не идеальным выбором.

Ответ 15

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

Все это идет с компромиссами, конечно. Поэтому, когда вы выбираете свою базу данных (NoSQL, NewSQL или RDBMS), посмотрите, какую проблему вы пытаетесь решить, и по вашим требованиям к масштабируемости. Ни одна база данных не делает все.

Ответ 16

Согласно DataStax, Cassandra не лучший вариант использования, когда есть необходимость в

1- Высокопроизводительные аппаратные устройства. 2- ACID, не откат (банковская транзакция)

Ответ 17

Он не поддерживает полное управление транзакциями через столы.
Вторичный индекс не поддерживается.
Должен полагаться на поиск эластичного поиска /Solr для вторичного индекса и должен быть записан пользовательский компонент синхронизации.
Не совместимая с ACID система.
Поддержка запросов ограничена.

Ответ 18

Apache cassandra - это распределенная база данных для управления большими объемами структурированных данных на многих товарных серверах, обеспечивая при этом высокодоступный сервис и отсутствие единой точки отказа.

Архивирование чисто основано на теореме о шапке, которая является доступностью и терпимостью к разделам, и, что интересно, последовательно.

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

Ответ 19

В виде:

используйте Cassandra там, где ожидается тяжелая запись, временные ряды, высокая доступность
Не используйте Cassandra там, где ожидается сильная согласованность, интенсивное чтение и транзакции
Используйте RDMS вместо Cassandra, куда вставлены данные транзакции