Cassandra: Databáze pro skutečně velké projekty

Základní představení produktu

přesný název	Apache Cassandra
charakteristika	konfigurovatelná peer to peer NoSQL databáze
datový model	strom
míra konzistence dat	individuálně nastavitelná
licence, upravitelnost	Apache verze 2, snadný hacking
škálovatelnost	za plného provozu neomezeně horizontálně škálovatelné
multiplatformnost	multiplatformní (platforma Java)
vývoj	intenzivní, prioritní projekt (top level)
kompatibilní s	Hadoop, J2EE, Ganglia...
vizuální nástroje	ne mnoho
web projektu	cassandra.apache.org

Je libo nekonzistentní data?

Obvyklé požadavky na databázi shrnuje akronym ACID, kde A znamená atomičnost, C konzistenci, I izolovanost a D trvalost (durability) databázových operací. Bohužel požadavek konzistence přináší podle Brewerovy CAP věty nepříjemná teoretická omezení. Sníží-li se kapacita linek mezi datacentry, znemožní se tím rychlá synchronizace. S nedostatečnou synchronizací se lze vypořádat jen trojím způsobem, a to místo zpracování vrátit chybovou hlášku, drasticky snížit kvalitu služby (extrémní latence), nebo vrátit nejlepší dostupnou odpověď bez záruk konzistence.

Kupodivu u webových aplikací často úzkostlivé lpění na striktní konzistenci nepatří k prioritám, což ilustruje následující příklad. V grafice „Líbí se mi“ vidím stále nulu, ačkoli se stránka před vteřinou zalíbila v Pittsburghu Tomáši Vokounovi a před minutou v Bostonu Jardovi Jágrovi. Já v Písku se dozvím o Vokounovi za osm vteřin a po dvaceti vteřinách i o Jágrovi. Databáze se zjevně výrazně zpozdila (neaktuální odpovědi), a navíc i obrátila pořadí. U takovýchto sdělení naštěstí nepřesnosti trvající v řádu desítek vteřin nijak nevadí, ostatně uživatelé si jich sotva všimnou.

Na druhou stranu bez konzistence si nelze představit provádění finančních transakcí, registraci uživatelských účtů, statistiku, archivaci, ... V Cassandře administrátor může určit individuálně míru konzistence jednotlivým skupinám záznamů. Vhodným nastavením vylepšuje konzistenci na úkor latence, respektive latenci na úkor konzistence.

Konzistence za latenci, latence za konzistenci

Každý záznam se přechovává v několika identických kopiích uložených na různých serverech. Úroveň garantované konzistence závisí na třech volbách redundance:

Data se kopírují na určený počet počítačů, což funguje i jako jednoduchý zálohovací mechanismus.
Počet úspěšně vytvořených replik pro dokončení zápisu je rovněž konfigurovatelný. Zápis se tak může považovat za úspěšný i před dosažením cílového počtu replik. Data jsou pak replikována automaticky „na pozadí" až do splnění kritéria celkového počtu replik. Díky tomu nezůstanou trvale málokrát replikovaná, leda by kopie byly smolně zničeny při selhání hardwaru.
Každý záznam obsahuje i čas svého vytvoření. Z přečtených replik se zpracuje jen nejnovější replika, neboť mladší záznamy zahrnují pozdější úpravy. Nejmladší repliky zachycují nejaktuálnější stav.

O konzistenci rozhoduje splnění Dirichletova principu. Požadujeme-li celkově dvacet replik, osmnáct replik při zápisu a tři repliky při čtení, čtení se vždy „střetne“ se zápisem alespoň u jedné repliky, protože osmnáct plus tři je více než dvacet. Uvedené nastavení tedy zaručuje konzistenci. Požadujeme-li pro změnu jen deset replik při zápisu, může se čtení „minout“ se zápisem, protože deset plus tři je méně než dvacet. Tedy toto přenastavení již konzistenci nezaručuje.

Jak nebloudit mezi tisíci servery?

Klíč identifikující záznam se převede na hash. Každý uzel obsluhuje určitý rozsah hashů, přesněji řečeno spravuje data odpovídající těmto hashům. Rozsahy se přidělují deterministickým algoritmem, aby Cassandra v clusteru „nebloudila“. Nově přidaný server získá rozsah hashů k obsluze, stáhne si příslušné repliky a zahájí svou činnost. Analogicky se redistribuují „osiřelé“ repliky zbylé po selhavších, nebo cíleně odpojených serverech. Administrátor si vybírá mezi různými předpřipravenými algoritmy a ladí nejrůznější nastavení:

Když, vzhledem k charakteru aplikace výrazně převažuje čtení nad zapisováním, vyplatí se výrazně zvýšit počet replik. S nastíněnou situací se setkáváme u webových publikačních platforem. (Autor obsahu touží, aby každý jeho text byl mnohokrát zhlédnut. Bez publika ztrácí motivaci pokračovat v tvorbě.)
Cassandra může zohlednit fyzickou topologii sítě (datacentra, rackové skříně, ...). Sníží se tak frekvence neefektivní komunikace mezi vzdálenými uzly. Podmínka uložení každého záznamu do každého z datacenter předejde nedostupnosti při rozsáhlých výpadcích konektivity mezi datacentry.
Nabízí se více hashovacích algoritmů. Podobné hashe pro podobné klíče mohou optimalizovat typické dotazy, ale mohou vyústit v asymetrickou zátěž a přetěžování některých uzlů. Kryptograficky dobrá hashování „rozhází“ data pseudonáhodně, čímž zabrání lokálnímu přetěžování. Nahodilost míst uložení však může zvyšovat celkový síťový provoz.

Datový model

Jen položky na úrovních keyspace a columnfamily jsou nastavitelné. U keyspacu se nastavuje jméno (name), algoritmu distribuce replik (replica placement strategy) a parametry tohoto algoritmu (strategy options). Konkrétní Columnfamily disponuje několika desítkami atributů, z nichž mnohé slouží k upřesnění mechanismu ukládání a k lazení výkonu. Datový model a metody ukládání tak nabízejí četná vylepšení.:

Sekundární indexy vracejí záznamy v columnfamily podle hodnoty. Tuto pomocnou strukturu se vyplatí definovat, když logika aplikace nepřipouští libovolné hodnoty. Třeba údaj o národnosti nabývá jen několika set možných hodnot.
Nechcete-li mít Cassandru jen coby úložiště neuspořádaných posloupností bytů, můžete definovat u jednotlivých columnfamily validátory a komparátory.
Limity byly zvoleny velkoryse.
Mnohé informace mají jen omezenou časovou platnost. Jmenujme registrační odkaz zasílaný na mail, pravidelné zálohy, časově omezená práva přístupu k placenému obsahu, ... Nastavení TTL (time to live) zabezpečí, že po vypršení lhůty budou příslušná data ignorována a postupně smazána.
Komunikuje se především vzdáleným voláním procedur (RPC, remote procedure call) skrz rozhraní Thrift. Cassandra rovněž disponuje jazykem CQL (Cassandra query language), jenž se svou syntaxí nápadně hlásí k tradici SQL.
Při ukládání se nejprve požadavek archivuje v commitlogu, což zajišťuje trvalost (durability) operace, a následně se uloží do rychlé memtable. Z přeplněné memtable se data uvolní ve formě nového souboru formátu SSTable, více souborů SSTableů se „sumarizuje“ (compaction) do jednoho a nepotřebné soubory SSTable uklízí garbage collector. Vyhledávání v souboru SSTable optimalizuje Bloomův filtr.

Cassandra se maximálně soustředí na jednoduché vyhledávání/ukládání dat. Obecnější standard SQL zastiňuje Cassandru svou univerzálnosti. Mimo jiné SQL databáze zvládají operace nad kartézským součinem (křížové spojení CROSS JOIN) a nad podobnými součiny (vnitřní spojení INNER JOIN, přirozené spojení NATURAL JOIN, úplné vnější spojení FULL OUTER JOIN, levé částečné vnější spojení LEFT OUTER JOIN, pravé částečné vnější spojení RIGHT OUTER JOIN). Bez obalu je nutno přiznat, že Cassandra nic podobného neumí. Cassandra je fachidiot, který exceluje v oblasti rychlého vyhledávání/ukládání a totálně propadá ve všem ostatním. Cassandřinu přílišnou specializaci alespoň částečně kompenzuje dostupnost externích kompatibilních nástrojů, zvláště Hadoopu.

Hadoop

Na obřích clusterech se vše komplikuje. Například zajistit, aby se každý údaj zpracoval právě jednou, není triviální. Není lehké pracovat s clusterem jako s jedním „celkem“, aniž by programátor byl limitován výkonem dílčích serverů. Populární framework Apache Hadoop řeší takovouto rutinu při programování distribuovaných výpočtů. Programátor se může soustředit na samotnou logiku fungování aplikace.

Hadoop přináší především implementaci programovacího modelu MapReduce(), který slouží k masivní paralelizace výpočtu. Programátor definuje funkci Map() a funkci Reduce(). Funkce Reduce() rekurzí zpracuje multimnožinu výsledků "paralelní" funkce Map() pro dostupná data. Jednotlivá vyčíslování funkce Map() se vzájemně neblokují, obejdou se bez synchronizace a kalkulaci lze provést okamžitě v místě uložení zpracovávaných dat. Jinými slovy MapReduce "rozloží" výpočet přes celý cluster. Tento postup důvěrně znají příznivci funkcionálních jazyků (např. Lisp) a multiparadigmatických jazyků (např. Python), byť vzhledem k nejednotnosti terminologie pod jiným jménem. Kroku Map() se též říká agregátor, kumulátor, projekce, fold, komprese, ...

Cassandřina pro a proti

Cassandra může být dobré řešení, pokud:

Očekáváte velká množství současně zpracovávaných dat a dotazů. Pro cluster jste si přichystali alespoň několik desítek serverů.
Vyžadujete velmi vysokou dostupnost služby. Některé dotazy se musí bezpodmínečně zpracovat, byť i za cenu ne zcela korektních výsledků.
Vaše servery se liší hardwarem a softwarem. Databáze musí obstát v heterogenním prostředí.
Oceníte minimální administraci při škálování a řešení různých incidentů.
Postrádáte vyčerpávající představu o ukládaných datech. Volíte proto key-value úložiště, aby vás nesvazovala databázová schémata.
Uvítáte absenci licenčních poplatků. Uvítáte upravitelnost zdrojových kódů.

Je nutné odpovědně zvážit, zda skutečně máte zmíněné požadavky. Zmíněným požadavkům byly obětovány některé podstatné vlastnosti, bez nichž zůstává mnoho projektů nemyslitelných. Cassandra nikdy nebude přímo konkurovat klasickým SQL databázím (MySQL, PostgreSQL, MariaDB, ...), jež pohánějí většinu webů.

Cassandra nepodporuje složitější vyhledávání dat. Způsob uložení dat definuje i způsob vyhledávaní.
Cassandra nezvládá komplikovanější zpracování dat.
Cassandra není kompatibilní s SQL, neporadí si se softwarem pro platformou LAMP. Aplikační software si pravděpodobně budete muset vyvinout sami.
Běžní IT experti neví nic o Cassandře. Využít Cassandřiny přednosti naplno (např. kompatibilita) dokáže jen specialista.

V perexu zmíněné reference vycházejí ze seznamu referencí v heslu Cassandra z anglické Wikipedie. Databáze se jmenuje podle starořecké věštkyně Kasandry, proto článek užívá posesivního adjektiva Cassandřin a skloňuje podle vzoru žena.