Для каких задач подходит Apache Cassandra, а когда её лучше не использовать
Apache Cassandra создавалась под запись огромных объёмов данных с предсказуемой задержкой и линейным масштабированием: телеметрия, события пользователей, логи, ленты сообщений, счётчики. Она плохо подходит там, где нужны сложные соединения таблиц, произвольные выборки по любому полю и строгие транзакции на нескольких строках. Правило простое: если вы заранее знаете все запросы к данным — Cassandra будет работать отлично, если нет — начнутся проблемы.
Почему запись в Cassandra быстрее, чем в реляционной СУБД
В основе — LSM-дерево. Запись сначала попадает в commit log и memtable в оперативной памяти, а на диск сбрасывается пачкой в виде неизменяемого файла SSTable. Никакого поиска нужной страницы на диске и обновления на месте — отсюда высокая скорость вставок даже на обычных SSD.
Расплата приходит позже, во время компакции: фоновый процесс сливает SSTable, удаляет устаревшие версии строк и надгробия (tombstones). Компакция ест диск и процессор, поэтому под неё резервируют запас ресурсов. Кластер архитектурно симметричен — выделенного мастера нет, узлы обмениваются состоянием по протоколу gossip, а узел, принявший запрос, работает координатором и рассылает его репликам.
Когда Cassandra — верный выбор
- Поток записи заметно превышает поток чтения, и данные почти всегда читаются по известному ключу партиции.
- Нужна работа в нескольких дата-центрах с настраиваемым уровнем согласованности (обычно на практике берут LOCAL_QUORUM, а не ONE и не ALL).
- Требуется отказоустойчивость без ручного переключения: при факторе репликации 3 потеря одного узла не останавливает сервис.
- Данные естественным образом делятся по времени — тогда стратегия компакции TWCS плюс TTL превращают удаление старых записей почти в бесплатную операцию.
- Объём растёт непрерывно, и расширение кластера должно сводиться к добавлению узлов, а не к переезду на более мощный сервер.
Протокол CQL и модель данных Cassandra за годы стали фактическим стандартом для распределённых key-value и wide-column хранилищ, поэтому появились альтернативные реализации — как зарубежные, так и российские СУБД, совместимые с apache cassandra на уровне протокола; подробнее можно узнать на сайте разработчика.
Что делать, если данные не ложатся в модель Cassandra
Первый признак проблемы — желание сделать JOIN или фильтр по неключевому полю. В CQL нет соединений, а запрос с ALLOW FILTERING обходит весь кластер и в продакшене почти всегда ошибка. Стандартный приём — денормализация: одна таблица под каждый сценарий чтения, дублирование данных считается нормой, а не грехом.
Вторичные индексы выручают редко: локальные индексы деградируют на высокой кардинальности, материализованные представления долго оставались экспериментальными. Часто помогают связки: Cassandra как хранилище фактов плюс отдельный поисковый движок или аналитическая СУБД для произвольных срезов. Лёгкие транзакции (LWT) через Paxos существуют, но каждая такая операция в разы дороже обычной записи — их держат для редких проверок уникальности, а не для основной нагрузки.
Если же бизнес-логика требует настоящих многострочных транзакций и постоянно меняющихся запросов, дешевле взять PostgreSQL или NewSQL-решение, чем бороться с ограничениями модели.
Ошибки проектирования, из-за которых кластер деградирует
- Слишком крупные партиции. Ориентир, который дают практики эксплуатации: держать партицию в пределах сотни мегабайт и порядка ста тысяч строк — за этими границами растут задержки и риск GC-пауз.
- Горячие партиции: ключ вроде «дата без времени» отправляет весь трафик суток на одни и те же реплики. Спасает добавление шардирующего суффикса в ключ.
- Использование таблиц как очереди. Постоянные удаления рождают тонны надгробий, и чтение начинает упираться в их сканирование; по умолчанию предупреждение срабатывает после тысячи tombstones на запрос, отказ — после ста тысяч.
- Запуск repair «когда вспомним». Плановый ремонт нужно успевать проводить в пределах gc_grace_seconds (по умолчанию 10 суток), иначе удалённые данные могут воскреснуть.
- Ставка на CL=ALL ради надёжности: любой недоступный узел превращает запись в ошибку, хотя кворум справился бы.
Вопросы и ответы
Сколько узлов нужно для старта?
Минимально жизнеспособный продакшен-кластер — три узла при факторе репликации 3, это позволяет работать с кворумом при потере одной машины. Один или два узла годятся только для разработки.
Cassandra может потерять данные при отключении узла?
При корректном факторе репликации и уровне QUORUM — нет: данные лежат на нескольких репликах, а отставший узел догоняется через hinted handoff, read repair и плановый repair. Риск возникает, если писать с CL=ONE и годами не запускать ремонт.
Чем ScyllaDB отличается от Apache Cassandra?
ScyllaDB — переписанная на C++ реализация той же модели данных и протокола CQL, без JVM и связанных с ней пауз сборщика мусора. Совместимость по драйверам высокая, но набор функций и инструменты администрирования совпадают не полностью.