Если не использовать Cassandra?

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

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

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

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

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

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

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

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

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