přejít na obsah přejít na navigaci

Linux E X P R E S, Cassandra: Databáze pro skutečně velké projekty

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

Cassandra_logo.jpg

Chystáte velkou webovou aplikaci? Na NoSQL úložiště Cassandru se spoléhají velké aplikace společností Digg, Twitter, Reddit, Cisco, Zoho nebo Facebook. Cassandra vyniká především neomezenou škálovatelností, maximální dostupností, rychlostí vyhledávání/ukládání, multiplatformností, „pružností“ datového modelu, konfigurovatelností a bezúdržbovostí. 


reklama

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.

Nahoru

(Jako ve škole)
 

Top články z OpenOffice.cz

Příspěvky

Tomáš Crhonek Cassandra: Databáze pro skutečně velké projekty
Tomáš Crhonek 16. 05. 2013, 08:06:08
Odpovědět  Odkaz 
Diky za pekny clanek. Jsou v planu i pokracovani, vytvoreni clusteru a prakticke pouziti?
Cassandra: Databáze pro skutečně velké projekty
Petr Ježek 18. 05. 2013, 09:54:27
Odpovědět  Odkaz 
Z článku má nejvyšší informační hodnotu sdělení, že běžní IT experti nevědí nic o Cassandře. Otázkou pak ale je, kdo je IT expert, když neví o NoSQL databázích, zvláště o té, která má triviální správu na rozdíl od správy SQL. Jinak Hadoop a jeho uchopení Redhatem ukazuje na trochu jinou obeznámenost s Cassandrou.
Cassandra: Databáze pro skutečně velké projekty
talpa 22. 06. 2013, 08:41:55
Odpovědět  Odkaz 
Kazdej nemuze vedet vse, o NoSQL databazich vim taky jen obecne info, nikdy jsem je na svych projektech nevyuzil, proste nebylo treba
Cassandra: Databáze pro skutečně velké projekty
talpa 22. 06. 2013, 08:44:04
Odpovědět  Odkaz 
jinak i sprava SQL muze byt trivialni pri rozumnem navrhu at uz je datovy model jakykoliv.

Přidat názor

Nejsou podporovány žádné značky, komentáře jsou jen čistě textové. Více o diskuzích a pravidlech najdete v nápovědě.
Diskuzi můžete sledovat pomocí RSS kanálu rss



 
 

František Bártík

Soustředím se na problémy, které vyžadují kreativní přístup anebo využití teoretických znalostí. Orientuji se na svobodná řešení a baví mě učit se nové věci. Neváhejte a oslovte mě s Vaším zajímavým pracovním zadáním.


  • Distribuce: debian a odvozená distra
  • Grafické prostředí: GNOME
  • Hodnocení autora: *

| blog



Public Relations

QNAP uvedl novou modelovou řadu NAS TVS-x82T

Společnost QNAP uvedla na trh novou modelovou řadu NAS TVS-x82T, kterou tvoří tři různé modely (TVS-1282T, TVS-882T a TVS-682T). Nová řada je založena na vícejádrových procesorech Intel Core aktuální generace se 14nm výrobním procesem. Díky nim mohou nové NASy nabídnout dostatek výkonu i pro aplikace náročné na CPU.

Pokračování ...


CIO Agenda 2016