## Зачем нужно знать Cassandra — оригинальный leaderless wide-column store, спроектированный в Facebook (2008) на пересечении идей Dynamo (Amazon, 2007) и Bigtable (Google, 2006). Сегодня знание Cassandra — это базовый класс для понимания целого семейства систем: ScyllaDB, AstraDB, Bigtable, HBase, частично DynamoDB. Три причины разобраться. - **Это canonical AP-система в учебнике распределённых БД.** Каждая концепция, которую обсуждают в DDIA и на собеседованиях по System Design — consistent hashing, tunable consistency, gossip, hinted handoff, read repair, vector clocks / last-write-wins, anti-entropy через Merkle tree — реализована в Cassandra в чистом, читаемом виде. Если вы понимаете write path Cassandra при `RF=3, CL=QUORUM`, вы понимаете 80% теории distributed databases. - **Это рабочая лошадка write-heavy workloads на масштабе.** Apple, Netflix, Discord (до миграции на Scylla), Instagram, Uber, Spotify держат на Cassandra (или её прямом потомке) триллионы записей. Любой инфраструктурный инженер в large-scale company рано или поздно сталкивается с production Cassandra/Scylla кластером — миллион rps writes, multi-DC active-active, partition'ы по сотням мегабайт. Понимание модели — деньги и спасённые ночи. - **Это шаблон для оценки альтернатив.** ScyllaDB продаёт себя как «Cassandra без JVM» (5-10× throughput на ноду). DynamoDB продаёт себя как «Cassandra без операций» (managed, но vendor lock-in). YDB и CockroachDB говорят «Cassandra-like availability + ACID». Без знания базовой модели нельзя осмысленно сравнивать. Дорогой урок: команды приходят из Postgres и пытаются использовать Cassandra «как SQL без транзакций» — нормализованные таблицы, JOIN client-side, `ALLOW FILTERING` в каждом query. Потом обнаруживают tombstone hell, scatter-gather по всему кластеру, p99 в секундах. Этот документ — про то, как сразу не наступить. ## Mental model > «Cassandra — это **leaderless ring of LSM-нод** с tunable quorum. Дизайн схемы начинается от queries (denormalize всё), partition key выбирает ноду через consistent hashing, clustering key сортирует rows внутри партиции, а background compaction постоянно пересобирает SSTables. Под капотом — Dynamo (распределение) + Bigtable (storage engine).» Три измерения, в которых принимаются все решения: 1. **Replication factor (RF) + consistency level (CL).** RF задаётся на уровне keyspace (обычно 3 per DC), CL — на каждый запрос. Правило `R + W > N` — единственный способ получить strong consistency для одного ключа. Всё остальное — eventual с разным lag. 2. **Schema = access pattern.** В Cassandra нет JOIN, нет произвольных WHERE, нет вторичных индексов (точнее, есть, но почти всегда anti-pattern). Каждая таблица проектируется под один query. Одни и те же данные могут лежать в 3-5 таблицах с разными partition keys — это нормально. 3. **Operational discipline.** Cassandra прощает мало: забыли `nodetool repair` в течение `gc_grace_seconds` (10 дней) — получаете «zombie data» (удалённые rows возвращаются). Не следите за wide partitions (>100 MB) — compaction страдает, p99 деградирует. Не настроили compaction strategy под workload — read amplification растёт линейно с числом SSTables. Любое решение по Cassandra — точка в этом пространстве. `LOCAL_QUORUM` reads + `LOCAL_QUORUM` writes на RF=3 (multi-DC), STCS для write-heavy / LCS для read-heavy / TWCS для time-series, `nodetool repair` раз в неделю — это не «опции», это обязательный production baseline. ## Что показывает диаграмма На канвасе — типовая Cassandra installation: один DC, кластер из пяти нод, RF=3. - **CQL driver (token-aware)** слева — клиент, который знает топологию кластера и партиционер; для каждого запроса выбирает координатором ноду, ближайшую к owner ключа (экономит один internal hop). - **Ring (5 нод)** в центре — все ноды равноправны (`node-1` ... `node-5`), у каждой свой token range на консистентном хеш-кольце `[0, 2^64)`. Ключ → токен → ближайший по часовой стрелке owner + следующие RF-1 реплики. Edges между нодами — представление gossip-меша (каждая нода обменивается digest'ом со случайным peer каждую секунду; полный mesh не рисуем, чтобы не загромождать). - **LSM internals на node-2** снизу — учебный «разрез» одной реплики: `CommitLog` (WAL, fsync перед ack), `Memtable` (in-RAM sorted skiplist), `Bloom filter` (in-RAM, false positive ~1%, отсекает SSTables, в которых ключа точно нет), три SSTable (immutable on-disk, newest first). Compaction — фоновая операция, на схеме обозначена edges sst1 → sst2 → sst3. Edges: - `client → n1` — CQL соединение, n1 в этом примере выступает координатором. - `n1 ↔ n2/n3/n4/n5` плюс другие пары — gossip-меш (peer-to-peer). - Внутри node-2: `n2 → commitlog` (fsync), `n2 → memtable` (insert), `memtable → sst1` (flush), `n2 → bloom → sst1/sst2/sst3` (read path), `sst1 → sst2 → sst3` (compaction). Каждая нода в реальности — это копия этой LSM-структуры. На диаграмме показан только один «срез», чтобы не повторять одно и то же пять раз. ## Сценарии и что они учат ### `write-quorum` — Канонический write path при CL=QUORUM Client → coordinator (n1) → `hash(partition_key)` → token=147 → owners: n3 (primary), n5, n2. Coordinator отправляет мутацию **параллельно** всем трём; на каждой реплике сначала `CommitLog` (fsync ~1ms), потом `Memtable` (in-RAM insert). Как только 2 из 3 acks дошли — coordinator отвечает клиенту OK. Третий ack приходит async, не блокирует latency. Когда memtable наполняется (~256 MB) — фоновый flush в SSTable. Чему учит: **`R + W > N` — единственная формула, которую надо помнить**. R=2, W=2, N=3 → любой последующий read с CL=QUORUM пересечётся хотя бы с одной репликой, видевшей write. Это и есть «strong consistency для одного ключа». CL=ONE даёт ~1ms latency, но stale reads возможны; CL=ALL даёт максимум consistency, но availability падает до AND всех реплик — одна нода вниз = writes fail. ### `read-repair` — Async-коррекция стейла во время чтения Coordinator (n1) для CL=QUORUM выбирает 2 ближайшие реплики: с n3 запрашивает full row, с n5 — только digest (md5 hash для bandwidth-efficient compare). Digest не сходится — n5 stale. Coordinator делает второй запрос (full row) к n5, видит timestamp T1 < T2 (n3 новее), резолвит last-write-wins, возвращает клиенту свежее значение. **Параллельно** отправляет n5 мутацию-починку через нормальный write path. Клиент про divergence не знает. Чему учит: **last-write-wins по timestamp — основной (и единственный из коробки) механизм разрешения конфликтов в Cassandra.** Это работает только если у нод синхронизированные часы (NTP обязателен, clock skew = silent data corruption). `read_repair_chance` (default <1.0) означает, что не каждое чтение триггерит repair — поэтому **`nodetool repair` раз в неделю обязателен**, иначе entropy накапливается и tombstone'ы могут expire'нуть до того, как достигнут отстающей реплики (= deleted data возвращается, «zombie»). ### `hinted-handoff` — Availability во время partition `n5` падает (или партиция изолирует n1 от n5). Клиент шлёт write с CL=QUORUM на тот же ключ. Coordinator (n1) пытается отправить мутацию на n2, n3, n5; первые две успешны, n5 — connection refused. Coordinator **локально** записывает «hint»: «доставить эту мутацию на n5, когда она снова жива». W=2 удовлетворено, клиент получает OK — availability сохранена несмотря на отказ узла. Когда n5 поднимается, gossip распространяет ALIVE state за O(log N) раундов; n1 читает свой hint store и проигрывает накопленные мутации. Если n5 отсутствует дольше `max_hint_window_in_ms` (default 3 часа) — hints выбрасываются, единственный механизм reconciliation — `nodetool repair`. Чему учит: **это и есть «AP» в CAP.** Под partition Cassandra предпочитает принять write (с локальным hint) и догнать позже, а не отказать. Trade-off: hint живёт на coordinator'е; если coordinator падает до доставки hint'а — hint потерян. Финальная сетка безопасности — periodic `nodetool repair` строго **до** истечения `gc_grace_seconds` (10 дней по умолчанию). ## Trade-offs ### ADR-001: Masterless ring vs leader-based replication **Status:** accepted. **Context.** Два мира распределённой OLTP. Leader-based (Postgres streaming, MongoDB replica set, MySQL Group Replication, Spanner / CockroachDB на уровне range): один узел координирует writes per shard, простая ментальная модель, легко получить strong consistency и ACID, но failover занимает секунды/минуты, лидер — потолок write throughput. Leaderless / masterless (Dynamo, Cassandra, Riak, ScyllaDB): каждый узел принимает каждый write, реплицирует на N peers, никакого failover не нужно — некого терять. Цена: tunable-не-default consistency, last-write-wins резолюция конфликтов, обязательные read-repair и `nodetool repair` для борьбы с entropy. **Decision.** Masterless выбираем когда: (1) write throughput выше чем способен сустейнить один primary (Discord держал ~120M сообщений/день до миграции на Scylla), (2) multi-DC active-active (active-active с leader'ом — это уже Spanner/CockroachDB класс), (3) толерантность к single-node failure без паузы на election. Cassandra явно выбирает AP в CAP: при partition каждая minority-партиция продолжает принимать writes (с hint'ами), reconciliation позже по timestamp. Это **неправильно** для inventory или balances; **правильно** для messages, time-series, sensor data, write-heavy логов и фидов. **Consequences.** Никакой ACID-транзакции «из коробки» — есть только LWT (Paxos round, 4× latency) для compare-and-set на одной партиции. Никакого referential integrity. Schema design жёстко привязан к access pattern. Operational ответственность смещена с «failover automation» (как у leader-based) на «anti-entropy hygiene» — repair, compaction tuning, monitoring tombstones. ### ADR-002: Cassandra vs ScyllaDB vs DynamoDB **Status:** accepted (per-workload). **Context.** Три wide-column store с одинаковой data model и кардинально разным operational профилем. **Cassandra** — Java, JVM GC pauses, зрелый OSS, runs anywhere; default-выбор когда нужен контроль над железом. **ScyllaDB** — C++ переписка на Seastar framework, per-core sharding (shared-nothing), DPDK NIC, нет GC; drop-in CQL replacement, ~5-10× throughput per node, ~5× ниже p99. Discord в 2022 мигрировал message store с 177 Cassandra нод на 72 Scylla. **DynamoDB** — AWS managed, проприетарный, pay-per-request или provisioned; ноль operations, auto-sharding, multi-region Global Tables — но lock-in, дорогой выше ~50K rps, нет CQL/SQL (только GetItem/Query). **Decision.** Дерево решений: | Условие | Выбор | |---|---| | AWS-shop, <50K rps sustained, want zero ops | **DynamoDB** | | On-prem / multi-cloud / >100K rps, команда комфортна с CQL | **ScyllaDB** | | Нужен максимум ecosystem (Spark, Solr/Elastic через DSE), есть Cassandra ops expertise, или железо с очень малым числом cores где per-core модель Scylla проигрывает | **Cassandra** | В 2026 году **выбор Cassandra для greenfield large-scale deployment без серьёзной оценки ScyllaDB — anti-pattern**: тот же API, кардинально лучше $/rps. DynamoDB anti-pattern: hot partition (один key >3K rps) silently throttles, нет способа вырастить per-key throughput без redesign схемы. **Consequences.** Переход Cassandra ↔ Scylla — смена бинарника, не приложения (CQL совместимость). Переход на/с DynamoDB — переписывание data access layer (нет CQL). Команды должны оценивать **полный TCO** включая ops headcount, не только лицензию/cloud bill. ### ADR-003: Tunable consistency — `LOCAL_QUORUM` как production default **Status:** accepted. **Context.** Cassandra выставляет CL per-query: ONE, TWO, THREE, QUORUM, ALL + DC-aware варианты LOCAL_ONE, LOCAL_QUORUM, EACH_QUORUM, ANY. Математика: если R + W > N (реплики) для одного ключа — strong consistency для этого ключа. CL=ONE — самый быстрый (один ack), stale reads возможны. CL=ALL — самый строгий, но любая нода вниз = ошибка. QUORUM = floor(N/2)+1, толерирует 1 ноду вниз на RF=3. EACH_QUORUM — QUORUM в каждом DC, durable но добавляет cross-DC RTT. **Decision.** Production default на multi-DC кластере — **`LOCAL_QUORUM` на чтение и запись**. Причины: (1) толерирует одну ноду вниз per DC без потери writes, (2) избегает cross-DC WAN на каждой операции (это +50-150ms p99), (3) даёт R+W>N внутри локального DC — read-your-writes within DC. Trade-off: write, успешный в DC-A, может ещё не быть реплицирован в DC-B; subsequent LOCAL_QUORUM read в DC-B может вернуть stale до прибытия async replication (обычно <1s). Для глобально-строгих требований (например, уникальность email при регистрации) — LWT (Paxos, 4× latency) или внешний координатор. CL=ONE — только для analytics / observability writes где потеря приемлема; CL=ALL — только для одноразовых admin операций (availability проседает до AND всех реплик). **Consequences.** App-код должен явно документировать места, где CL ≠ LOCAL_QUORUM. LWT — silver bullet, но 4× медленнее обычного write; не использовать на high-throughput путях. На multi-DC active-active дизайн должен учитывать: один и тот же ключ может одновременно меняться в двух DC, last-write-wins по timestamp решит конфликт (= тихая потеря). ## Реальные системы - **Apple** — крупнейший Cassandra deployment в мире, десятки тысяч нод, multiple workloads (iCloud metadata, iMessage backend, push notifications). Часто публикует талки на Cassandra Summit. - **Discord** — trillions of messages, до 2022 на Cassandra, с 2022 на ScyllaDB (Java GC pauses не масштабировались, миграция дала 2-3× меньше нод и предсказуемый p99). См. их blog post «How Discord Stores Trillions of Messages». - **Netflix** — viewing history, recommendations metadata, multiple write-heavy сервисы. Внесли существенный вклад в Cassandra (Priam, Aegisthus). Один из крупнейших публично известных deployments. - **Instagram** (исторически) — heavy Cassandra usage до миграции части на Postgres+Cassandra mix. - **Uber** — изначально Cassandra, потом Schemaless поверх MySQL для большинства транзакционных workloads. Cassandra оставлена для time-series и аналитики. - **Spotify** — рекомендации, история прослушиваний, user playlists. - **eBay** — каталог, ad serving, поведенческие данные. - **GitHub** — Pages, audit log. - **Bloomberg** — финансовые time-series. - **Walmart Labs** — каталог и inventory metadata (не сам inventory — для него ACID-системы). Общий паттерн: **write-heavy, schema стабильна, eventual consistency приемлема, нужен многонодовый scale без single-leader bottleneck**. Большинство этих компаний сегодня либо мигрировали часть на ScyllaDB (Discord), либо рассматривают, либо построили внутренние Cassandra-like решения (Uber Schemaless, FB Tao). ## Anti-patterns - **Wide partitions (>100 MB или >100K rows).** Partition целиком лежит на одной ноде, читать её — один disk scan; compaction должна перетасовать всё. Решение: bucketing — `PRIMARY KEY ((user_id, YYYY-MM), message_id)`. - **`ALLOW FILTERING` в production.** Делает scatter-gather по всему кластеру — каждая нода сканирует свои SSTables. Латентность в секундах, нагрузка на весь кластер. Если query не помещается в `(partition_key, clustering_key)` — нужна **другая таблица** с другим PK, не FILTERING. - **Secondary indexes на high-cardinality columns.** Cassandra secondary index — это **per-node** структура; query по индексу = scatter-gather, ровно как FILTERING. Использовать только для low-cardinality columns в queries, ограниченных одним partition. Иначе — denormalize в отдельную таблицу. - **Heavy DELETE workload без TWCS.** Каждый DELETE = вставка tombstone, который живёт `gc_grace_seconds` (10 дней). Range read с >100K tombstones → query fails. Для time-series — TWCS + TTL, чтобы старые window выбрасывались целиком. - **Не запускать `nodetool repair`.** В течение `gc_grace_seconds` (10 дней) каждая реплика должна получить tombstone. Иначе tombstone expire'ит локально, потом приходит «оживший» row с старой реплики → zombie data. Repair раз в 5-7 дней — обязательная фоновая работа. - **Multi-DC без `LOCAL_QUORUM`.** Каждое чтение через WAN = +50-150ms p99. Используйте LOCAL_QUORUM по умолчанию, EACH_QUORUM только когда globally durable обязательно. - **`ConsistencyLevel=ONE` для критичных writes.** Один ack ≠ durable — если получившая нода падает до replication, write потерян. ONE приемлемо для observability/analytics, не для бизнес-логики. - **LWT (Paxos) на каждый write.** `IF NOT EXISTS` и `IF column=X` — 4× latency из-за Paxos round (prepare → propose → commit). Использовать точечно (regional uniqueness, idempotency на критичных операциях). - **Counter columns на high-throughput пути.** Counters имеют отдельный write path (read-before-write), медленнее обычных writes. Для real-time счётчиков лучше Redis + периодическая консолидация. - **Cassandra как маленький KV (<100 GB).** На таком объёме Postgres / MongoDB replica set дешевле, проще, гибче. Cassandra оправдывается на 10+ TB и/или write-heavy multi-DC. - **Bootstrap новой ноды на 5+ TB.** Streaming данных от neighbors занимает часы-сутки, всё это время кластер degraded. Держите ноды 1-2 TB. - **Schema changes без осторожности.** ALTER распространяется через gossip, **не атомарно**. Одновременный DDL с двух клиентов = schema disagreement, requires manual repair. Schema migrations — через одну ноду, по одной операции, с паузой. ## Когда НЕ использовать - **Workload требует ACID транзакций на нескольких rows/partitions.** Cassandra даёт only single-row atomicity + LWT на одну partition. Для multi-row ACID — Postgres / Spanner / CockroachDB / YDB. - **Часто меняющиеся access patterns / ad-hoc analytics.** Cassandra schema жёстко привязан к queries. Каждый новый pattern = новая таблица или GSI. Если требования зыбкие — Postgres (или строить отдельный аналитический сторадж: ClickHouse, Snowflake). - **Маленький dataset (<100 GB).** Overkill. Replica set Mongo / Postgres standby проще, дешевле, без операционного бремени repair/compaction. - **Сложные JOIN-heavy queries.** В Cassandra JOIN не существует. Денормализация = duplication × write amplification. Если данные реально реляционные — RDBMS. - **Strict global consistency.** Multi-DC Cassandra с LOCAL_QUORUM = eventually consistent через DC. LWT — только в пределах одной partition в одном DC. Для globally strict — Spanner / CockroachDB. - **Workload с >50% deletes.** Tombstone hell неизбежен. Если данные с TTL — TWCS работает, но если delete как часть бизнес-логики (CRUD app) — Cassandra плохой выбор. - **Full-text search, vector search, graph queries.** Не профиль Cassandra. Elastic / OpenSearch / pgvector / Neo4j. - **Команда без operational expertise.** Cassandra **прощает мало**. Нужны люди, понимающие compaction, repair, GC tuning, monitoring через nodetool. Без этого кластер деградирует за месяцы. Managed варианты (Astra DB, AWS Keyspaces) частично решают, но снимают и часть control. - **Greenfield в 2026 без оценки ScyllaDB.** Тот же API, кардинально лучше throughput/$. Cassandra оправдана только если есть существующая ops-экспертиза или specific ecosystem зависимости. ## Дальше читать - **«Cassandra — A Decentralized Structured Storage System» (Lakshman & Malik, LADIS 2009)** — оригинальная статья, читается легко: - **«Dynamo: Amazon's Highly Available Key-value Store» (DeCandia et al., SOSP 2007)** — фундамент leaderless replication, на котором стоит Cassandra: - **«Bigtable: A Distributed Storage System for Structured Data» (Chang et al., OSDI 2006)** — origin LSM + wide-column модели: - **Cassandra: The Definitive Guide, 3rd ed. (Carpenter, Hewitt)** — bible. Если делаешь Cassandra всерьёз — обязательно. - **Database Internals (Petrov), главы 11-13** — distributed storage, anti-entropy, gossip, consensus. Лучший учебник по теории, лежащей под Cassandra. - **DDIA (Kleppmann), главы 5-6** — Replication, Partitioning. Базовый теоретический минимум. - **Apache Cassandra docs:** - **DataStax docs:** — более structured, с production guidance. - **Discord — How Discord Stores Trillions of Messages:** — самый известный case-study миграции с Cassandra на ScyllaDB. - **Discord — How Discord Stores Billions of Messages (Cassandra era):** — что они делали до миграции и почему упёрлись. - **Netflix tech blog — Cassandra tag:** — годы production wisdom. - :concept{slug="cap-theorem"} — почему Cassandra по умолчанию AP и что это значит при partition. - :concept{slug="quorum-reads-writes"} — формула R+W>N и tunable consistency в общем виде. - :concept{slug="gossip-protocol"} — peer-to-peer membership propagation, на котором держится ring. - :concept{slug="b-tree-vs-lsm"} — почему storage engine у Cassandra именно LSM, а не B-tree. - :concept{slug="consistent-hashing"} — token ring и vnodes. - :concept{slug="replication"} — sync/async, leader/leaderless, quorum — теоретический фон. - :case{slug="twitter-system-design"} — где timeline-like write-heavy access pattern идеально ложится на Cassandra/Scylla.