neděle 11. července 2010

Eventuálně konzistentní

V prvním článku zde na Dagblogu jsem se snažil zachytit základní myšlenky kolem NoSQL (Not Only SQL) databází. Převážně jsem mluvil o key/value databázích. Samozřejmě rodina NoSQL databází je mnohem širší, kromě key/value databází máme například grafové databáze (Neo4j, HyperGraphDB) specializované na ukládání hierarchických struktur a nebo databáze pro ukládání dokumentů reprezentované poměrně známou CouchDB a nebo MongoDB. Každý z těchto druhů NoSQL databází exceluje v jiné oblasti, kde nám klasické relační databáze nedostačují ať již z hlediska objemu dat, rychlosti, ceny, efektivity.

Všechny a nebo lépe řečeno většina těchto NoSQL databází (výjimky nevylučuji) se vyznačuje takzvanou případnou konzistenci dat. Pro většinu z nás je konzistence našich dat posvátnou krávou. Není se čemu divit, dvacet let jsme psali aplikace nad relačními databázemi v čase a prostoru definovaném ACID kde jsme konzistenci drželi referenční integritou a orámovali transakcemi. Jenom velice těžko si představujeme, jak naše data nejsou konzistentní a nebo lépe řečeno pohled na ně v určitý časový okamžik.

Případná konzistence

Abychom se vůbec probojovali k tomu, co eventual consistency znamená, musíme začít ze široka. S masivním rozvojem internetových aplikací rostl i objem dat, se kterými tyto aplikace pracují a nebo které je potřeba zpracovat. Nemusíme si hned představovat všechny ty giganty jako Facebook, Twitter a další sociální sítě, ale stačí obyčejné služby pro agregaci článků a nebo nástroj, kterým si analyzujeme data (třeba logy) vygenerovaná námi provozované aplikace. Zjednodušeně řečeno, problém relačních databází nastane ve chvíli kdy do nich hrneme hromady dat, se kterými potřebujeme pracovat. Především psát nad nimy dotazy - dělat pohledy na tato data.

S velkým objemem dat řešíme jak škálovat read a write operace. Klasický přístup pro škálovatelnost write operací je takzvaný sharding. Tedy, že data podle určitého klíče fyzicky sepratujete. Write operace jsou totiž narozdíl od čtecích vždy na určité úrovni vzájemně blokující. Jednoduchý přístup, je ten že data všech lidí začínajících na písmeno A dáváte do jiné tabulky než data lidí začínajících na písmeno B. Případně neděláte rozdělení na úrovni tabulek, ale rovnou databází. Pro rozprostření dat podle klíče se zde používá technika zvaná consistent hashing. Pro operace čtení se používá takzvaný replica read. V takovém scénáři máme databázové servery v master/slave módu. Kdy některé čtecí operace (nemusí nutně všechny) směřujeme na slave servery..

CAP teorém, vyberte si dva

Existuje něco, čemu se říká CAP teorém, podle kteréhho mají systémy tři základní atributy - dostupnost, konzistenci dat a partioning (fyzické rozdělení). Podle tohoto teorému je možné dáshnout pro distribuované systémy pouze dvou z nich. Vzhledem k tomu, že v předešlých odstavcích jsme si řekli, že pro zvládnutí velkého objemu dat potřebujeme sharding, to znamená že dochází k partioningu (data máme fyzicky na jiných serverech), zbývá nám volba mezi konzistencí dat a dostupností.

V případě, že konzistence dat je pro nás absolutní prioritou na úkor dostupnosti, znamená to, že náš systém jako celek může být v určitých momentech nedostupný. To je daň za to, aby jsme nepřečetli například data, která jsou zastaralá. Pokud je naopak absolutní prioritou dostupnost systému na úkor konzistence dat, znamená to, že v určitých chvílích můžeme číst data, která jsou zastaralá. Této konzistenci se říká případná. NoSQL databáze jsou charakterizované právě případnou konzistenci, ve smyslu "časem konzistentní" ši "výsledně konzistentní", s tím že mají vysokou míru dostupností.

Případná konzistence se jí říká protože klient čte konzistentní data jenom za splnění určitých podmínek, ve kterých se systém může nalézat. I případná konzistence má několik stupňů jako Read-your-own-writes. Pro zajímavost, v prostředí internetu je jedním ze základních systému pracující s případnou konzistencí DNS a jeho propagace změn skrze cache s definovanou dobou vypršení.

Pro vaší aplikaci to znamená, že můžete pracovat s daty, které nemusí být aktuální. Nemá cenu dodávat, že jsou typy úloh, pro které je tato konzistence dat akceptovatelná a pro které již ne. Například autoři CouchDB by se nebáli pomocí ní naimplementovat bankovní systém, chce to prostě jiné recepty.

Zdroje