LINUXSOFT.cz Přeskoč levou lištu
Uživatel: Heslo:  
   CZUKPL

> 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 5812×

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.
Obvykle NoSQL databáze používají odlišné modely reprezentace dat jako zobrazení, orientované grafy, objekty... Odlišné modely reprezentace dat a relační model se dají vzájemně výpočetně nenáročně převádět. Zásadní rozdíl mezi NoSQL a SQL však spočívá ve vyjadřovací síle jazyka. Většina NoSQL jazyků má ostře menší vyjadřovací sílu než SQL. Typicky spojení tabulek JOIN nelze vyjádřit pomocí NoSQL jazyků.

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

pridej.cz

 

DISKUZE

nosql 14.7.2011 11:28 Radim Kolář
Nevýhody SQL 15.7.2011 11:07 František Kučera
L Re: Nevýhody SQL 15.7.2011 16:10 Tomáš 'Heron' Crhonek
  |- Re: Nevýhody SQL 17.7.2011 02:14 Miloslav Ponkrác
  L Re: Nevýhody SQL 22.7.2011 10:41 Radim Kolář
    |- Re: Nevýhody SQL 22.7.2011 14:43 Tomáš 'Heron' Crhonek
    L Re: Nevýhody SQL 22.7.2011 14:45 Aleš Hakl
      L Re: Nevýhody SQL 24.7.2011 10:20 Radim Kolář
        L Re: Nevýhody SQL 25.7.2011 10:07 Tomáš 'Heron' Crhonek
          L Re: Nevýhody SQL 25.7.2011 13:31 Radim Kolář
preklep - Cassandra je AP! 26.11.2012 14:12 chipiik




Příspívat do diskuze mohou pouze registrovaní uživatelé.
> Vyhledávání software
> Vyhledávání článků

8.5.2016 17:19 /Redakce Linuxsoft.cz
PR: Dne 26.5.2016 proběhne v Praze konference Cloud computing v praxi. Tématy bude např. nejnovější trendy v oblasti cloudu a cloudových řešení, cloudové služby, infrastruktura cloudu, efektivní využití cloudu, možné nástrahy cloudů a jak se jim vyhnout
Přidat komentář

21.4.2016 8:01 /František Kučera
Spolek OpenAlt zve na 127. distribuovaný sraz příznivců svobodného softwaru a otevřených technologií (hardware, 3D tisk, SDR, DIY, makers…), který se bude konat ve čtvrtek 28. dubna od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).
Přidat komentář

2.3.2016 22:41 /Ondřej Čečák
Letošní ročník konference InstallFest již tento víkend!
Přidat komentář

14.2.2016 16:39 /Redakce Linuxsoft.cz
O víkendu 5. a 6. března 2016 proběhne na pražském Strahově 8. ročník tradiční konference InstallFest. Celkem za dva dny uvidíte ​30 přednášek​ a ​6 workshopů.
Přidat komentář

5.2.2016 17:38 /Petr Ježek
Utilitka z XFce "xfce4-power-manager" nejen umožňuje nastavení lhůty pro uspání či hybernaci, ale i zapínání a vypínání prezentačního módu pro nerušené sledování videí. Stačí ji nastavit v každém vybavenějším panelu a v jakémkoli nontiled WM/DE.
Přidat komentář

10.1.2016 11:32 /Pavel `Goldenfish' Kysilka
LinuxMarket změnil provozovatele. Nově jej provozuje Marek Pszczolka. Více info a detaily #1 a #2.
Přidat komentář

29.12.2015 11:38 /Ondřej Čečák
Ještě posledních pár dní můžete přidávat příspěvky nebo nápady na Install Fest 2016, který se bude konat 5. a 6. března 2016.
Přidat komentář

8.12.2015 11:36 /Petr Ježek
Logické se stává realitou. LibreOffice a Thunderbird se mají dle článku na Redditu stát protiváhou MS řešení (MS Office a Outlook).
Přidat komentář

   Více ...   Přidat zprávičku

> Poslední diskuze

10.6.2016 21:10 / pavel riha
FreeBSD 10.3 a virtualizace

8.6.2016 21:56 / Milan Gallas
Nevalidní prefix m

7.5.2016 14:58 / Teodor Komárek
Soubory

20.4.2016 0:07 / Jakub Cleing
Sázkový panel PHP FUSION

9.4.2016 9:43 / jiwopene@gmail.com
Re: problém s dpkg a nemožností instalovat

Více ...

ISSN 1801-3805 | Provozovatel: Pavel Kysilka, IČ: 72868490 (2003-2016) | mail at linuxsoft dot cz | Design: www.megadesign.cz | Textová verze