Оригинал
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 (по hash) и 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 данных и географически распределённых систем