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

Question

В последнее время много говорят о Кассандре .

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

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

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

Answer 1

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

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

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

В случае СУБД сделать выбор довольно легко, поскольку все базы данных, такие как 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 было бы сложно и утомительно для вас.

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

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

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

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

Answer 8

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

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

Answer 9

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

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

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

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

Answer 10

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

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

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