it-swarm-eu.dev

Proč nemůže RDBM klastr tak, jak to dělá NoSQL?

Jedním z velkých plusů pro nosql DBMS je to, že se mohou snáze sdružovat. Pravděpodobně s NoSQL můžete vytvořit stovky levných strojů, které ukládají různá data a dotazují je najednou.

Moje otázka zní: Proč nemůže relační DBMS dělat to jako mysql nebo sql server? Je to, že prodejci prostě nepřišli na technický způsob, jak to udělat se svým stávajícím produktem, nebo existuje nějaký problém s relačním modelem, který brání tomu, aby to bylo proveditelné? Co je tak skvělého na NoSQL způsobu ukládání a přístupu k datům (klíč/hodnota, dokumenty atd.), Což usnadňuje sdružování, pokud je to vůbec pravda?

88
fregas

Distribuované databázové systémy 101

Nebo, Distribuované databáze - co ve skutečnosti FK znamená ' webové měřítko '?

Distribuované databázové systémy jsou složitá zvířátka a mají řadu různých příchutí. Pokud se do toho vrhnu do hloubky svých matně zapamatovaných studií na univerzitě, pokusím se vysvětlit některé klíčové technické problémy při budování distribuovaného databázového systému.

Nejprve nějaká terminologie

ACID (Atomicity, Consistency, Isolation and Durability) vlastnosti: Toto jsou klíčové invarianty, které musí musí být vynucena pro spolehlivou implementaci transakce, aniž by způsobila nežádoucí vedlejší účinky.

Atomicita vyžaduje, aby byla transakce dokončena nebo vrácena zpět. Částečně dokončené transakce by nikdy neměly být viditelné a systém musí být postaven tak, aby tomu nedocházelo.

Konzistence vyžaduje, aby transakce nikdy neporušovala invarianty (jako je deklarativní referenční integrita), které jsou zaručeny podle schématu databáze. Pokud například existuje cizí klíč, nemělo by být možné vložit podřízený záznam s úctou k neexistujícímu nadřazenému.

Izolace vyžaduje, aby transakce navzájem nezasahovaly. Systém by měl zaručit stejné výsledky, pokud jsou transakce prováděny paralelně nebo postupně. V praxi většina produktů RDBMS umožňuje režimy, které kompromitují izolaci proti výkonu.

Trvanlivost vyžaduje, aby po potvrzení transakce zůstala v trvalém úložišti způsobem, který je odolný vůči hardwaru nebo selhání softwaru.

Níže vysvětlím některé technické překážky, které tyto požadavky na distribuované systémy představují.

Architektura sdílených disků: Architektura, ve které všechny uzly zpracování v klastru mají přístup ke všem úložný prostor. To může představovat centrální překážku pro přístup k datům. Příkladem systému sdíleného disku je Oracle RAC nebo Exadata .

Sdílená architektura nic: Architektura, ve které mají uzly zpracování v klastru lokální úložiště, které není vidět do dalších uzlů clusteru. Příklady systémů sdílených nic nejsou Teradata a Netezza .

Architektura sdílené paměti: Architektura, ve které více procesorů (nebo uzlů) může přistupovat ke sdílenému fondu Paměť. Většina moderních serverů je typu sdílené paměti. Sdílená paměť usnadňuje určité operace, jako jsou mezipaměti nebo primitiva pro atomovou synchronizaci, které jsou na distribuovaných systémech mnohem obtížnější.

Synchronizace: Obecný pojem popisující různé metody pro zajištění konzistentního přístupu ke sdílenému prostředku pomocí několika procesů nebo vlákna. To je mnohem obtížnější v distribuovaných systémech než v systémech sdílené paměti, ačkoli některé síťové architektury (např. Teradata's BYNET) měly v síťovém protokolu synchronizační primitiva. Synchronizace může také přinést značné množství režijních nákladů.

Semi-Join: Primitiv použitý při spojování dat uchovávaných ve dvou různých uzlech distribuovaného systému. V podstatě sestává z dostatečného množství informací o řádcích, které se mají spojit, a předat je jedním uzlem do druhého, aby se spojení vyřešilo. U velkého dotazu by to mohlo znamenat značný síťový provoz.

Případná konzistence: Termín používaný k popisu sémantiky transakcí, které kompromitují okamžitou aktualizaci (konzistence na čtení) na všech uzlech distribuovaného systému pro výkon (a tedy vyšší propustnost transakce) při zápisu. Případná konzistence je vedlejším účinkem použití replikace kvora jako optimalizace výkonu pro urychlení transakčních transakcí v distribuovaných databázích, kde je na samostatných uzlech uchováváno více kopií dat.

Lamportův algoritmus: Algoritmus pro implementaci vzájemného vyloučení (synchronizace) napříč systémy bez sdílené paměti. Normálně vzájemné vyloučení v systému vyžaduje atomové čtení-porovnání-zápis nebo podobnou instrukci typu běžně praktického pouze v systému sdílené paměti. Existují další distribuované synchronizační algoritmy, ale Lamport's byl jedním z prvních a je nejznámější. Stejně jako většina distribuovaných synchronizačních mechanismů je Lamportův algoritmus silně závislý na přesném načasování a synchronizaci hodin mezi uzly clusteru.

dvoufázový závazek (2PC): Skupina protokolů, které zajišťují aktualizaci databáze zahrnující více fyzických systémů zavázat se nebo se vrátit zpět důsledně. Ať už je 2PC používán v systému nebo ve více systémech prostřednictvím správce transakcí, přináší to značnou režii.

Ve dvoufázovém potvrzovacím protokolu požádá správce transakcí zúčastněné uzly, aby transakci přetrvávaly tak, že mohou zaručit, že se zaváže, a poté tento stav signalizují. Když všechny uzly vrátily stav „šťastný“, signalizuje uzlům, aby se zavázaly. Transakce je stále považována za otevřenou, dokud všechny uzly neodesílají odpověď naznačující, že potvrzení je dokončeno. Pokud uzel zhasne před signalizací dokončení potvrzení, správce transakcí znovu dotazuje uzel, když se vrátí, dokud neobdrží kladnou odpověď označující, že se transakce potvrdila.

Kontrola více verzí (MVCC): Správa soupeření zápisem nových verzí dat do jiné umístění a umožnění jiným transakcím vidět starou verzi dat, dokud nebude nová verze potvrzena. Tím se snižuje soupeření s databází na úkor nějakého dalšího provozu při zápisu nové verze a označení staré verze jako zastaralé.

Algoritmus voleb: Distribuované systémy zahrnující více uzlů jsou ze své podstaty méně spolehlivé než jediný systém, protože existuje více režimy selhání. V mnoha případech je pro klastrované systémy nutné řešit selhání uzlu. Volební algoritmy jsou třídou algoritmů používaných k výběru vedoucího pro koordinaci distribuovaného výpočtu v situacích, kdy není „vedoucí“ uzel stoprocentně určen nebo spolehlivý.

Horizontální rozdělení na oddíly: Tabulka může být pomocí svého klíče rozdělena na více uzlů nebo svazků. To umožňuje, aby se velký objem dat rozdělil na menší kousky a distribuoval se mezi uzly úložiště.

Sharding: Datová sada může být horizontálně rozdělena na více fyzických uzlů v architektuře sdíleného-nic. Pokud toto rozdělení není průhledné (tj. Klient si musí být vědom schématu rozdělení a zjistit, který uzel se má explicitně dotazovat), nazývá se to sharding. Některé systémy (např. Teradata) dělají data rozdělená mezi uzly, ale umístění je pro klienta transparentní; termín se obvykle nepoužívá ve spojení s tímto typem systému.

Konzistentní hašování: Algoritmus používaný k alokaci dat do oddílů na základě klíče. Vyznačuje se rovnoměrným rozložením hash klíčů a schopností pružně rozšiřovat nebo snižovat počet kbelíků. Díky těmto atributům je užitečné rozdělovat data nebo načítat v clusteru uzlů, kde se velikost může dynamicky měnit s přidáváním nebo vyřazováním uzlů (pravděpodobně kvůli selhání).

Multi-Master Replication: Technika, která umožňuje replikaci zápisů napříč několika uzly v klastru ostatní uzly. Tato technika usnadňuje škálování tím, že umožňuje, aby některé tabulky byly rozděleny nebo shardovány mezi servery a jiné byly synchronizovány v klastru. Zápisy musí být replikovány do všech uzlů na rozdíl od kvora, takže transakční transakce jsou dražší na replikované architektuře s více mastery než na replikovaném systému kvora.

Přepínač bez blokování: Síťový přepínač, který používá interní hardwarový paralelismus k dosažení propustnosti, která je úměrná počet portů bez interních úzkých hrdel. Naivní implementace může použít mechanismus crossbar, ale to má O (N ^ 2) složitost pro N porty, což ji omezuje na menší přepínače. Větší přepínače mohou používat složitější interní topologii nazývanou neblokující přepínač minimálního rozpětí, aby bylo dosaženo lineárního škálování propustnosti, aniž by bylo třeba hardwaru O (N ^ 2).

Vytvoření distribuované DBMS - jak těžké to může být?

Několik technických výzev to v praxi ztěžuje. Kromě přidané složitosti budování distribuovaného systému musí architekt distribuované DBMS překonat některé složité technické problémy.

Atomicita v distribuovaných systémech: Pokud jsou data aktualizovaná transakcí rozložena do více uzlů, musí být koordinace potvrzení/vrácení uzlů koordinována. To zvyšuje významnou režii u systémů sdílených-nic. V systémech sdílených disků je to menší problém, protože všechny uzly mohou vidět všechny úložiště, takže jediný uzel může koordinovat potvrzení.

Konzistence v distribuovaných systémech: Abychom si mohli vzít příklad výše uvedeného cizího klíče, musí být systém schopen vyhodnotit konzistentní stav. Například, pokud by nadřazený a podřízený vztah cizího klíče mohl sídlit na různých uzlech, je třeba nějaký druh distribuovaného zamykacího mechanismu, aby bylo zajištěno, že pro ověření transakce nebudou použity zastaralé informace. Pokud to není vynuceno, můžete mít (například) rasový stav, kdy je rodič odstraněn po ověření jeho přítomnosti před povolením vložení dítěte.

Opožděné vynucení omezení (tj. Čekání na potvrzení ověření DRI) vyžaduje, aby byl zámek držen po celou dobu transakce. Tento druh distribuovaného zamykání přichází se značnou režií.

Jsou-li uchovávány více kopií dat (to může být nutné v systémech sdílených - nic, aby se předešlo zbytečnému síťovému provozu ze spojení), musí být aktualizovány všechny kopie dat.

Izolace v distribuovaných systémech: Kde jsou data ovlivněná transakcí uložena na více systémových uzlech, musí být zámky a verze (pokud se používá MVCC) synchronizovány napříč uzly. Zaručení serializovatelnosti operací, zejména na architekturách sdílených nic, kde lze ukládat nadbytečné kopie dat, vyžaduje distribuovaný synchronizační mechanismus, jako je Lamportův Algoritmus, který také přináší značnou režii v síťovém provozu.

Trvanlivost v distribuovaných systémech: V systému sdílených disků je problém s trvanlivostí v zásadě stejný jako systém se sdílenou pamětí, s tou výjimkou, že distribuované synchronizační protokoly jsou stále požadováno napříč uzly. DBMS musí zapisovat do protokolu deník a důsledně zapisovat data. V systému sdíleného typu nic nemusí existovat více kopií dat nebo částí dat uložených v různých uzlech. Protokol dvoufázového potvrzování je nutný k zajištění toho, že potvrzení probíhá přes uzly správně. To také vede k značné režii.

V systému sdílených nic nemůže ztráta uzlu znamenat, že data nejsou k dispozici systému. Pro zmírnění těchto dat mohou být replikována napříč více než jedním uzlem. Konzistence v této situaci znamená, že data musí být replikována do všech uzlů, kde se obvykle nacházejí. To může způsobit značnou režii při psaní.

Jednou běžnou optimalizací provedenou v systémech NoSQL je použití replikace kvora a případné konzistence, která umožňuje, aby se data mohla replikovat líně a zároveň zaručovala určitou úroveň odolnosti dat zápisem do kvora před nahlášením transakce jako závazku. Data jsou pak líně replikována do ostatních uzlů, kde jsou uloženy kopie dat.

Povšimněte si, že „případná konzistence“ je zásadním kompromisem v oblasti konzistence, který nemusí být přijatelný, pokud je třeba údaje prohlížet konzistentně, jakmile je transakce potvrzena. Například u finanční aplikace by měl být okamžitě k dispozici aktualizovaný zůstatek.

Systémy sdíleného disku

Systém sdílených disků je takový, kde všechny uzly mají přístup ke všem úložným prostorům. Výpočet je tedy nezávislý na umístění. V tomto režimu může fungovat také mnoho databází DBMS - Oracle RAC je příkladem takové architektury.

Systémy sdílených disků se mohou podstatně škálovat, protože mohou podporovat vztah M: M mezi uzly úložišť a uzly zpracování. A SAN může mít více řadičů a databáze může spouštět více serverů. Tyto architektury mají přepínač jako centrální úzký profil, ale přepínače příčníků umožňují tomuto přepínači mít velkou šířku pásma. Některé zpracování může být mimo provoz na uzly úložiště (jako v případě Oracle Exadata), což může snížit přenos na šířce pásma úložiště.

Přestože je přepínač teoreticky překážkou dostupné šířky pásma, znamená to, že architektury sdílených disků se poměrně efektivně přizpůsobí velkým objemům transakcí. Většina běžných architektur DBMS používá tento přístup, protože poskytuje dostatečně dobrou škálovatelnost a vysokou spolehlivost. U redundantní architektury úložiště, jako je vláknový kanál, neexistuje jediný bod selhání, protože mezi jakýmkoli zpracovávacím uzlem a jakýmkoli úložným uzlem jsou nejméně dvě cesty.

Sdílené-nic systémy

Sdílené systémy jsou systémy, kde alespoň některá data jsou držena lokálně v uzlu a nejsou přímo viditelná pro jiné uzly. Tím se odstraní úzký profil centrálního přepínače, což umožňuje databázi škálovat (alespoň teoreticky) počet uzlů. Horizontální dělení umožňuje rozdělení dat mezi uzly; to může být pro klienta transparentní nebo ne (viz Sharding výše).

Protože data jsou neodmyslitelně distribuována, může dotaz vyžadovat data z více než jednoho uzlu. Pokud spojení vyžaduje data z různých uzlů, použije se operace polospojení k přenosu dostatečného množství dat pro podporu spojení z jednoho uzlu do druhého. To může mít za následek velké množství síťového provozu, takže optimalizace distribuce dat může mít velký vliv na výkon dotazu.

Data jsou často replikována napříč uzly sdíleného systému bez omezení, aby se snížila nutnost polospojování. To funguje docela dobře na zařízení pro datový sklad, protože rozměry jsou obvykle o mnoho řádů menší než tabulky skutečností a lze je snadno replikovat přes uzly. Obvykle jsou také načteny v dávkách, takže režie replikace je menší problém, než by tomu bylo u transakční aplikace.

Díky inherentní paralelitě architektury se sdíleným-ničím se dobře hodí k takovým druhům tabulkových skenování/agregovaných dotazů, které jsou charakteristické pro datový sklad. Tento druh operace se může škálovat téměř lineárně s počtem uzlů zpracování. Velké spoje napříč uzly mají tendenci vytvářet více režijních nákladů, protože operace polospojování mohou generovat velké množství síťového provozu.

Přesouvání velkých objemů dat je méně užitečné pro aplikace pro zpracování transakcí, kde režie více aktualizací způsobuje, že tento typ architektury je méně atraktivní než sdílený disk. Tento typ architektury tedy nemá tendenci se široce používat mimo aplikace datového skladu.

Střípky, replikace kvora a případná konzistence

Replikace kvora je zařízení, kde DBMS replikuje data pro vysokou dostupnost. To je užitečné pro systémy určené k práci na levnějším komoditním hardwaru, který nemá vestavěné funkce s vysokou dostupností, jako je SAN. V tomto typu systému jsou data replikována ve více uzlech úložiště pro výkon čtení a redundantní úložiště, aby byl systém odolný vůči selhání hardwaru uzlu.

Replikace zápisů do všech uzlů je však pro uzly M a N zápisem O (M x N). Díky tomu je zápis drahý, pokud zápis musí být replikován do všech uzlů, než je transakce dovolena se zavázat. Replikace kvora je kompromis, který umožňuje okamžitou replikaci zápisů do podmnožiny uzlů a pak je na pozadí zaneprázdněn na ostatních uzlech. Zápisy lze spáchat rychleji, přičemž poskytují určitou míru redundance zajištěním jejich replikace na minimální podmnožinu (kvora) uzlů před tím, než je transakce hlášena jako odevzdaná klientovi.

To znamená, že čtení mimo uzly mimo kvora může vidět zastaralé verze dat, dokud proces na pozadí nedokončí zápis dat do zbývajících uzlů. Sémantika je známá jako „eventuální konzistence“ a může, ale nemusí být přijatelná v závislosti na požadavcích vaší aplikace, ale znamená, že transakční závazky jsou blíže k O(1) než O(n) ve využití zdrojů.

Sharding vyžaduje, aby si klient uvědomil rozdělení dat do databází, často pomocí typu algoritmu známého jako „konzistentní hašování“. V sdílené databázi klient hashe klíč k určení, na který server v klastru se má dotaz vydat. Protože jsou požadavky distribuovány mezi uzly v klastru, nedochází k úzkým místům s jediným uzlem koordinátoru dotazů.

Tyto techniky umožňují databázi škálovat téměř lineární rychlostí přidáním uzlů do klastru. Teoreticky je replikace kvora nezbytná pouze tehdy, je-li podkladové úložné médium považováno za nespolehlivé. To je užitečné, pokud mají být použity komoditní servery, ale má menší hodnotu, pokud má základní mechanismus úložiště vlastní schéma vysoké dostupnosti (například a SAN se zrcadlovými řadiči a vícecestnou připojitelností k hostitelé).

Například služba BigTable společnosti Google neimplementuje replikaci kvora sama o sobě, i když je umístěna na systému souborů GFS, clusterovém systému souborů, který používá replikaci kvora. BigTable (nebo jakýkoli sdílený systém) mohl použít spolehlivý úložný systém s více řadiči a rozdělit data mezi řadiče. Paralelní přístup by pak byl dosažen rozdělením dat.

Zpět na platformy RDBMS

Neexistuje žádný vlastní důvod, proč by tyto techniky nemohly být použity s RDBMS. Správa zámků a verzí by však byla v takovém systému poměrně složitá a jakýkoli trh pro takový systém by pravděpodobně byl docela specializovaný. Žádná z běžných platforem RDBMS nepoužívá replikaci kvora a nejsem si konkrétně vědom žádného produktu RDBMS (přinejmenším jednoho, který nemá žádné významné využití), který tak činí.

Systémy se sdíleným diskem a sdíleným diskem se mohou škálovat až na velmi velké pracovní zatížení. Například Oracle RAC může podporovat 63 uzlů zpracování (což by mohly být velké stroje SMP samy o sobě) a libovolný počet řadičů úložiště v síti SAN. Produkt IBM Sysplex (klastr sálových počítačů zSeries) může podporovat více sálových počítačů (každý se značným výkonem zpracování a vlastní šířkou pásma I/O) a více řadičů SAN). Tyto architektury mohou podporovat velmi velké transakce svazky se sémantikou ACID, i když předpokládají spolehlivé úložiště. Teradata, Netezza a další prodejci vytvářejí vysoce výkonné analytické platformy založené na designech sdílených dat, které se rozšiřují na extrémně velké objemy dat.

Doposud na trhu levných, ale velmi velkých objemů plně ACID RDBMS platforem dominuje MySQL, která podporuje sharding a multi-master replikaci. MySQL nepoužívá replikaci kvora k optimalizaci propustnosti zápisu, takže transakční transakce jsou dražší než v systému NoSQL. Sharding umožňuje velmi vysokou propustnost čtení (například Facebook používá MySQL značně), takže tento typ architektury se dobře přizpůsobuje pracovním vytížením náročným na čtení.

Zajímavá debata

BigTable je architektura sdílená - nic (v podstatě distribuovaný pár klíč - hodnota), jak zdůraznil Michael Hausenblas níže . Moje původní hodnocení zahrnovalo motor MapReduce, který není součástí BigTable, ale normálně by se používal ve spojení s ním v jeho nejběžnějších implementacích (např. Hadoop/HBase a Google MapReduce framework).

Při porovnání této architektury s Teradata, která má fyzickou afinitu mezi úložištěm a zpracováním (tj. Uzly mají místo lokálního úložiště místo sdíleného SAN), byste mohli argumentovat, že BigTable/MapReduce je architektura sdílených disků prostřednictvím globálně viditelného paralelního úložného systému.

Propustnost zpracování systému stylu MapReduce, jako je Hadoop, je omezena šířkou pásma neblokujícího síťového přepínače.1 Přepínače bez blokování však mohou zpracovat agregáty s velkou šířkou pásma kvůli paralelismu vlastnímu návrhu, takže jsou zřídka významným praktickým omezením výkonu. To znamená, že architektura sdílených disků (možná lépe označovaná jako systém sdílených úložišť) se může přizpůsobit velkým pracovním zatížením, i když je síťový přepínač teoreticky ústředním problémem.

Původním bodem bylo poznamenat, že ačkoli tento centrální problém existuje v systémech sdílených disků, může být diskový subsystém s několika oddíly úložiště (např. Tablety BigTable tablet nebo SAN řadiče) stále škálovatelný Architektura neblokujících přepínačů dokáže (teoreticky) zpracovat tolik současných připojení, kolik má portů.

1 Dostupné zpracování a propustnost I/O samozřejmě také představují omezení výkonu, ale síťový přepínač je ústředním bodem, kterým prochází veškerý provoz.

Relační databáze mohou klastrovat jako řešení NoSQL. Udržování ACID vlastností to může komplikovat a je třeba si uvědomit kompromisy provedené za účelem zachování těchto vlastností. Bohužel, co přesně jsou kompromisy, záleží na pracovní zátěži a samozřejmě na rozhodnutích při navrhování databázového softwaru.

Například, primárně OLTP pracovní vytížení může mít další latenci jediného dotazu, i když je měřítko propustnosti klastru pěkně. Tato dodatečná latence by mohla být nevšimnuta nebo být skutečným přerušovačem transakcí, vše v závislosti na aplikaci. Klastrování obecně zlepší propustnost a zraní latenci, ale i toto „pravidlo“ je podezřelé, pokud jsou dotazy aplikace zvláště přístupné paralelnímu zpracování.

Společnost, pro kterou pracuji, Clustrix , nabízí řadu homogenních výpočetních a úložných uzlů spojených relativně vysokou rychlostí sítě. Relační data jsou hash distribuován v uzlech na základě jednotlivých indexů v blocích, které nazýváme „plátky“. Každý řez bude mít dvě nebo více replik rozmístěných v klastru kvůli trvanlivosti v případě selhání uzlu nebo disku. Klienti se mohou připojit k libovolnému uzlu v klastru a vydávat dotazy pomocí drátového protokolu MySQL.

Je trochu nepřirozené myslet na komponenty ACID databáze samostatně, protože tolik se to spojuje dohromady, ale jde to takto:

Atomicita - Clustrix používá k zajištění atomicity dvě fázové potvrzení. Operace UPDATE a DELETE také zamknou řádky prostřednictvím našeho distribuovaného správce zámků, protože tyto operace interně proměníme v SELECT a následují přesné operace UPDATE/DELETE.

Atomicita zjevně zvyšuje množství zpráv mezi uzly účastnícími se transakce a zvyšuje zatížení těchto uzlů při zpracování potvrzovacího protokolu. Toto je část režie za distribuovaný systém a omezila by se škálovatelnost, pokud by se každý uzel účastnil každé transakce, ale uzly se účastní transakce pouze tehdy, pokud mají zapisovanou jednu z replik.

Konzistence - Cizí klíče jsou implementovány jako spouštěče, které jsou vyhodnoceny v době potvrzení. Operace UPDATE a DELETE s velkým dosahem mohou naše uzamčení z důvodu uzamčení ublížit, ale naštěstí je nevidíme tak často. Je mnohem běžnější vidět aktualizaci transakce/smazat několik řádků a poté potvrdit.

Druhou částí konzistence je udržování usnášeníschopnosti prostřednictvím PAXOS konsensuální protokol , který zajišťuje, že pouze klastry s většinou známých uzlů jsou schopny pořizovat zápisy. Je samozřejmě možné, že klastr má kvora, ale stále chybí data (všechny repliky řezu offline), což způsobí selhání transakcí, které přistupují k jednomu z těchto řezů.

Izolace - Clustrix poskytuje izolaci MVCC na úrovni kontejneru. Naše atomicita zaručuje, že všechny použitelné repliky obdrží konkrétní zápis dříve, než nahlásíme transakci, která byla odevzdána, většinou redukuje problém s izolací na to, co byste měli v případě bez klastrů.

Trvanlivost - Každý řez relačních dat je uložen do dvou nebo více uzlů, aby byla zajištěna odolnost v případě selhání uzlu nebo disku. Pravděpodobně také stojí za zmínku, že verze zařízení našeho produktu má kartu NVRAM, kde je WAL uložena z důvodu výkonu. Mnoho databází jedné instance zlepší výkon svých licencí WAL kontrolou v intervalech místo v každém potvrzení. Tento přístup je v distribuovaném systému problematický, protože umožňuje „přehrát, kde?“ složitá otázka. Zabraňujeme tomu v zařízení poskytováním záruky tvrdé trvanlivosti.

22
Matt

Základní odpovědí je, že model konzistence je jiný. Píšu to, abych rozšířil odpověď ConcernedOfTunbridge, která by pro to měla být referenčním bodem.

Základním bodem modelu konzistence ACID je to, že poskytuje spoustu základních záruk, pokud jde o stav dat globálně v systému. Tyto záruky podléhají omezením věty CAP, což v podstatě znamená, že aby byly funkční, musíte mít všechny autoritativní zdroje na stejné stránce, než sdělíte aplikaci, že jste provedli transakci. Multi-master replikace je tedy velmi obtížné provést, aniž by docházelo k těmto omezením. Jakmile začnete provádět asynchronní replikaci v prostředí s více mastery, tyto záruky jdou z okna. Model konzistence ACID je silný model konzistence určený pro důležité nebo kritické informace.

Model konzistence BASE je slabý model konzistence určený pro nekritické informace. Protože záruky jsou výrazně slabší, je schopnost nabízet takové slabé záruky v systémech s více mastery snadněji dosažitelná, protože záruky jsou, samozřejmě, slabé.

RDBMS to může a dělá měřítko stejně jako řešení NoSQL!

Existují však případy, kdy se RDBMS mohou a dělají v měřítku do té míry, že by NoSQL nebyla schopna se vyrovnat. Prostě to dělá jinak. Podívám se na Postgres-XC jako na příklad toho, jak je možné škálování, aniž by obětoval silné záruky konzistence.

Způsob, jakým tyto konkrétní RDBMS dělají, je implementovat něco jako střižné řešení s proxy a něco jako architektura sdílených disků, ale podstatně složitější než oba. Nemají měřítko stejným způsobem jako řešení NoSQL, takže kompromisy jsou odlišné.

Model Postgres-XC je, jak jsem pochopil, inspirován Teradatou. Skládá se z uzlů ve dvou různých rolích, jako uzlů úložišť nebo koordinátorů. Koordinátoři jsou multi-master (nejde o skutečnou replikaci) a připojují se k uzlům úložišť, aby zpracovali skutečné zpracování dat. Uzly úložiště se replikují v nastavení master-slave. Každý uzel úložiště obsahuje v podstatě střep databáze, ale koordinátoři udržují konzistentní obraz dat.

Jedná se o významné oddělení odpovědnosti. Uzly úložišť spravují data, kontrolují omezení, místně vynutitelná omezení cizího klíče a zpracovávají alespoň nějakou agregaci dat. Koordinátoři zpracovávají ty cizí klíče, které nelze místně vynutit, a také úvahy o oknech a dalších údajích, které mohou vytáhnout z více datových uzlů. Koordinátoři v podstatě umožňují ACID v distribuovaných transakcích v nastavení typu multi-master, kde uživatel ani neví, že jsou transakce distribuovány.

V tomto ohledu nabízí Postgres-XC něco podobného jako možnosti škálování NoSQL, ale díky dodatečným zárukám konzistence existuje ještě větší složitost. Chápu, že existují komerční RDBMS, které však nabízejí tento druh škálovatelnosti. Teradata to dělá. Podobné systémy sdílených disků se mohou podobným způsobem škálovat a DB2 i Oracle taková řešení nabízejí. Je tedy zcela nespravedlivé tvrdit, že to RDBMS nedokáže. Oni mohou. V minulosti však byla tak malá potřeba, že úspory z rozsahu nebyly dostatečné k tomu, aby byla proprietární řešení pro většinu hráčů cenově dostupná.

Nakonec poznámka o VoltDB. Stejně jako řešení NoSQL považuji VoltDB za velmi specializovaný nástroj. Je to velmi rychlé, ale na úkor vícenásobných transakcí a trvanlivosti na disku. To znamená, že máte velmi odlišné obavy. VoltDB je to, co získáte, když průkopníci RDBMS vytvoří řešení NoSQL ;-). VoltDB je zčásti rychlý, protože z rovnice definuje souběžnost a trvanlivost. Trvanlivost se stává vlastností sítě, nikoli vlastností uvnitř hostitele a souběžnost je spravována spuštěním dotazů jeden po druhém, interně paralelně, v sekvenčním pořadí. Nejedná se o tradiční RDBMS (a to je dobrá věc btw, protože může jít tam, kde tradiční RDBMS nemůže, ale obrácení je také velmi pravdivé).

pravit: Je také důležité zvážit důsledky spojení. V clusterových systémech se spojení stává velmi odlišným výkonem. Pokud je vše na stejném uzlu, může to zlepšit výkon, ale pokud musíte provést okružní cestu do jiného uzlu, bude to vyžadovat velmi vysoké náklady. Datové modely tedy dělají rozdíly a přístup klastrování má dopad na výkon. Přístupy, jako je Postgres-XC a Postgres-XL, předpokládají, že můžete strávit spoustu času přemýšlením o věcech, abyste mohli náležitě chránit svá data a udržovat spojené údaje pohromadě. Ale to vyžaduje režii designu. Na druhé straně se to přizpůsobuje mnohem lépe než mnoho řešení NoSQL a lze jej vhodně vyladit. Například my (v Úpravě) používáme klastrovací strategii podobnou NoSQL pro naše 3,5PB dat v PostgreSQL, což je v podstatě log analýza. A mnoho našich návrhů je hluboce inspirováno klastrovými strategiemi NoSQL. Proto někdy datový model omezuje také klastrovací model.

15
Chris Travers

Moje odpověď nebude tak dobře napsaná jako ta předchozí, ale je to tady.

Michael Stonebraker of Ingres sláva vytvořil MPP sdílené-nic sloupec-store (Vertica) a MPP sdílené-nic Nová databáze SQL (VoltDB), která distribuuje data mezi různými uzly v klastru a udržuje ACID. Vertica od té doby koupila společnost HP.

Věřím, že i jiné nové databáze SQL udržují ACID, i když si nejsem jistý, kolik z nich distribuuje své řádky přes klastr atd.

Tady je řeč, kterou Stonebraker dal na New SQL ve vztahu k NoSQL a "Old SQL". http://www.youtube.com/watch?v=uhDM4fcI2aI

6
geoffrobinson

MySQL klastrování může shard pomocí multi mastering replikace a hash shards přes klastr.

1
Jeremy Singer