Cassandra od środka

Twój mózg jest leniwy w bardzo sprytny sposób: zapamiętuje to, co dziwne, wizualne i emocjonalne, a wyrzuca nudne listy parametrów konfiguracyjnych. Dlatego zamiast suchej dokumentacji dostajesz tu diagramy, które same się animują, pogawędki komponentów bazy danych i pytania, które zmuszą Cię do myślenia. Merytorycznie nie odpuszczamy jednak niczego: po lekturze powinieneś umieć wyjaśnić, dlaczego Cassandra zachowuje się tak, jak się zachowuje, a nie tylko że tak robi.

Każdy diagram ze znaczkiem ▶ startuje sam, gdy wjedzie na ekran, ale możesz go też klikać, psuć i resetować. Najwięcej nauczysz się, psując: wyłączaj węzły, zmieniaj poziomy spójności, zapominaj o naprawach i patrz, co się stanie.

Klasyczna replikacja master–slave jest prosta: wszystkie zapisy idą do jednego serwera, który rozsyła je do kopii. Prosta aż do chwili, gdy master padnie. Wtedy zapisy stoją, dopóki ktoś (człowiek albo automat typu failover) nie wybierze nowego szefa — a jeśli wybierze dwóch naraz, masz split brain. Do tego master jest wąskim gardłem: wszystkie zapisy przechodzą przez jeden serwer, więc dokładanie maszyn nie zwiększa przepustowości zapisu.

Cassandra jest masterless / peer-to-peer: każdy węzeł może przyjąć dowolne zapytanie (staje się wtedy jego koordynatorem), każdy zna topologię klastra, każdy przechowuje fragment danych. Nie ma pojedynczego punktu awarii i nie ma specjalnych ról — nawet „seed nodes”, o których jeszcze usłyszysz, to tylko adresy kontaktowe, a nie szefowie.

Każdy wiersz w Cassandrze ma klucz partycji (partition key). Domyślny partitioner, Murmur3Partitioner, zamienia go na 64-bitową liczbę — token — z zakresu od −2⁶³ do 2⁶³−1. Wyobraź sobie ten zakres zwinięty w okrąg: to jest pierścień (ring). Każdy węzeł ma na nim swój token i jest właścicielem zakresu od tokena poprzednika (wyłącznie) do własnego (włącznie). Żeby znaleźć właściciela klucza, idziesz od jego tokena zgodnie z ruchem wskazówek zegara do pierwszego napotkanego węzła.

Dlaczego nie zwykłe hash(klucz) mod N? Bo zmiana N przetasowuje prawie wszystko: przy przejściu z 6 na 7 serwerów ~86% kluczy zmienia właściciela, a każdy przeprowadzany klucz to dane przesyłane przez sieć. W consistent hashingu nowy węzeł rozcina jeden zakres — przeprowadzają się tylko klucze z kawałka między nim a jego poprzednikiem. Kliknij „Dodaj węzeł G” i porównaj liczby.

Jeden token na serwer ma dwie wady. Po pierwsze, zakresy wychodzą nierówne, więc jeden węzeł dźwiga dwa razy więcej danych niż sąsiad. Po drugie, gdy węzeł padnie, cały jego zakres przejmuje jeden sąsiad (i tylko on streamuje dane do zastępcy). Rozwiązanie z Cassandry 1.2: każdy fizyczny węzeł dostaje wiele tokenów — vnodes. Liczbę ustawia num_tokens (kiedyś domyślnie 256, od Cassandry 4.0 domyślnie 16 w połączeniu z inteligentnym algorytmem przydziału tokenów allocate_tokens_for_local_replication_factor).

Replication factor (RF) mówi, ile kopii każdego wiersza trzyma klaster. RF ustawia się na poziomie keyspace’u razem ze strategią replikacji. Pierwsza replika trafia do właściciela tokena, a kolejne — do następnych węzłów idąc zgodnie z zegarem. Tu zaczyna się różnica między strategiami:

• SimpleStrategy — bierze po prostu kolejne RF węzłów. Dobre tylko na laptopa, bo nie wie nic o szafach i serwerowniach.
• NetworkTopologyStrategy — RF osobno dla każdego centrum danych (np. {'dc1': 3, 'dc2': 2}); idąc po pierścieniu, pomija węzły z DC, które ma już komplet, i stara się rozkładać repliki po różnych rackach (szafach). To jest wybór produkcyjny.

CREATE KEYSPACE sklep WITH replication = {
  'class': 'NetworkTopologyStrategy', 'dc1': 3, 'dc2': 2
};

Skąd Cassandra wie, który węzeł jest w którym DC i racku? Od snitcha. W produkcji używa się GossipingPropertyFileSnitch: każdy węzeł czyta swoje DC i rack z pliku cassandra-rackdc.properties i ogłasza je reszcie przez gossip. Nad nim zawsze działa dynamic snitch, który mierzy opóźnienia replik i przy odczytach omija wolniejsze („ten węzeł ma właśnie GC pause — zapytajmy inną replikę”).

Skoro nie ma centralnego rejestru, skąd węzły wiedzą, kto żyje, jakie ma tokeny, w którym jest DC i jaką wersję schematu? Z plotek. Co sekundę każdy węzeł wybiera losowo jednego żywego rozmówcę (czasem dodatkowo węzeł uznany za martwy i seed) i wymienia się z nim stanem w trzech wiadomościach: GossipDigestSyn → GossipDigestAck → GossipDigestAck2. Każda informacja ma wersję (para generation — czas startu węzła — i rosnący version), więc zawsze wiadomo, która jest świeższa.

Magia epidemii: w każdej rundzie liczba „wtajemniczonych” mniej więcej się podwaja, więc informacja dociera do N węzłów po około log₂N rundach. 1000 węzłów? Kilkanaście sekund. Patrz sam:

Wykrywanie awarii to nie „nie odpowiedział 3 razy = martwy”. Cassandra używa Phi Accrual Failure Detector: zamiast binarnej decyzji liczy poziom podejrzenia φ na podstawie historii odstępów między heartbeatami danego węzła. φ rośnie z czasem ciszy (przy odstępach ~1 s: φ ≈ cisza / ln 10); gdy przekroczy phi_convict_threshold (domyślnie 8), węzeł zostaje uznany za DOWN — lokalnie, przez każdego obserwatora osobno. W chmurach z niestabilną siecią podnosi się to do 10–12.

Tajemnica szybkich zapisów: Cassandra nigdy nie nadpisuje danych na dysku w miejscu i nie czyta przed zapisem. Każdy zapis na replice to dwa tanie kroki: dopisanie na koniec commit logu (sekwencyjny zapis — trwałość na wypadek awarii) i wstawienie do memtable (posortowana struktura w pamięci). Potwierdzenie leci do koordynatora. Koniec. Kiedy memtable urośnie, zostaje w całości zrzucona (flush) do nowego, niezmiennego pliku SSTable (Sorted String Table). To właśnie struktura LSM-tree (Log-Structured Merge tree) odziedziczona po Bigtable.

Kiedy replika leży: hinted handoff

Koordynator wysyła zapis do wszystkich replik danego klucza. Jeśli któraś jest DOWN (wie to z gossipu), zapisuje dla niej hint — „przypominajkę” z mutacją — na swoim dysku. Gdy gossip ogłosi, że replika wróciła, koordynator odtwarza jej hinty. Hinty zbiera się tylko przez max_hint_window (domyślnie 3 godziny); węzeł leżący dłużej trzeba naprawić przez nodetool repair. Hint to optymalizacja, nie gwarancja — i (poza CL=ANY) nie liczy się do potwierdzeń zapisu.

Każde zapytanie niesie consistency level (CL): ile replik musi odpowiedzieć, zanim koordynator uzna operację za udaną. Najważniejsze poziomy: ONE, TWO, THREE, QUORUM (⌊RF/2⌋+1 replik), ALL, a dla wielu DC: LOCAL_ONE, LOCAL_QUORUM (kworum tylko w lokalnym DC — najpopularniejszy wybór produkcyjny) i EACH_QUORUM. Dla zapisów jest jeszcze ANY — wystarczy, że ktokolwiek, choćby koordynator jako hint, przyjął zapis.

Magiczna nierówność: jeśli R + W > RF, zbiór replik, które potwierdziły zapis, i zbiór replik czytanych muszą się przeciąć — więc odczyt zobaczy najnowszą potwierdzoną wartość.

Zapisy były tanie, bo niczego nie porządkowaliśmy. Rachunek przychodzi przy odczycie: kawałki jednego wiersza mogą leżeć w memtable i w kilku SSTables (każdy UPDATE innej kolumny to osobny fragment). Replika musi je wszystkie znaleźć i scalić, wybierając dla każdej komórki wartość z najnowszym timestampem. Żeby nie czytać każdego pliku z dysku, każda SSTable ma zestaw pomocników:

1. Filtr Blooma (Filter.db, w RAM) — probabilistyczne „na pewno nie ma” albo „może jest”.
2. Key cache — pamięta pozycje ostatnio czytanych partycji w pliku.
3. Partition summary (próbka indeksu w RAM) → partition index (Index.db) — gdzie w pliku zaczyna się partycja. (Cassandra 5.0 ma też nowy format BTI oparty na drzewach trie: Partitions.db/Rows.db.)
4. Compression offsets (CompressionInfo.db) — który skompresowany blok (domyślnie 16 KiB) trzeba rozpakować.
5. Wreszcie dane (Data.db).

Filtr Blooma nigdy nie kłamie w stronę „nie ma” — jeśli choć jeden z bitów klucza jest zerem, klucza na pewno nie dodano. Może natomiast fałszywie powiedzieć „może jest”. Prawdopodobieństwo ustawia bloom_filter_fp_chance (typowo 0.01; im mniej, tym więcej RAM-u). Tu kompletny odczyt klucza id=42 na jednej replice:

Poziom wyżej: koordynator i read repair

Przy CL wyższym niż ONE koordynator prosi jedną (najszybszą według dynamic snitcha) replikę o pełne dane, a pozostałe tylko o digest — hash wyniku. Jeśli hashe się zgadzają, odsyła wynik. Jeśli nie — pobiera pełne dane od wszystkich pytanych, scala je (najnowszy timestamp wygrywa) i przed odpowiedzią dopisuje brakujące wersje do przestarzałych replik. To jest blocking read repair (w Cassandrze 4.0 usunięto dawne losowe „read_repair_chance”; zostało naprawianie tego, co wyszło przy okazji odczytu). Dodatkowo speculative retry (domyślnie 99p) wysyła zapytanie do kolejnej repliki, jeśli pierwsza odpowiada wolniej niż 99. percentyl. Możesz to zobaczyć w laboratorium spójności z rozdziału 7.

Każdy flush dokłada nową SSTable. Bez sprzątania po tygodniu miałbyś ich tysiące, a każdy odczyt dotykałby dziesiątek plików. Kompakcja bierze kilka SSTables, scala je sortowaniem przez scalanie (merge sort — tanie, bo pliki już są posortowane), wybiera najnowsze wersje komórek, wyrzuca nadpisane dane i przedawnione tombstony, i zapisuje nowy plik. Stare są usuwane. Każda strategia to kompromis między trzema „wzmocnieniami”:

• read amplification — ile SSTables trzeba przejrzeć przy odczycie,
• write amplification — ile razy te same bajty są przepisywane na dysk,
• space amplification — ile dodatkowego miejsca zajmują duplikaty i sama kompakcja (STCS potrafi potrzebować chwilowo 2× miejsca!).

Skoro SSTables są niezmienne, DELETE nie może niczego wymazać. Zamiast tego zapisuje tombstone — znacznik „ta komórka / wiersz / zakres / partycja jest usunięta od timestampu T”. Przy odczycie tombstone przesłania starsze dane, a przy kompakcji dane i nagrobek w końcu znikają. Tombstony powstają też, gdy:

• wygasa TTL (komórka zamienia się w tombstone),
• wstawiasz null do kolumny (tak, INSERT … VALUES (…, null) tworzy tombstone!),
• nadpisujesz całą kolekcję (SET tags = {…} najpierw zapisuje range tombstone).

Ale uwaga: kompakcja może wyrzucić tombstone dopiero po gc_grace_seconds (domyślnie 864000 s = 10 dni). Dlaczego tak długo? Bo nagrobek musi zdążyć dotrzeć do wszystkich replik. Jeśli któraś go nie dostała, a pozostałe już go usunęły… zobacz sam, co się dzieje:

Hinted handoff i read repair naprawiają tylko to, co „przy okazji” zauważą. Dane, których nikt nie czyta, mogą się rozjeżdżać latami. Dlatego jest nodetool repair: każda replika buduje dla swojego zakresu tokenów drzewo Merkle (tzw. validation compaction — czyta dane i je haszuje). Liście to hashe małych podzakresów tokenów, a każdy węzeł wewnętrzny to hash dzieci. Repliki wymieniają się drzewami, porównują je od korzenia w dół i streamują tylko te podzakresy, których liście się różnią.

Twierdzenie CAP mówi, że gdy nastąpi podział sieci (P), system musi wybrać między spójnością (C) a dostępnością (A). Cassandra jest projektowana jako AP: domyślnie woli przyjąć zapis i pogodzić wersje później (last-write-wins po timestampie). Ale dzięki tunable consistency pojedyncze zapytanie może zażądać zachowania „CP-podobnego” (np. QUORUM) — kosztem tego, że po mniejszościowej stronie podziału dostanie błąd.

Lightweight transactions (LWT)

Czasem naprawdę potrzebujesz „zapisz tylko, jeśli…”, np. unikalna nazwa użytkownika. Do tego służą LWT: INSERT … IF NOT EXISTS, UPDATE … IF balance = 100. Pod spodem działa Paxos między replikami danej partycji (CL SERIAL / LOCAL_SERIAL): prepare/promise, odczyt aktualnej wartości, propose/accept, commit — klasycznie 4 rundy sieciowe zamiast jednej (Paxos v2 z Cassandry 4.1 ścina to do ~2). To linearizowalność dla jednej partycji — nie ma transakcji obejmujących wiele partycji (na to czeka projekt Accord z CEP-15). Używaj LWT oszczędnie i nie mieszaj ich ze zwykłymi zapisami tych samych danych.

INSERT INTO users_by_login (login, user_id) VALUES ('ala', 42) IF NOT EXISTS;
--  [applied] | login | user_id
--  False     | ala   | 17        ← ktoś był szybszy

W bazie relacyjnej modelujesz byty i relacje, a zapytania składasz JOIN-ami. W Cassandrze nie ma JOIN-ów, a zapytanie powinno trafić w jedną partycję (jeden zestaw replik, kilka sekwencyjnych odczytów). Zatem odwracasz proces: zaczynasz od listy zapytań aplikacji, a dla każdego projektujesz tabelę (query-first modeling). Te same dane lądują w kilku tabelach — to denormalizacja i jest zamierzona: dysk jest tani, a zapisy szybkie. Płacisz tym, że aplikacja (lub batch LOGGED) musi pisać do kilku tabel.

Anatomia klucza głównego

CREATE TABLE messages_by_channel (
  channel_id  text,
  bucket      text,        -- np. tydzień: '2026-W39'
  sent_at     timeuuid,
  author      text,
  body        text,
  PRIMARY KEY ((channel_id, bucket), sent_at)
) WITH CLUSTERING ORDER BY (sent_at DESC);

• Klucz partycji (channel_id, bucket) — to, co idzie do hasha i wybiera węzły. Zapytanie musi podać go w całości (równość).
• Kolumny klastrujące sent_at — sortują wiersze wewnątrz partycji na dysku. Pozwalają na zakresy (sent_at > …) i ORDER BY — ale tylko w kolejności ich deklaracji.
• Partycja z wieloma wierszami to wide partition („wide row” z czasów Thrift): jeden klucz, tysiące posortowanych wierszy, czytanych sekwencyjnie jednym „plasterkiem”.

Ściąga: parametry, które warto znać