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

database rdbms nosql cassandra

84156 просмотра

18 ответа

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

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

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

  • использовать Кассандру,
  • не использовать Кассандру, а
  • используйте RDMS вместо Cassandra.
Автор: JimJim Источник Размещён: 30.08.2019 05:08

Ответы (18)


154 плюса

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

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

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

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

Автор: ajay Размещён: 21.06.2015 11:33

48 плюса

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

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

Автор: Nathan Hurst Размещён: 20.04.2010 07:01

28 плюса

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

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

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

Автор: Vagif Verdi Размещён: 24.04.2010 07:30

27 плюса

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

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

Автор: Tom Clarkson Размещён: 14.04.2010 10:22

13 плюса

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

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

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

Автор: Nadav Har'El Размещён: 07.11.2017 09:51

9 плюса

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

Автор: Warren Размещён: 06.06.2010 10:21

4 плюса

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

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

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

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

Автор: Rahul Singh Размещён: 15.03.2019 01:44

3 плюса

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

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

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

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

Автор: sinelaw Размещён: 09.04.2013 02:36

3 плюса

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

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

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

Автор: Simon Размещён: 04.10.2013 10:59

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 Размещён: 07.10.2014 03:59

2 плюса

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

Автор: ronaldmathies Размещён: 28.04.2010 04:31

1 плюс

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

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

Автор: user2089236 Размещён: 09.03.2017 04:23

1 плюс

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

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

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

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

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

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

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

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

Автор: KayV Размещён: 21.03.2018 04:53

1 плюс

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

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

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

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

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

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

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

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

Автор: rai.skumar Размещён: 06.08.2019 10:21

0 плюса

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

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

Автор: Sam Taha Размещён: 09.04.2013 02:06

0 плюса

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

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

Автор: Mike Размещён: 05.05.2017 02:50

0 плюса

  • Он не поддерживает полное управление транзакциями в разных таблицах.
  • Вторичный индекс не поддерживается.
  • Нужно полагаться на Elastic search / Solr для вторичного индекса, и пользовательский компонент синхронизации должен быть написан.
  • Система не совместима с ACID.
  • Поддержка запросов ограничена.
Автор: Deepak Panneerselvam Размещён: 16.10.2017 10:56

0 плюса

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

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

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

Автор: Remario Размещён: 07.12.2017 11:48
Вопросы из категории :
32x32