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

200

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

Twitter, Digg, Facebook и т. Д. Все используют его.

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

  • использовать Кассандру,
  • не использовать Кассандру, а
  • используйте RDMS вместо Cassandra.
JimJim
источник
7
Наверное, должен быть CW? Это в значительной степени просто NoSQL против реляционных баз данных, что является довольно субъективным IMO.
Эд Джеймс
3
Я хотел бы знать, подходит ли это для системы обмена сообщениями. Я предполагаю, что если Twitter использует это, тогда все будет в порядке, однако они могут использовать его не для всего Twitter?
Люк

Ответы:

165

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

Я постараюсь ответить на ваши вопросы один за другим в том же порядке, в котором вы их задавали. Поскольку 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 было бы сложным и утомительным для вас.

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

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

Аджай Тивари
источник
1
Проблема с ответом состоит в том, что он объединяет все решения NoSQL вместе. См. Dataconomy.com/sql-vs-nosql-need-know для получения дополнительной информации. В NoSQL-ландшафте основными разделениями являются документ, ключ-значение, график и большая таблица. У них разные характеристики для разных задач. Решение, которое подходит для Монго, может не подходить для Кассандры.
Yehosef
17
Единственный способ, которым этот ответ «объединяет все решения NoSQL вместе», - это категория NoSQL; кроме этого пост делает большую работу, указывая на то, что каждая база данных NoSQL "предлагает свое решение" для разных проблем. У меня не было ощущения, что автор даже намекнул, что mongo, cassandra или любая другая база данных NoSQL решают те же проблемы.
Ник Сувин
NoSQL databaseэто не вещь. NoSQLэто просто термин, используемый для современных нереляционных баз данных (см. вики ).
eddyP23
2
Также обратите внимание, что не все базы данных NoSQL не являются ACID. Графовые базы данных обычно являются кислотными.
eddyP23
Cassandra поддерживает атомарную операцию на уровне строк и атомарную и изоляцию для каждого раздела с использованием транзакций с легким весом. Если мое требование - иметь ACID на уровне строк, могу ли я не использовать Cassandra? Даже для критических данных?
TechEnthusiast
52

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

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

Натан Херст
источник
Когда вы в последний раз видели раздел, в котором оба раздела были большими? Смотрите мой вопрос stackoverflow.com/questions/7969874/…
Аарон Уоттерс
5
Кассандра также, очевидно, позволяет вам указать ваше требование согласованности во время запроса, что может быть полезным компромиссом для некоторых случаев использования
Ричард Марр,
30

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

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

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

Вагиф Верди
источник
27

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

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

Том Кларксон
источник
3
Схема вряд ли изменится, она хорошо вписывается в структуру таблицы, а потерянные / противоречивые данные могут вызвать реальные проблемы.
Том Кларксон,
4
Я не понимаю, почему противоречивые данные могут вызвать реальные проблемы с банками. Сценарий: у вас есть один банковский счет, на котором больше 100 долларов, и две банковские карты. Когда вы попытаетесь снять деньги с двух карт одновременно в 2 разных банкоматах, вы получите 2 раза по 100 долларов США и письмо с дополнительной комиссией в своем почтовом ящике. Банк зарабатывает деньги (дополнительная комиссия за превышение лимита), используя противоречивые данные. Трудно соединить все банкоматы в мире друг с другом через одну большую реляционную базу данных. Можете ли вы привести пример, когда непоследовательные финансовые данные могут быть проблемой?
Пако,
5
Все это - COBOL и пакетная обработка, и оно не так хорошо разработано / стабильно, как вы думаете. Банкоматы не подключаются к какому-либо унифицированному хранилищу данных, поэтому вряд ли являются подходящим примером. Это все равно что сказать, что SQL не подходит для веб-приложений, потому что вы не можете дать всем в Интернете прямой доступ к вашей базе данных. Кроме того, я никогда ничего не говорил о банках - подумайте, например, о заказах на сайте электронной коммерции, где вам не нужно иметь дело с организацией, настолько консервативной, что SQL считается новым и ненадежным.
Том Кларксон
6
@Paco: первый банкомат считывает ваш баланс ($ 100), а второй банкомат делает то же самое. Оба банкомата снимают 100 долларов со 100 долларов и записывают окончательный остаток в 0 долларов на свой счет. Результат: банк теряет 100 долларов.
Сеун Осева
9
@Paco: Дело в том, что без надлежащей изоляции транзакции обычный банк даже не узнает, что счет был списан. Они даже не узнают.
Сеун Осева
14

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

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

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

Надав хар'ел
источник
9

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

кроличий садок
источник
4

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

  1. (Volume, Velocity) Будете ли вы писать и читать тонны информации, настолько много информации, что ни один компьютер не сможет справиться с записью.
  2. (Глобальный) Вам понадобятся эти возможности записи и чтения по всему миру, чтобы записи в одной части мира были доступны в другой части мира?
  3. (Надежность) Нужна ли вам эта база данных, чтобы она была запущена и работала постоянно и никогда не выходила из строя независимо от того, какое Облако, какая страна, будь то ВМ, Контейнер или Голый металл?
  4. (Масштабируемость) Вам нужна эта база данных, чтобы иметь возможность продолжать расти легко и линейно масштабироваться
  5. (Согласованность) Вам нужна согласованность TUNABLE, когда некоторые записи могут происходить асинхронно, тогда как другие должны быть сертифицированы?
  6. (Навык) Готовы ли вы сделать все возможное, чтобы изучить эту технологию и моделирование данных, которое связано с созданием глобально распределенной базы данных, которая может быть быстрой для всех и везде?

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

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

Рахул Сингх
источник
3

Тяжелый одиночный запрос против gazillion легкой загрузки запросов - это еще один момент, который следует учитывать, помимо других ответов здесь. По сути, сложнее автоматически оптимизировать отдельный запрос в БД в стиле NoSql. Я использовал MongoDB и столкнулся с проблемами производительности при попытке вычислить сложный запрос. Я не использовал Кассандру, но я ожидаю, что у нее будет та же проблема.

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

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

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

sinelaw
источник
3

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

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, потому что синхронизация базы данных слишком медленная.

(Также из-за фиксации с 2 фразами, 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 также быстрее, чем Кассандра. Однако никогда не будет масштабируемости нескольких экземпляров.

CodeFarmer
источник
Вам не нужно соглашаться только с одной технологией базы данных. Вы можете иметь комбо и использовать тот, который подходит для конкретной проблемы.
Пепито Фернандес
3

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

  • Не рассматривайте Кассандру в качестве первого выбора, когда у вас есть строгие требования к отношениям (по всему набору данных).

  • Кассандра по умолчанию является системой AP (из CAP). Но он поддерживает настраиваемую согласованность, что означает, что он также может быть настроен для поддержки в качестве CP. Так что не игнорируйте это только потому, что вы где-то читали, что это AP, и вы ищете системы CP. Cassandra более точно называется «настраиваемой последовательностью», что означает, что она позволяет вам легко выбирать необходимый уровень согласованности в соответствии с уровнем доступности.

  • Не используйте Cassandra, если ваш масштаб невелик или вы можете иметь дело с нераспределенной БД.

  • Задумайтесь, если ваша команда думает, что все ваши проблемы будут решены, если вы используете распределенные БД, такие как Cassandra. Начать с этих БД очень просто, так как они имеют много значений по умолчанию, но их оптимизация и освоение для решения конкретной проблемы потребует значительных (если не много) инженерных усилий.

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

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

  • Cassandra оптимизирована для действительно высокой пропускной способности при записи. Если ваш вариант использования слишком тяжел для чтения (например, кеш), то Cassandra может быть не идеальным выбором.

rai.skumar
источник
2

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

ronaldmathies
источник
CouchdB, например, позволяет очень легко вычислять агрегатные функции: wiki.apache.org/couchdb/… . Технически, это «в коде», но это не так «сложно», как это было бы с Кассандрой.
user359996
2
На самом деле я согласен, что вам может потребоваться день для написания агрегата в коде, но вы можете написать его для запуска на бэкэнд-сервере, который будет использовать почти 0 циклов базы данных. С базой данных SQL вы получите результат, записав одну строку, которая может занять у вас 5 минут. но он будет тормозить всю базу данных каждый раз, когда вы ее запускаете. Так что есть плюсы и минусы в обоих направлениях. Мой банк, например, закрывает все посещения веб-сайтов в середине ночи примерно на 10-15 минут. Они наверняка используют COBOL, но это очень похожая проблема.
Алексис Уилке
1

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

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


источник
1
Cassandra Query Language (CQL) является очень похож на SQL, хотя. На самом деле, я бы сказал, что CQL является преимуществом Cassandra перед другими опциями NoSQL для тех, кто ищет SQL-подобный интерфейс.
arussell84
1
Кассандра технически не в конечном итоге последовательна. Cassandra позволяет вам обменять последовательность на доступность. Кассандра в основном балансирует теорему CAP. В конечном итоге вы можете иметь согласованную запись, а затем читать согласованно, наоборот или согласованно для обоих, и все это зависит от вашего коэффициента репликации в сочетании с вашим уровнем чтения / записи. Я получил ответ, поставив «в конечном итоге непротиворечивый» в кавычки, вероятно, по этой причине, но я чувствую, что некоторая ясность в порядке.
tsturzl
1

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

  1. Вам не нужны свойства ACID из вашей БД.

  2. Было бы огромное и огромное количество записей в БД.

  3. Требуется интеграция с Big Data, Hadoop, Hive и Spark.

  4. Необходим анализ данных в реальном времени и генерация отчетов.

  5. Требуется внушительный отказоустойчивый механизм.

  6. Существует требование однородной системы.

  7. Существует множество настроек для тюнинга.

KayV
источник
0

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

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

Сам Таха
источник
0

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

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

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

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

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

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

Remario
источник
Сильные гарантии согласованности, сервер всегда берет запись, и каждое чтение обеспечивает самое последнее.
Ремарио