Книга по Cassandra особенно полезна тогда, когда нужно перестать видеть в ней просто AP-ярлык из CAP-диаграммы и начать мыслить ее через реальную модель записи, хранения и отказов.
В инженерной практике она помогает связать tunable consistency, партиционирование, LSM-хранение и модель запросов с конкретными требованиями продукта, где доступность и линейный рост записи важнее универсальности запросов.
На интервью и в архитектурных обсуждениях эта глава сильна тем, что позволяет честно обозначить границы Cassandra: она отлично решает одни классы задач, но требует отдельных паттернов там, где ждут ad-hoc запросы или жесткую консистентность.
Практическая польза главы
AP-first мышление
Используйте Cassandra там, где приоритет — доступность и линейное масштабирование записи при сетевых разделениях.
Data model by query
Проектируйте таблицы от бизнес-запросов: правильный partition key критичен для latency и равномерности нагрузки.
Operational discipline
Закладывайте процессы repair, compaction tuning и мониторинга tombstones как часть архитектурного контракта.
Interview limitations
Честно обозначайте ограничения: сложные ad-hoc запросы и строгая консистентность обычно требуют дополнительных паттернов.
Оригинал
Telegram: book_cube
Оригинальный пост с разбором Cassandra.
Cassandra: The Definitive Guide, 3rd Edition
Авторы: Jeff Carpenter, Eben Hewitt
Издательство: O'Reilly Media, Inc.
Объём: 426 страниц
Wide Column Store: архитектура Bigtable + Dynamo, tunable consistency, LSM-Tree, Gossip Protocol. Классификация AP (CAP) и PA/EL (PACELC).
Apache Cassandra — одна из самых известных NoSQL баз данных, объединившая лучшее от двух миров: модель данных Google Bigtable и распределённую архитектуру Amazon Dynamo. Разберём её архитектуру, модель консистентности и место в классификации CAP/PACELC.
Происхождение: Bigtable + Dynamo
Google Bigtable
От Bigtable Cassandra взяла:
- Wide Column модель данных
- LSM-Tree для хранения (MemTable → SSTable)
- Append-only записи в Commit Log
Amazon Dynamo
От Dynamo Cassandra унаследовала:
- Consistent Hashing для распределения
- Gossip Protocol для обнаружения узлов
- Tunable Consistency (настраиваемая консистентность)
Визуализация архитектуры
Ring Topology
Consistent Hashing
Выберите ключ, чтобы увидеть его распределение по кольцу (RF=3):
Replication Factor = 3
Каждый ключ хранится на 3 узлах: primary node и 2 следующих узла по часовой стрелке.
Write Path
- Клиент -> любая нода (координатор)
- Координатор вычисляет hash(key) -> token
- Token -> primary node + RF-1 реплик
- Параллельная запись на все реплики
Связанная глава
CAP теорема
Фундаментальное ограничение распределённых систем: C, A, P.
Cassandra и CAP теорема
Availability + Partition Tolerance
Cassandra — AP система по умолчанию
При сетевом разделении Cassandra предпочитает оставаться доступной, даже если это означает возврат потенциально устаревших данных. Это делает её идеальной для сценариев, где доступность критичнее строгой консистентности.
Tunable Consistency
Уникальная особенность: Cassandra позволяет настраивать уровень консистентности на уровне каждого запроса. С настройками QUORUM или ALL можно получить поведение ближе к CP.
Связанная глава
PACELC теорема
Расширение CAP: компромиссы в штатном режиме.
Cassandra и PACELC
Partition → Availability, Else → Latency
Скорость превыше консистентности
Выбирает Availability — продолжает обслуживать запросы, даже если часть реплик недоступна.
Выбирает Low Latency — не ждёт подтверждения от всех реплик.
Это объясняет, почему Cassandra использует eventual consistency даже когда сеть работает нормально — не из-за страха partition'ов, а ради минимальных задержек.
Связанная глава
Паттерны консистентности и идемпотентность
Практические модели консистентности, идемпотентные операции и trade-offs.
Уровни консистентности
Cassandra предлагает спектр уровней консистентности — от максимальной скорости до строгой согласованности:
Запись считается успешной, даже если сохранена только в hinted handoff.
Достаточно ответа от одной реплики. Быстро, но может вернуть stale data.
Требует ответа от большинства реплик (RF/2 + 1). Баланс скорости и консистентности.
Требует ответа от всех реплик. Максимальная консистентность, минимальная доступность.
Linearizable consistency через Paxos. Для Lightweight Transactions (CAS операций).
Формула сильной консистентности: если W + R > RF, где W — consistency level записи, R — чтения, RF — replication factor, то гарантируется чтение последней записанной версии.
Связанная глава
Репликация и шардинг
Как выбирать стратегию шардирования, держать баланс шардов и масштабировать запись/чтение.
Архитектура
LSM-Tree Storage
1. Записи идут в Commit Log (durability)
2. Данные накапливаются в MemTable (in-memory)
3. Периодически flush в SSTable (immutable on disk)
4. Фоновый Compaction объединяет SSTables
Распределение данных
• Consistent Hashing — ключ → token → node
• Virtual Nodes (vnodes) — равномерное распределение
• NetworkTopologyStrategy — rack/DC awareness
• Replication Factor — количество копий
Gossip Protocol
• Peer-to-peer обнаружение узлов
• Phi Accrual Failure Detector
• Нет single point of failure
• Каждую секунду обмен с 1-3 узлами
Отказоустойчивость
• Hinted Handoff — временное хранение для недоступных нод
• Read Repair — исправление при чтении
• Anti-Entropy Repair — фоновая синхронизация
• Merkle Trees — эффективное сравнение данных
Когда использовать Cassandra
✓ Хорошо подходит
- Time-series данные (IoT, метрики, логи)
- Высокая пропускная способность записи
- Географически распределённые системы
- Когда доступность важнее консистентности
- Messaging и activity feeds
✗ Не лучший выбор
- ACID транзакции между записями
- Сложные JOIN'ы и аналитика
- Часто меняющиеся схемы данных
- Малые объёмы данных (<100GB)
- Высокие требования к read latency
История
Подробную историю Cassandra можно посмотреть в главе «Cassandra: архитектура и компромиссы» — ссылка ведет сразу к таймлайну.
Сегодня Cassandra используется в крупных production-системах (Netflix, Apple, Uber и др.) как база для write-heavy и геораспределённых сценариев.
Ключевые выводы
- 1.Cassandra — AP система по CAP и PA/EL по PACELC: приоритет доступности и низкой задержки
- 2.Tunable consistency позволяет балансировать между скоростью и согласованностью на уровне каждого запроса
- 3.Архитектура без master-узла: все ноды равноправны благодаря Gossip Protocol
- 4.LSM-Tree обеспечивает высокую пропускную способность записи за счёт последовательных операций на диске
- 5.Идеальна для write-heavy нагрузок, time-series данных и географически распределённых систем
Связанные главы
- CAP теорема - Базовая рамка для понимания, почему Cassandra в partition-сценариях выбирает availability и как это влияет на продуктовые SLA.
- PACELC теорема - Расширение CAP, объясняющее компромисс Cassandra между latency и consistency даже при нормальной работе сети.
- Cassandra: архитектура и компромиссы - Практический обзор эволюции, исторического контекста и production-паттернов эксплуатации Cassandra-кластеров.
- Репликация и шардинг - Операционные принципы, которые помогают проектировать RF, placement и rebalance для Cassandra в больших инсталляциях.
- Jepsen и модели консистентности - Проверка гарантий распределённых систем под отказами и как интерпретировать consistency-поведение Cassandra на практике.
- Database Selection Framework - Фреймворк выбора СУБД, который помогает обосновать Cassandra для write-heavy и geo-distributed нагрузок.