Cassandra полезно понимать не как абстрактный NoSQL-класс, а как очень конкретную архитектурную ставку на доступность, линейный рост записи и проектирование от access patterns.
В реальной системе эта глава помогает проектировать таблицы вокруг partition key, clustering columns и границ партиций, а также подбирать consistency level под бизнес-критичность операции, а не по умолчанию.
На интервью и в архитектурных обсуждениях она дает сильный язык для объяснения, почему Cassandra подходит write-heavy и geo-distributed сценариям, но требует дисциплины на стороне модели чтения и запросов.
Практическая польза главы
Модель по запросам
Проектируйте таблицы от access patterns: partition key, clustering columns и границы партиций.
Tunable consistency
Согласовывайте consistency level с критичностью операции, latency budget и требованиями продукта.
Операционный цикл
Планируйте compaction, repair, tombstones и capacity management как постоянный процесс, а не разовую настройку.
Interview narrative
Показывайте Cassandra как выбор для write-heavy и geo-distributed систем с осознанными ограничениями чтения.
Источник
Apache Cassandra
История, архитектура и особенности Apache Cassandra.
Apache Cassandra - распределенная wide-column база данных, сочетающая идеи Dynamo и Bigtable. Она создана для масштабирования и высокой доступности, а консистентность настраивается под требования системы.
Специфика Cassandra
Wide-column store
Данные организованы в keyspace и таблицы, оптимизированные под известные паттерны запросов.
Masterless архитектура
Все узлы равноправны, что устраняет единую точку отказа и повышает доступность.
AP + tunable consistency
Система ориентирована на доступность и устойчивость к разделению, а уровень консистентности настраивается.
Ограничения и компромиссы
- Ограниченная поддержка сложных join и ad-hoc запросов.
- Модель запросов требует заранее продуманной схемы под чтение.
- Оптимально работает с большими объемами и высокими write-нагрузками.
Визуализация архитектуры
Ring Topology
Consistent Hashing
Выберите ключ, чтобы увидеть его распределение по кольцу (RF=3):
Replication Factor = 3
Каждый ключ хранится на 3 узлах: primary node и 2 следующих узла по часовой стрелке.
Write Path
- Клиент -> любая нода (координатор)
- Координатор вычисляет hash(key) -> token
- Token -> primary node + RF-1 реплик
- Параллельная запись на все реплики
История: ключевые вехи
Facebook -> open source
Cassandra была создана в Facebook и открыта для сообщества в 2008 году.
Apache Incubator
Проект перешел в Apache Incubator и стал развиваться как open-source инициатива.
Top-level project
Apache Cassandra стала проектом верхнего уровня.
1.0: первый стабильный мажорный релиз
Закреплён production-ready статус Cassandra как самостоятельной distributed СУБД.
2.0: LWT и развитие CQL
Появляются lightweight transactions (CAS/Paxos) и заметные улучшения модели запросов.
3.0: серьёзный апдейт хранения
Крупные внутренние изменения storage-слоя и улучшения производительности.
4.0: упор на стабильность
Релиз с фокусом на надёжность, предсказуемость и эксплуатационную зрелость.
5.0: SAI и векторные сценарии
Новый мажорный релиз с Storage-Attached Indexes и возможностями для современных поисковых/AI-нагрузок.
IBM и DataStax
Объявлена покупка DataStax компанией IBM, что усиливает enterprise-контур вокруг Cassandra-экосистемы.
Архитектура Cassandra по слоям
Архитектура показывает координатор, репликацию и LSM-подобное хранение с commit log, memtable и SSTable.
Архитектура кластера
Модель данных
DDL vs DML: как проходит запрос
DDL работает со схемой keyspace и таблиц, DML - с данными. Ниже показаны основные шаги для обоих типов запросов.
Как запрос проходит через Cassandra
Сравнение цепочки для DDL (структура) и DML (данные)
Активный шаг
1. Узел принимает запрос
Любой узел кластера может принять DML запрос.
Работа с данными
- DML работает с данными и индексами, не меняя схему.
- Write path оптимизирован для высокой скорости записи.
- Consistency level определяет подтверждение записи.
Почему Cassandra выбирают
- Линейное масштабирование при добавлении узлов.
- Высокая доступность без единой точки отказа.
- Хорошая производительность записи благодаря LSM-подобному хранению.
- Гибкая настройка консистентности для разных сценариев.
Связанные главы
- Database Selection Framework - Как определить, когда Cassandra подходит под write-heavy distributed workload, а когда лучше выбрать другой тип хранилища.
- Репликация и шардинг - Практические решения для replica placement, balancing и управления отказами в распределённом data-слое.
- CAP теорема - Базовый контекст про компромиссы доступности и консистентности, на которых строится архитектура Cassandra.
- PACELC теорема - Расширение CAP для оценки latency/consistency в штатном режиме и выбора уровня tunable consistency.
- Jepsen и модели консистентности - Как проверять реальные гарантии распределённых баз данных под сетевыми сбоями и partition-сценариями.
- Key-Value Database - Case study по проектированию распределённого KV-слоя с partitioning/quorum, близкого к классу задач Cassandra.