Cassandra DB - I.

Tento seriál se bude zabývat open source databází Apache Cassandra. Jednotlivé instalace dokáží spolupracovat při poskytování databázových služeb. Návrh Cassandry se zaměřuje na snadné a spolehlivé propojování velkého množství počítačů, které vytvoří jednu distribuovanou vysoce výkonnou dobře horizontálně škálovatelnou databázi. Projekt zařadil Apache Software Foundation mezi své top-level projekty. První díl seriálu bude čistě teoretický.

14.7.2011 00:00 | František Bártík | Články autora | přečteno 10961×

Nevýhody SQL

Principy Cassandry se neslučují s principy klasických SQL databází. Jedná se tedy o tzv. NoSQL databázi. Během posledních několika let vznikla celá řada populárních NoSQL databází.

Co je na SQL špatně? Na SQL není nic špatně, ale pouze se nehodí pro všechna praktická využití databázi. Neexistuje jen jeden princip návrhu NoSQL databáze, proto mluvit o obecných výhodách NoSQL databází postrádá smysl. Obvykle NoSQL překonávají SQL databáze v některé z těchto vlastností.:

• Při vytvoření tabulky se určují typ ukládaných dat v jednotlivých sloupcích a počet sloupců. Navržené schéma lze později změnit pouze s pomocí speciálních SQL příkazů. Tato potřeba vyvstává například při migraci na novou verzi klientského softwaru, jejíž nová funkcionalita vyžaduje ukládaní větších množství údajů u záznamů. Alternativním přístupem u některých NoSQL databází (tzv. schema-free database) je schéma vůbec nepožadovat.
• V SQL se dají zapsat náročné dotazy, které mnohdy dokáží přetížit databázi. Například dotaz SELECT * FROM tabulka1 JOIN tabulka2 JOIN tabulka3 ON tabulka1.cislo + tabulka2.cislo + tabulka3.cislo = 0 má polynomiální výpočetní náročnost v závislosti na velikosti tabulek. U velkých tabulek nepřipadají tyto dotazy v úvahu. Proto u jazyků navržených pro velké databáze by bylo záhodno zamezit těmto dotazům již v návrhu jazyka. Další potencionálně nebezpečnou operací jsou transakce.
• Možnosti SQL jsou velmi rozsáhlé. Tato komplexnost ztěžuje optimalizaci enginu databáze na právě ty dotazy, které jsou ve zvoleném způsobu nasazení skutečně potřeba.
• Při založení tabulky nemůžeme rovnou omezit množinu přípustných dotazů nad tabulkou a tím umožnit lepší optimalizace omezené množiny použitých dotazů.
• U konkrétních tabulek není možné snížit požadavky na model konzistence dat. Problematice úrovní konzistence a jejich nastavování v Cassandře se bude věnovat jeden z dalších dílů.
• Při pokládání SQL dotazů se konstruují a odesílají dotazy v textové formě, která napodobuje angličtinu. Předávání textových řetězců vycházejících z přirozeného jazyka rozhodně není nejefektivnějším způsobem komunikace mezi klientem a serverem.

Velké distribuované systémy

Velké distribuované systémy běží v různých geografických regionech na mnoha počítačích, souběžně obsluhují velké množství klientů a často se potýkají s různými technickými problémy. komplikací. Jmenujme například tři zásadní otázky.

• Vzhledem k odezvě se vyplatí číst data z blízkých datacenter. Na jaká datacentra ukládat jaká data? Jakou zvolit míru redundance?
• Internet může být nespolehlivý. Jak se databáze vypořádá se situací, kdy jsou některé její uzly offline? Jak se databáze vypořádá s DOS útokem, kdy některé uzly jsou přetíženy?
• Vzhledem k prostorové rozlehlosti, limitaci přenosu rychlostí světla a rychlosti síťových prvků existují nepřekonatelná omezení ve snižování latence. V době, kdy změna dat "probublává" celou databází, může databáze přijmout třeba několik stovek dalších požadavků na změnu dat. Jak synchronizovat činnost jednotlivých uzlů?

Brewerův teorém

Při návrhu databáze se některé vlastnosti, které pokládáme za samozřejmé u nedistribuovaných databází, musí obětovat. Nejdůležitější tři vlastnosti pro distribuované databázové charakterizujme písmeny C, A a P.

• Písmeno C (consistency) označuje striktní konzistenci. Tyto systémy podle času uspořádají všechny dotazy do posloupnosti a každý dotaz je proveden vždy nad stavem databáze, který vznikne provedením všech předcházejících dotazů.
• Písmeno A (availability) označuje systémy, které garantují vyřízení dotazu.
• Písmeno P (partition tolerance) označuje systémy, jejichž návrh počítá s nemožností garantovat kvalitu komunikace. Jinými slovy připouští možnost výpadků nebo výrazným zhoršením spojení mezi uzly. Například pokud se výrazně sníží propustnost linky spojující dvě datacentra bude na nich běžící databáze s vlastností P schopna vyřizovat požadavky klientů.

Databázové systémy lze klasifikovat podle množiny splněných podmínek. Podle Brewerova teorému databáze nemůže splňovat současně podmínky CAP, přestože všechny ostatní kombinace vlastností C, A a P jsou možné. Rozeberme jednotlivé případy kombinací CA, CP a AP.

• K zajištění striktní konzistence je nutná synchronizace celé databáze. Dosažení synchronizace vyžaduje zaručenou komunikaci mezi všemi uzly, což vylučuje vlastnost P. Příkladem databáze CA je většina SQL databázových systémů.
• Analogicky u striktně konzistentní databáze přerušení komunikace mezi jednotlivými uzly znemožňuje vyhodnotit některé posloupnosti dotazů. Tedy vlastnosti CP vylučují vlastnost A. Příkladem je databáze Googlu BigTable a jí inspirované databáze HBase a HyperTable.
• Při vyhodnocování dotazu v okamžiku, kdy není celá databáze propojená, se dá spolehlivě zjistit hodnota rozhodných dat nejvýše v okamžicích, které předcházely výpadku spojení. Vyhodnocení dotazu nevychází z aktuálního hodnot a proto databáze nemůže splňovat podmínku C. Příkladem je databáze Amazonu Dynamo. Databáze Apache Cassandra má rovněž vlastnosti AC.

Strategické rozhodnutí mezi těmito typy samozřejmě závisí na charakteru aplikace. Různé činnosti kladou různé nároky. Následující dva příklady ilustrují aplikace s rozdílnými nároky na konzistentnost databáze.

• U aplikace obsluhující bankovní účty je nejdůležitější vlastnost C. Při nekonzistentním zpracovávání snadno mohou v systému "vznikat" a "zanikat" peníze.
• U populárního zpravodajského serveru bude důraz kladen na dostupnost. Místo chybové stránky o problémech databáze je rozhodně lepší zobrazit třeba pět minutu starou verzi webu. Rovněž není problém, pokud se nový článek některým čtenářům zobrazí až po několika vteřinách od své publikace. Tato služba tedy nevyžaduje vlastnost C.

Příští díl

V příštím díle seriálu si povíme, proč pro zmíněný zpravodajský server je databáze Cassandra jednou z dobrých voleb. Dále popíšeme některé její výhody, instalaci a způsob administrace.

Verze pro tisk

DISKUZE nosql 14.7.2011 11:28 Radim Kolář Nevýhody SQL 15.7.2011 11:07 František Kučera Re: Nevýhody SQL 15.7.2011 16:10 Tomáš 'Heron' Crhonek   Re: Nevýhody SQL 17.7.2011 02:14 Miloslav Ponkrác   Re: Nevýhody SQL 22.7.2011 10:41 Radim Kolář     Re: Nevýhody SQL 22.7.2011 14:43 Tomáš 'Heron' Crhonek     Re: Nevýhody SQL 22.7.2011 14:45 Aleš Hakl       Re: Nevýhody SQL 24.7.2011 10:20 Radim Kolář         Re: Nevýhody SQL 25.7.2011 10:07 Tomáš 'Heron' Crhonek           Re: Nevýhody SQL 25.7.2011 13:31 Radim Kolář preklep - Cassandra je AP! 26.11.2012 14:12 chipiik Zobrazit označené Zobrazit vše Příspívat do diskuze mohou pouze registrovaní uživatelé.