Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (20)
Ján Kmeťko - NoSQL a distribuované databázy – pohľad zhora na konzistentnosť výkon a škálovateľnosť
- 1. Ján Kmeťko
- 3. Deklarovaný výkon nie je vždy reálnym obrazom (napr. môže platiť len pre špeciálny testovací prípad, alebo len pre percento reálnych situácii) Univerzálna lineárna škálovateľnosť je mýtus
- 4. 1. Výkon DB je obmedzovaný fyzicky vlastnosťami existujúcich algoritmov a dostupného HW 2. Výkon DB je znižovaný vnútornou neefektívnosťou databázy 3. Výkon je znižovaný použitím neoptimálnych algoritmov, alebo neoptimálneho HW
- 5. Rýchlosť procesora Prístup na pamäťové médium ◦ Latencia ◦ Náhodný prístup – frekvencia ◦ Sekvenčný prístup – rýchlosť zápisu vs. čítania ◦ Linearita adresného priestoru ◦ Trvalosť Komunikácia cez sieť ◦ Latencia ◦ Priepustnosť Spoľahlivosť
- 6. Názov SR SW R IOpS W IOpS trvalosť zdieľanie kapacita cena Cena/GB RAM 1 GB/s 1 GB/s 60k 60k nie PC 8 GB 200$ 25$ (+ PC) HDD (low end) 100 MB/s 100 MB/s 100 100 áno PC 500GB 100$ 0.5$ HDD (high end) 400 MB/s 400 MB/s 300 300 áno PC 256GB 1000$ 4$ SSD HDD (high end) 250 MB/s 90 MB/s 35k 8k áno PC 160GB 440$ 3$ RAM SAN 20 GB/s 20 GB/s 600k 600k áno sieť 1TB 500k$ 500$ HDD SAN ? ? ? ? áno Sieť 4TB 17k$ 3,5$ SSD SAN 1GB/s 1GB/s 300k 300k áno Sieť 2,4TB 125k$ 52$ Tabuľka 01 – približné porovnanie typov médií
- 7. Vyhľadávanie polením intervalu (dáta musia byť zoradené) – O(log 2 N) – náhodné čítanie Vyhľadávanie linárne – O(N) – sekvenčné čítanie Cena úpravy indexov pri zápise a zmene dát Cena tranzakčnosti (čakanie na zámky vs. reštart transakcie) Distribuované DB ◦ Cena distribuovaných tranzakcií ◦ Úprava synchrónnych replík na viacerých uzloch ◦ Náročnejšia concurrency control pri distribuovaných DB
- 9. Zníženie transaction isolation levelu Eventuálna konzistentnosť ◦ Asynchróne menená/invalidovaná cache ◦ Čítanie asynchrónnej repliky (alebo materializovaného view) ◦ Vlastné riešenia „šírenia dát“ ◦ Konzistentné prečítanie minulosti Slabá trvalosť Prečítanie uzamknutých, alebo modifikovaných dát Komutatívne operácie (inkrement)
- 10. Správna schéma šírenia dát – cesta k škálovateľnosti Šírenie zmien do stromovej štruktúry – neobmedzená škálovatelnosť pre read-only dáta Príklad pre celosvetovú stávkovú kanceláriu
- 11. Nemajú úplnú replikáciu Primárne repliky rozdistribuované na viacero uzlov Neexistuje pevný a dopredu daný kľúč rozloženia dát na uzly
- 12. Obmedzenia CAP teorémy Kde sú dáta ktoré hľadám?! Distribuované concurrency control Distribuované transakcie a commit Predefinovanie ACID podmienok Problém N na M stavov
- 13. Konzistentnosť (Consistency) Dostupnosť (Availability) Odolnosť voči rozdrobeniu siete (Partition tolerance) Nemôžeme mať všetky tri – príklad Môžeme mať ale rozumnú mieru všetkých CA / AP / CP systémy Potrebujeme skutočne P?
- 14. Statická tabuľka umiestnení Distribuovaná hash tabuľka Dynamická tabuľka umiestnení
- 15. Vyhľadanie entity O(log N) Veľkosť tabuľky - prstov O(log N) Bez možnosti zgrupovania Napr. Cassandra
- 16. Vyhľadanie entity - O(1) Veľkosť tabuľky – O(N), (N/X) X – veľkosť partície Zgrupovanie entít podľa primárneho usporiadania Možnosť viacvrstvovej tabuľky Napr. HBase, Google BigTable
- 17. Dvojfázové zamykanie (two phase locking) Zoradené časové značky (timestamp ordering) Konflikty – čakanie / reštart tranzakcie Concurrency Control in Distributed Database Systems - PHILIP A. BERNSTEIN
- 18. Problém konsenzu ◦ Komunikácia môže zlyhať v ktoromkoľvek okamihu Dvojfázové potvrdenie ◦ Náchylné na zlyhanie koordinátora Trojfázové potvrdenie Paxos potvrdenie ◦ Odolnosť voči (N - 1)/2 zlyhaniam ◦ Náročnosť N(F + 3) / 3 správ
- 19. Dostupnosť ◦ (1 - P^n) nedostupnosti všetkých potrebných replík Trvalosť ◦ (1 – p^n) straty všetkých synchrónnych replík. P je pravdepodobnosť zlyhania uzla za čas potrebný na vytvorenie novej repliky Konzistentnosť (CAP) ◦ Okno nekonzistentnosti / perióda zmeny Network partition – izolácia uzla / racku / datacenta ◦ Závisí od sieťovej infraštruktúry Konzistentnosť (ACID) ◦ Naruší len chyba, nesprávna kombináia algoritmov, alebo failover na asynchrónnu/neaktuálnu repliku
- 20. Eventuálna konzistentnosť ◦ Push asynchrónna replikácia zmien ◦ Pop asynchrónna replikácia zmien One-site transakcie Harwest a yield ◦ Výsledky len z % dát
- 21. Zložitejšie algoritmy Odolnosť voči výpadku uzlov a komunikácie Problém N^M stavov Viac možností optimalizácie Testovanie Zmena schémy dát Update verzie systému za behu Odhad: 10 – 100 krát náročnejšia implementácia, ako single node relačnej DB
- 22. Priestor na Vaše otázky
Notas do Editor
- Prečo by mali byť zaujímavé práve distribuované databázy? Donedávna takmer jednoznačne kraľovali v segmente informačných systémov relačné databázy a okrem niekoľkých špeciálnych situácii architekt skutočne siahol po bez váhania po relačnej databáze. V posledných niekoľko rokoch ale zažívame pomerne silný prúd venujúci sa prechodu na NoSQL databázy. Relačné databázy sú ako mainstreamové riešenie silne zažité, - všetci ich poznajú, - sú veľmi dobre otestované, robustné a spoľahlivé - majú silnú podporu vývojových nástrojov, metodík, atd. - majú širokú komunitu, - sú plne integrovateľné do všetkých jazykov - navyše ich funkcionalita pokrýva drvivú väčšinu prípadov s ktorými sa pri vývoji stretávam...No, aké argumenty teda ostávajú zástancom NoSQL databáz, ktoré sú bezpochyby vo všetkom spomenutom pozadu?Áno, je to práve deklarovaný vyšší výkon, škálovateľnosť a v niektorých prípadoch možnosť skutočnej distribuovateľnosti.Táto prezentácia bude skôr všeobecná – to znamená, že sa nebudem venovať žiadnej konkrétnej databáze, ale rozoberiem v nej radšej všeobecné princípy, ako databázy rôznych typov môžu fungovať. Mojim cieľom je dať vám nejaký rámec, ako ne základe stručných informácií uvedených v dokumentácii odhadnúť skutočné vlastnosti danej databázy.
- Toto je prvým mottom mojej prezentácie. Napriek tomu, že všetky typy databáz nám, ako ich používateľom ponúkajú iný pohľad na dáta, inú abstrakciu dát, vnútorne musia dáta ukladať na tie isté disky a riešiť tie isté problémy. Len ak pochopíme tieto problémy, môžeme pochopiť ako a prečo fungujú databázy tak, ako fungujú.
- Ako sa vraví každý chváli svoje perie. Platí to aj o dodávateľoch databáz a dvojnásobne, ak ide o platené produkty.Na čísla uvádzané na prvých stránkachproduktovsa treba pozerať kriticky. Môžu byť pravdivé aj v reálnej prevádzke, ale často sú testy volené tak, aby ukázali len dobré stránky produktu.Univerzálna lineárna škálovateľnosť databázy, ktorá by platila napr. pre vyhľadávanie je mýtus....prečo?Lebo viac používateľov rovná sa viac dát. Dlhšia doba behu systém – napríklad niekoľko rokov - sa tiež rovná sa viac dát.A vyhľadávanie nad indexom trvá O (log 2 N) a bez indexu dokonca O(N). Udržiavanie indexov je takisto závislé od množstva dát v nich.Navyše aj na obyčajné získanie záznamu dĺžkou potrebujeme O(log 2 N) času, aby sme ho našli podľa primárneho kľúča.Takže lineárna škálovateľnosť v zmysle 1 server – 1000 používateľov, 15 serverov – 15000 používateľov a 1000 serverov – milión používateľov je pre väčšinu aplikácii nedosiahnuteľná. Na grafy takýchto ladných tvarov sa pozerajte vždy kriticky.
- Aké obmedzenia nám teda platia pre výkon databázy.Výkon DB je obmedzovaný fyzicky vlastnosťami existujúcich algoritmov a dostupného HW – to je dôležité, lebo ak vám niekto sľubuje niečo, čo si neviete predstaviť, ako to na pozadí funguje, buď máte slabú predstavivosť, alebo si jeho sľuby zle vysvetľujete ;)Výkon DB je znižovaný vnútornou neefektívnosťou databázy - v tom sa jednotliví dodávatelia predbiehať môžu a je ťažké odhadnúť vnútornú rýchlosť bez testovaniaVýkon je znižovaný použitím neoptimálnych algoritmov, alebo neoptimálneho HW - každá databáza sa dá ohnúť len do určitej miery. Aj keď si dokážete predstaviť, ako spraviť niečo efektívnejšie, väčšinou sa musíte držať toho, čo databáza povolí. Navyše aj keď niečo databáza sľubuje, že dokáže, nemusí to ešte dobre a rýchlo fungovať. Ak niečo nesľubuje v dokumentácii, je naopak veľmi pravdepodobné, že to naozaj nevie.Ak teda vyberáte pre nejakú situáciu databázu a posúdite kandidátov podľa 1. a 3. bodu, môžete si dostatočne zúžiť výber možných riešení bez zdĺhavého prototypovania a výkonnostného tesotvania.Aj tak ale na konci budete musieť urobiť prototyp a otestovať to performance testami, aby ste vylúčili, že vám výkon zabije vnútorná neefektívnosť.
- Pozrime sa teda ako nás obmedzuje hardware.Samozrejme sme obmedzení výpočtovou silou procesora. Ale aby mal procesor čo spracovávať, musíme k nemu dostať dáta na vyhodnotenie.Dáta sú niekde uložené....nazvime pre túto prednášku každý HW, na ktorom sú uložené dáta pamäťovým médiom. Kaťdé pamäťové médium je charakterizované nejakými vlastnosťami.Latenciu – rýchlosť odozvy, to všetci poznáme.Za zamyslenie stojí najmä porovnanie sekvenčného a náhodného prístupu. Napríklad pevný disk má dramaticky rozdielnu rýchlosť náhodného a sekvenčného čítania.Náhodný prístup využívame najmä pri vyhľadávaní polením intervalu a je rozumnejšie ho merať frekvenciou (počet prístupov za sekundu), ako priepustnosťou.No a ešte u niektorých médií sa môže lýšiť rýchlosť zápisu a čítania.Linearitaadresnehopriestorunas obmedzuje pri sekvencnompristupe…musimecitatbajtyzasebou a napr. grafmusimeulozit do linearnehopriestoru…prirodzenevnimaneobmedzenieTrvalosť je prevrátená hodnota pravdepodobnosti s akou dáta stratíme. Pri komunikácii cez sieť nás obmedzuje najmä latencia a priepustnosť - to je každému snáď jasné. Ak máme nejakú NAS, tak vlastnosti siete sa vlastne prenášajú do vlastnosti pamäťového média.Vlastnosti siete tiež významne vstupujú do rovnice, čo môžeme očakávať od distribuovanej databázy.Spoľahlivosť siete, médii a inej infraštruktúry sa nám zasa výrazne odráža v niektorých rovniciach trvalosti dát a dostupnosti systému – to rozoberiem neskôr.
- Pozrime si teraz tabuľku, ktorú som pracne zostavil asi pred rokom a pol, keď ma zaujímali vlastnosti jednotlivých médií.Toto je sekvenčný prístup, toto je počet náhodných IO operácii. Z pohľadu budúcnosti je zaujímavý najmä skok v náhodných prístupoch HDD a SSD.Takejto skokovej zmene, ktorá úplne v niektorých situáciách mení výber použitého algoritmu sa napríklad staré relačné databázy nemusia vedieť tak rýchlo prispôsobiť.Sú to len moje domnienky, ale dodávateľ DB, ktorá dokáže plne využiť potenciál SSD diskov môže získať dobrú konkurenčnú výhodu v rýchlosti.Na ramku a disk na PC, som si napísal aj test, ktorý výsledky potvrdzuje, ostatné je podľa údajov výrobcov.
- Z algoritmických obmedzení sú naľahšiezadefinovateľné tie obmedzenia týkajúce sa vyhľadávania a prehľadávania dát. Všimnite si, že lineárne vyhľadávanie má horšiu časovú zložitosť, ale napr. na pevnom disku využíva omnoho rýchlejšiu metódu prístupu.Použitie iného ako primárneho média – čiže napr. cache a in memory index môžu výrazne zrýchliť databázové operácie. Ak sa napríklad celá databáza zmestí do RAMky, tak v ideálnom prípade to databáza využije a prístup k dátam bude bezkonkurenčne rýchly. Zápis by sa síce musel robiť na disk, ale stačilo by transakčný log raz za čas zmergovať s dátami a celú databázu tak upratať.....Pri každom pridanom indexe treba samozrejme rátať s jeho údržbou.......No a v neposlednom rade tranzakcie môžu značne spomaliť databázu. Najviac sa to prejaví pri databázach, kde veľa používateľov intenzívne pracuje s tými istými dátami v kombinácii čítania a zápisu.O distribuovaných databázach sa ešte zmienim, lebo tam je riadenie súbežného prístupu, distribuovaný komit a synchrónna replikácia dát úplne osobitnou kapitolou problémov a náročnosti.
- Relačné databázy väčšinou spĺňajú podmienky ACID. To je super vec a nás vývojárov ACID podmienky priam rozmaznávajú istotami, ktoré poskytujú.Nemusíme sa starať o konflikty medzi používateľmi, dáta sú vždy konzistentné a aktuálne a rollbacktranzakcie sa o konzistentnosť dát postará ak sa nám pritrafí nejaký ten error.Samozrejme toto nás niečo stojí ako už som spomenul v predchádzajúcom slajde.Ak teda narazíme na problémy s výkonom v pohodlí ACID podmienok, možnosti optimalizácie schémy a indexov sme už vyčerpali a nákup nového železa nie je riešením situácie prichádzajú rad na kompromisy.Také kompromisy, ktoré je používateľ ochotný akceptovať. Práve umenie urobiť kompromisy, ktoré sa nedotknú používateľa by mohlo byť mottom vývoja výkonovo optimalizovaných systémov. No a tiež práve možnosť ohnúť databázu do niektorého z takýchto kompromisov, prípadne možnosť skombinovania databázy z nejakým iným nedatabázovým riešením je mottom výberu tej správnej databázy z výkonového hľadiska.
- Na tomto slajde mám zoznam kompromisov, ktoré je možné urobiť na nedistribuovanej aj distribuovanej databáze.Znižovanie tranzactionisolationlevelu asi všetci poznáte....Eventualconsistency sa čím ďalej tým viac skloňuje najmä okolo NoSQL databáz. Slovo eventuálne by sme mohli vysvetliť frázou „niekedy v budúcnosti určite“. Čiže eventuálne konzistentné dáta znamená, že niekedy v budúcnosti budú určite konzistentné.Samotné slovo konzistentnosť nadobúda mierne odlišný význam ako je jej význam v ACID podmienkach. V podmienkach ACID znamená, že dáta nenarúšajú pravidlá dané dátovou schémou.Konzistentný v zmysle eventuálnej konistentnosti znamená, že ak máme dáta uložené na viacerých miestach a aktívnečítané z viacerých miest, tak dáta sú konzistentné ak zmena na jednom miesta sa už prejavila na inom mieste. Silná konzistentnosť nám nedovolí prečítať neaktuálne dáta, zatiaľ čo eventuálna konzistentnosť nám to dovolí. Eventuálna konzistentnosť nám ale stále zaručuje, že zmeny sa niekedy v budúcnosti prejavia v celom systéme.Ako vyzerá taká eventuálna konzistentnosť v praxi? Najrozšírenejší príklad je kešovanie v aplikácii. V Jave máme Hibernate a EHCache, ktorá sa dá nastaviť tak, aby objekty načítané v jednej session boli využité v ďalšej session. Ak niekto iný medzičasom zmení databázu, pracujeme s neaktuálnymi dátami. Možno by sa synchrónna invalidáciacache na aplikačno serveri dala spraviť pomocou trigerrov, ale už by šlo o integráciu s databázou mimo SQL rozhrania.Druhým pomerne rozšíreným príkladom je eventuálne konzistentná replika dát. Aj niektoré relačné databázy podporujú asynchrónnu master-slave replikácia. Potom slave replika je vlastne eventuálne konzistentná replika. Aj materializované view, ktoré je vytvárané, alebo modifikované asynchrónne je vlastne eventuálne konzistentnou replikou.Kdekoľvek dochádza k čítaniu dát, ktoré nie sú synchrónne menené s ich primárnou replikou dochádza k eventuálnej konzistentnosti. Modifikáciu dát je aj tak ale nutné robiť na primárnej replike.Aký má eventuálna konzistentnosť dopad na používateľa? Závisí od okolností, ale existuje veľa prípadov, kde ju môžeme akceptovať a môžeme s ňou pracovať. Dopad na používateľa silne závisí ajod štatistického rozloženia doby nekonzistentnosti.Zoberme si hocijakú webovú aplikáciu. Dáta sú načítané z databázy, vyrenderované o html, to je poslané a zobrazené používateľovi. Používateľovi navyše chvíľku trvá, kým si dáta pozrie, uvedomí a rozhodne o ďalšej akcii.Od načítania dát z databázy mohli byť tieto dáta zmenené, takže v hlave používateľa máme de facto len eventuálne konzistentnú repliku dát. Pokiaľ nepracujeme s dlhotrvajúcimi transakciami (ktoré je ale lepšie ošetriť na aplikačnej úrovni), sú v hlave používateľa zobrazené vždy potenciálne neaktuálne...a teda eventuálne konzistentné dáta. A práve preto pridať niekoľko stoviek milisekúnd nekonzistentnosti môže mať aj tak v konečnom dôsledku minimálny dopad na používateľa.Ak máme veľké požiadavky na škálovateľnosť, odporúčam zamyslieť sa nad tým, ako by sa zmeny v dátach mohli šíriť naprieč celým systémom a začať pracovať s eventuálnou konzistentnosťou ako nástrojom pre škálovateľnosť. Konzistentné prečítanie minulosti – niektoré situácie vyžadujú, aby dáta boli na 100% konzistentné v zmysle ACID, ale nemusia byť nevyhnutne najaktuálnejšie. Ak databáza udržiava určitú dobu historické verzie dát a každú zmenu viaže k nejakej časovej značke môžeme urobiť read do minulosti. Ak máme eventuálne konzistentnú repliku, ktorá má hornou hranicou ohraničené okno nekonzistentosti, tak nám takéto prečítanie minulosti vráti dáta, ktoré síce nemusia byť aktuálne, ale určite sú konzistentné v zmysle ACID podmienok. Podobná idea by sa dala použiť aj v prípade primárnej repliky na to, aby sme sa vyhli získavaniu read zámkov a stacinamprecitat data v takomokamihuminulosti, zevsetkyzamkynacitanychdatachboliziskaneazpodanomokamihu.Slabá trvalosť – normálna trvalosť podľa ACID podmienok zaručuje, že dáta ostanú v databáze aj po výpadku prúdu, prípadne páde operačného systému. V praxi sa to interpretuje tak, že dáta musia byť uložené na disk. Pri slabej trvalosti nečakáme, kým sa dáta uložia na disk. Výmenou za vyššiu rýchlosť odozvy je možnosť straty dát.Prečítanie uzamknutých, alebo modifikovaných dát – ak to DB podporuje, a v danej situácii netrváme na ACID konzistentnosti, môžeme prečítať a pracovať aj s uzamknutými dátami, obísť concurrencycontrol a zvýšiť tak rýchlosť odozvy a zrýchliť súbežný beh s inmitranzakciami. Je to niečo ako zníženie transactionisolationlevelu pre jednu transakciu.A perlička na záver. Nie každá zmena dát musí byť definovaná pevnou hodnotou. Napríklad taký inkrement, alebo dekrement hodnoty je komutatívna operácie, ktorú môžeme aplikovať aj keď súbežne bežia ďalšie rovnaké komutatívne operácie. Ak to databáza podporuje, tak tú istú hodnotu môže odrazu komutatívne modifikovať viacero tranzakcií, pričom zmena hodnoty sa pripíše k času komitnutiatranzakcie. Toto sa da vyuzithlavnenanejakecountery. Databáza by na to potrebovala špeciálny typ write zámku a tabuľku, ktorá ukladá časové verzie dát, takže moc databáz to nepodporuje.
- Ešte by som sa na chvíľu vrátil k šíreniu dát. Je dôležité zamyslieť sa nad tým, ako sa budú zmeny v dátach prejavovať naprieč celým systémom A navrhnúť takú schému, šírenia dát, aby bol systém optimálne vyťažený a zároveň škálovateľný.Napríklad stromová štruktúra šírenia zmien pre read-only časť systému dáva možnosť postaviť aplikáciu škálovateľnú na celosvetovú úroveň výmenou za malý kompromis oneskorenia Dát voči primárnej replike. Predstavte si stávkovú kanceláriu, ktorá zobrazuje aktuálny kurzový lístok pre používateľov po celom svete. V primárnej replike dochádza k zmene dát. Tieto zmeny sú replikované na druhú vrstvu databáz, pričom druhá vrstva pozostáva z N (povedzme 20) strojov. Zmeny sú z druhej vrstvy ďalej šírené na tretiu vrstvu, ktorá už môže obsahovať N*N (povedzme 400) uzlov. Každý zo 400 uzlov druhej vrstvy dokáže obslúžiť po 8 web serverov z ktorých každý dokáže obslúžiť 100 000 ľudí (nie každý stále používa systém). Výsledok je systém distribuovania kurzového lístka pre 320 mil. používateľov, s kompromisom oneskorenia odozvy o rádovo sekundy a škálovateľný ďalej veľmi jednoduchým spôsobom.
- Ak postupne zlyhajú všetky nápady uvedené v predchádzajúcich kapitolách, pozvoľna sa s nápadmi ako prispôsobiť našu aplikáciu dostávame k distribuovaným databázam.Ja by som ako skutočné distribuované databázy označil iba tie, ktoré:Nemajú úplnú replikáciu – čiže nie všetky dáta sa nachádzajú na všetkých uzlochPrimárna repliky sa nenachádzajú len na jednom uzleTo ktoré dáta sa nachádzajú na ktorom uzle nie je dopredu definované, ale je za behu menenéAž takto zadefinovaná distribuovaná databáza dokáže riešiť kvalitatívne inú skupinu problémov, ako databázy, ktoré tieto kritéria nespĺňajú. Na druhej strane ale takáto databáza prináša úplne inú skupinu problémov, ktoré musíme riešiť pri jej vývoji, prevádzke a vývoji systémov pre ňu.
- Tu je zoznam problémov, ktoré treba pri vývoji a práci s distribuovanými databázami brať do úvahy.Sú to: - prečítať body.Každému z nich venujem po jednom slajde,takže poďme si ich prejsť
- S CAP teorémou sa stretol asi každý, kto sa začal zaujímať o distribuované databázy.V princípe hovorí o tom, že neviem zostrojiť databázu, ktorá odrazu spĺňa vlastnosti dostupnosti, konzistentnosti a tolerancie voči rozdrobeniu siet, čiže absolútnemu výpadku medzi uzlami.Pomenovanie vlastností nie je jednoznačné a preto by som ich rád spresnil. Konzistentnosť v zmysle CAP teorémy znamená, že tá istá hodnota toho istého objektu je na všetkých miestach v databáze rovnaká. Ide teda vlastne o ten istý význam konzistentnosti, aký som vysvetloval pri eventuálnej konzistentnosti.Dostupnosť v zmysle CAP znamená, že databáza spracuje požiadavku v nejakom obmedzenom čase. Tento čas musí mať horné obmedzenie, napríklad vyjadrením zložitosťou požadovanej operácie. Čas potrebný na spracovanie požiadavky by sa mal dať nejakým spôsobom predvídať. Správna požiadavka navyše nemôže byť zamietnutá.Tolerancie k rozdrobeniu siete znamená, že uzly systému budú fungovať a odpovedať aj po strate spojenia so zvyšnými uzlami systému. Príklad na nemožnosť zostaviť systém spĺňajúci všetky tri kritériá je jednoduchý. Predstavte si že príde požiadavka na zmenu dát na uzol, ktorý stratil spojenie so zvyškom systému. Keďže nemôže komunikovať s ostatnými uzlami, má v zásade dve možnosti. Buď dáta zmení lokálne u seba, a po obnovení spojenia sa ich pokúsi zmergovať so zvyškom systému. Po lokálnej zmene dát ale budú dáta iné ako v zvyšku systému, čím sa poruší konzistentosť dát. Druhá možnosť je buď zamietnuť požiadavku, alebo čakať na obnovenie spojenia, kým ju vybavíme, čím sa poruší podmienka dostupnosti. CAP teoréma teda nie je nič zložité a je len formalizovaním niečoho, na čo by väčšina z nás prišla aj prostým sedliackym rozumom.Uvedené 3 vlastnosti sa dajú aj kombinovať, ale aj tak je zaujímavé pozrieť sa, ako vyzerajú systémy, ktoré si vyberajú dve z daných vlastností na 100% a čo z toho vyplýva.CP systémy nezaručujú dostupnosť a tak v prípade straty spojenia buď zamietajú požiadavky, alebo ich zamietajú po určitom timeoute, alebo čakajú s vybavením požiadaviek na obnovenie spojeniaAP systémy nezaručujú konzistentnosť dát a tak požiadavky sú vybavené aj keď nie je spojenie so zvyškom systému. Po obnovení spojenia musia byť dáta zmergované. Mergovanie je väčšinou náročné na logiku, lebo sa musí systém rozhodnúť, ktorým dátam dať prednosť.CA systémy netolerujú rozdrobenie siete. Rozdrobenie siete sa dá netolerovať napríklad tak, že uzly, ktoré stratia kontakt s väčšinou ostatných uzlov sú odpísané a ich úlohu preberú uzly, ktoré si kontakt s väčšinou udržali. Po opätovnom nadviazaní spojenia im sú opäť pridelené nové úlohy, prípade dôjde k resynchronizácii a opätovnému vráteniu starých úloh. Dostupnosť je síce zachovaná, ale nie v maximálnej možnej miere. Systém ostane dostupný iba používateľom, ktorí sú schopní komunikovať so zvyško systému – väčšinou uzlov. Pri CA systémoch treba dávať pozor, aby sa nerozpadli dominovým efektom a postupným vyradzovaním všetkých uzlov tak, ako sa bude strácať spojenie.Tolerancia k rozdrobeniu siete nemusí byť až taká dôležitá vlastnosť, lebo za normálnych okolností sieť rozdrobená nie je. Sieť môžeme spraviť navyše takú redundantnú a odolnú voči zlyhaniu, ako sa nám zažiada respektíve ako nám to finančné prostriedky dovolia.
- Kde sú dáta ktoré hľadám? Pridistribuovaných databázach s neúplnou replikáciou je to jedna z najzákladnejších otázok, ktoré riešime.Vždy keď chceme pristupovať k nejakým dátam musíme najskôr vedieť na ktorom uzle sa nachádzajú. Pri statickej tabuľke umiestnení máme napríklad napevno povedané, že dáta od toho do toho roku sú na tom uzle, dáta za iný rok sú na inom uzle.Z popisu požadovanej entity vieme jednoducho zistiť, na ktorom uzle sa nachádza. Toto podporujú aj niektoré relačné databázy.
- Ďalší prístup vyhľadávania spočíva v zadefinovaní N-dimenzionálneho priestoru, ktorého časti sú rozdelené medzi uzly. Ako najjednoduchšiu verziu si predstavte napríklad kružnicu .Potom je zadefinovaná funkcia, ktorá zobrazuje id entity do tohto priestoru. Teda v našom príklade hash funkciu, ktorá zobrazí id entity na nejaké miesto v tejto kružnici.Každý uzol pozná svojich susedov v priestore a tak keď hľadáme nejakú entitu, začneme na nejakom uzle, napríklad N8 a prehľadávame priestor. V priestore môžu existovať aj skratky –tzv. prsty, ktoré smerujú na opačnú stranu priestoru, štvrtinu, osminu, šetnástinu a tak ďalej. Pomocou prstov sme schopní nájsť bod v priestore so zložitosťou O(log N) a počet prstov bude tiež O(log N).Nevýhodou takéhoto systému je väčšia náročnosť vyhľadávania a nemožnosť zgrupiť dokopy entity podľa nejakého základného kritéria.Dáta môžu byť uložené aj redundante, napríklad posunutím priestoru. Tým sa dá zabezpečiť spamätanie sa databázy po výpadku niektorého uzla.Keď dôjde k výpadku niektorého uzla, ostatné uzly si musia nejakým spôsobom prerozdeliť priestor, ktorý vypadnutý uzol obhospodaroval. Možností je viacej, ale najjednoduchšie je, keď si tento priestor rozdelia susedia,
- Podľa mňa je najperspektívnejším prístupom dynamická tabuľka umiestnení.Voľne vysvetlené tabuľka entít je rozdelená na časti – partície a každý uzol má tabuľku umiestnení, v ktorej sú záznamy typu že entity s ID od 10 001 – 20 000 sú na uzle X a entity s ID 20 001 -30 000 sú na uzle Y.Identifikácia uzla na ktorom je entita je potom vo väčšine prípadov v konštantom čase.Veľkosť tabuľky umiestnení je síce O(N) ale v závislosti od veľkosti partície je výrazne menšia ako N – N/veľkosť partície.Dôležité je nájsť ideálny kľúč podľa ktorého sú entity v tabuľke zoradené a tým pádom aj zgrupené v partíciách. Tento zoraďovací kľúč potom plní funkciu primárneho kľúča, lebo len podľa neho vieme lokalizovať entitu. Redundanciu dát riešime vytvorením záložných partícii.Veľkou výhodou je možnosť robiť vyhľadávanie len nad časťou databázy podľa primárneho zoraďovacieho kľúča– čiže niekoľkými partíciami. Napríklad ak máme osoby a primárny zoraďovací kľúč je priezvisko + meno + id, môžeme prehľadať len tých ľudí, ktorých meno začína na „Kme“. Ďalšou výhodou je možnosť riadiť ktorá partícia sa kde nachádza. Na to je možné vymyslieť veľa rôznych stratégii, či už podľa záťaže jednotlivých uzlov, alebo blízkosti k používateľom.
- Concurrencykontróle pribúda v distribuovaných databázach ďalší rozmer zložitosti. Komunikácia medzi uzlami databázy má neurčitú odozvu a tak nie je možné atomické získanie všetkých zámkov potrebných pre tranzakciu.Navyše doba trvania tranzakcie naberá na neurčitosti o neurčitosť doby komunikácie medzi uzlami.Niektorý z uzlov môže navyše vypadnúť a zvyšok systému sa s tým musí vedieť vysporiadať.Vlastne zatiaľ sa mi nepodarilo naraziť na databázu, ktorá by bola plnohodnotne distribuovaná a zároveň implementovala aj plnohodnotné distribuované tranzakcie.Ak nejakú takú poznáte, budem vám vďačný za tip.Dobre teda v princípe sa môže distribuované concurrencycontrol zakladať na dvoch princípoch a ich obmenách, respektíve na kombnáciách ich týchto obmien.Dvojfázové zamykanie je založené na zámkach, ktoré v úvode tranzakcie nazbierame naprieč databázou, potom vykonáme tranzakciu a potom zámky uvolníme.Zoradené časové značky priraďujú časovú značku každej tranzakcii a verzionujú dáta vždy keď sú zmenené a pamätajú si aj časové značky read prístupov jednotlivých transakcií a podľa toho určujú, či je tranzakciu možné vykonať, alebo nie.Konflikty je možné riešiť čakaním, alebo reštartom tranzakcie.Rozoberať všetky možné kombinácie je nad rámec tejto prednášky a koho by to zaujímalo, tak vrelo odporúčam prečítať si tento článok z roku 1981
- Ďalším problémom s distribuovanými transakciami je jednotné rozhodnutie všetkých zúčastnených uzlov transakciu definitívne potvrdiť, alebo zrušiť.Všeobecne z terminológie distribuovaných systémov ide o problém konsenzu, kedy sa viacero uzlov musí zhodnúť na jednotnom rozhodnutí. Nebol by to problém, keby komunikácia medzi ktorýmikoľvek uzlami nemohla zlyhať v ktoromkoľvek okamihu. Dokonca je matematicky dokázané, že pre asynchrónne systémy, kde môže dôsť k byzantínskemu zlyhaniu uzlov neexistuje deterministický algoritmus na konsenzus. Aj najlepší z algoritmov dospeje k rozhodnutiu len eventuálne a nie v pevnom čase. Byzantínske zlyhanie je také, že namiesto toho, aby sa zlyhaný uzol odmlčal, začína šíriť náhodné, alebo nepravdivé správy.Pri dvojfázovom potvrdení sa najskôr koordinátor tranzakcie pýta všetkých uzlov, či je možné potvrdiť tranzakcu. Ak všetky povolia, tak tranzakciu potvrdí, inak nie.Pri trvalom zlyhaní koordinátora ostanú záznamy zúčastňujúce sa tranzakcie uzamknuté a je nutné ich manuálne odblokovať.Trojfázové potvrdenie len pridáva fázu pre-commit po uskutočnení ktorej môže dôjsť k zlyhaniu koordinátora, lebo tranzakcia sa automaticky potvrdí po uplynutí timeoutu.Ani trojfázové potvrdenie ale nie je dostatočne odolné voči zlyhaniu koordinátora a niektorého z uzlov.Až paxos potvrdenie prináša odolnosť voči (N - 1)/2 zlyhaniam, kde N je počet uzlov. Paxos algoritmus je pomerne zložitý na vysvetlenie a môžem ho vysvetliť po prednáške.
- Pre prostredie distribuovanej databázy musíme predefinovať vlastnosti ACID aj CAP pravdepodobnostnými definíciami podľa hesla nič nie je na 100%.Dostupnosť je definovaná ako pravdepodobnosť dostupnosti všetkých potrebných replík dát. Dostupnost je moznezvysitmoznostouzrusitsynchronnurepliku.Pravdepodobnosť straty môžeme získať vynásobením pravdepodobnosti straty jednotlivých replík. Ak čas potrebný na vytvorenie novej repliky je t a pravdepodobnosť zlyhania uzla za čas t je p, potom pravdepodobnosť simultánneho zlyhania n replík je p^n.Ak sú tieto pravdepodobnosti závislé javy, tak treba použiť vzorce pre závislé javy. A pozor...ak využijeme možnosť zrušiť repliku, tak automaticky už v nej nebudú konzistentné dáta.Konzistentosť v zmysle CAP teorémy počítame pre nesynchrónne repliky. ). Pravdepodobnosť prečítania nekonzistentnej verzie určitého údaju môžeme vyjadriť ako podiel okna nekonzistentnosti a periódy zmeny daného údaju. Pri distribuované databázy má taktiež význam zaoberať sa pravdepodobnosťou vzniku rozdrobenia siete. Pravdepodobnosti izolácie uzla, racku, alebo datacentra závisa od použitej sieťovej infraštruktúry a dajú sa vypočítať použitím pravdepodobnostných vzorcov a grafových algoritmov.Konzistentosť v zmysle ACID podmienok môže s použitím už spomenutých algoritmov ostať zachovaná. Overovanie constrainov môže vyžadovať viacero readov pre transakciu a tak ovplyvniť výkon. Aby došlo k porušeniu konzistentnosti, musí dôjsť buď k softvérovej chybe databázy, alebo k porušenu trvalosti a návratu k prepnutiu na nesynchrónnu repliku, alebo k obnoveniu zo zálohy.
- Aj na distribuované databázy je možné uplatniť všetky kompromisy pre zvýšenie výkonu, ktoré boli spomenuté pri nedistribuovaných databázach.Obzvlášť to platí pre eventuálnu konzistentnosť, ktorá by v distribuovaných DB mala byť databázou priamo podporovaná. Môžeme využiť dva princípy replikácie pri eventuálne konzistentných replikách. Pri push princípe tlačí synchrónna replika všetky svoje zmeny na eventuálne konzistentnú repliku. Pri pop princípe sa eventuálne konzistentná replika v pravidelných intervaloch dotazuje synchrónnej repliky na zmeny, ktoré nastali. Prvý princíp je rýchlejší, ale v princípe asi menej výkonný. Druhý má výhodu, že má priamo zabudovaný mechanizmus zisťovania straty kontaktu so synchrónnou replikou a má predvídateľnejšie okno nekonzistentnosti.One site transakcie vyžadujú prispôsobenie databázovej schémy. Základná idea je, že tranzakcia, ktorá je vykonávaná len na jednom uzle nepotrebuje distribuované tranzakcie a commit. Určite vás ale hneď napadnú situácie, kedy to tak celkom neplatí a tak sa dá táto technika využiť len v obmedzených prípadoch.O to perspektívnejšia je technika harwest a yield, ktorá ponúka rozumný kompromis medzi dostupnosťou a kvalitou výsledkov. Ak tranzakcia spracováva určitú množinu dát a niektoré z týchto dát nie je možné prečítať, môže sa transakcia uspokojiť aj s percentom spracovaných dát. Povolením nižšieho harwestu vlastne zvýšme dostupnosť systému. Používateľa môžeme o použitom harweste informovať.
- Keď si porovnáme distribuované databázy, ktoré sú momentálne na trhu s tým, čo by sa teoreticky dalo naprogramovať tak určite dôjdeme k záveru, že sú tu ešte veľké medzery.V tejto oblasti čaká IT svet ešte veľa úsilia.Implementácia distribuovanej databázy je z niekoľkých dôvodov výrazne náročnejšia, ako implementácia jednouzlových databáz.V prvom rade sa používajú zložitejšie algoritmy. Tie sú distribuované a tak musia fungovať aj pri výpadku ktoréhokoľvek uzla v ktoromkoľvek okamihu. Systém by sa mal vedieť s pomocou administrátora zotaviť aj po výpadku nadkritického množstva uzlov, tak aby sa minimalizovali straty.To súvisí s probmémom N na M stavov. Máme totiž n uzlov, pričom každý z nich sa môže nachádzať v M stavoch. V takýchto podmienkach sa veľmi ťažko robia deterministické algoritmy a ešte ťažšie sa testujú, prípadne sa dokazuje ich správnosť. Distribuovaná DB nám ponúka aj omnoho viacej optimalizácií, ktoré by mohla podporovať a tak sa výrazne rozširuje scope, čo by sa dalo implementovať.Perličkou na záver sú problémy, ako realizovať zmenu dátovej schémy, prípadne update databázy na novú verziu (ak si zoberieme množstvo uzlov, ktoré treba vymeniť).
- Ďakujem vám za pozornosť a dúfam, že vás moja prednáška zaujala.Teraz dávam priestor na vaše otázky.