Как Кассандра сравнивается с MySQL (или любой другой РСУБД) в настройке одного узла?

Question

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

Но меня беспокоит, как работает Кассандра на одном узле. Как и многие другие, я могу начать только с небольшого количества данных, поэтому более одного узла для начала просто не практично. Основываясь на другом отличном SO-вопросе: Why don't you start off with a "single & small" Cassandra server as you usually do it with MySQL? Я пришел к выводу, что Cassandra действительно может быть запущен просто как единый узел, если только вы готовы отказаться от преимуществ, таких как доступность, которые получены из многоузловой установки.

Существуют также способы реализации динамического добавления полей в РСУБД, например, как описано здесь на SO: How to design a database for User Defined Fields? Это в какой-то мере имитирует схематичность.

Итак, теперь я хотел бы разобраться, как сравнивать Cassandra и MySQL в отношении характеристик и производительности при настройке одного узла? Что бы вы посоветовали кому-то в моей ситуации - начните с простой РСУБД с планом/намерением перейти на Кассандру позже? Или начать с Кассандры?

Answer 1

В одной конфигурации узла Кассандры многие преимущества Cassandra теряются, поэтому основной причиной этого было бы, если бы вы планировали расширить до нескольких узлов в будущем. Производительность будет способствовать использованию СУБД в большинстве приложений при использовании единого узла, поскольку RDBMS предназначена для этой среды и может предполагать, что все данные являются локальными.

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

RDBMS напротив - более зрелая технология. ACID-транзакции не проблема. Конструкция схемы намного проще, поскольку вы можете добавлять эффективные индексы в любой столбец для оптимизации запросов, и у вас есть соединения, позволяющие в значительной степени исключить избыточные данные. Исключая избыточные данные, гораздо проще поддерживать согласованность данных, поскольку не существует нескольких копий данных, которые необходимо обновить, если кто-то изменит их адрес, например. Но вы рискуете исчерпать пространство на одной машине, чтобы хранить все свои данные. И если вы столкнетесь с диском, у вас будет время простоя и потребуются резервные копии для восстановления данных, а Cassandra часто может легко восстановить данные на узле, который не синхронизирован. Также нет простого способа масштабирования РСУБД для обработки более высоких ставок транзакций, кроме покупки более быстрой машины.

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