Ahoj, Khabrovite. Tradičně pokračujeme ve sdílení zajímavého materiálu v předvečer zahájení nových kurzů. Dnes jsme speciálně pro vás přeložili článek o Google Cloud Spanner, načasovaný tak, aby se shodoval se zahájením kurzu .
Původně publikováno v .
Jako společnost, která nabízí celou řadu cloudových řešení POS pro maloobchodníky, restauratéry a online obchodníky po celém světě, Lightspeed používá několik různých typů databázových platforem pro různé případy použití v oblasti transakcí, analýzy a vyhledávání. Každá z těchto databázových platforem má své silné a slabé stránky. Proto, když Google uvedl na trh Cloud Spanner - slibné funkce, které ve světě relačních databází nejsou k vidění, jako je prakticky neomezená horizontální škálovatelnost a 99,999% dohoda o úrovni služeb (SLA) , Nemohli jsme si nechat ujít příležitost mít ji ve svých rukou!
Abychom poskytli ucelený přehled o našich zkušenostech s Cloud Spanner, stejně jako o kritériích hodnocení, která jsme použili, probereme následující témata:
- Naše hodnotící kritéria
- Cloud Spanner v kostce
- Naše hodnocení
- Naše zjištění
1. Naše hodnotící kritéria
Než se ponoříme do specifik Cloud Spanner, jeho podobností a rozdílů s jinými řešeními na trhu, pojďme si nejprve promluvit o hlavních případech použití, které jsme měli na mysli, když jsme zvažovali, kam nasadit Cloud Spanner v naší infrastruktuře:
- Jako náhrada za (převažující) tradiční řešení databáze SQL
- Jako řešení OLTP s podporou OLAP
Poznámka: Pro snadné srovnání tento článek porovnává Cloud Spanner s variantami MySQL z rodin řešení GCP Cloud SQL a Amazon AWS RDS.
Použití Cloud Spanner jako náhrada za tradiční řešení SQL databáze
V prostředí tradiční databází, když se doba odezvy na databázový dotaz blíží nebo dokonce překračuje předem definované prahové hodnoty aplikace (především kvůli nárůstu počtu uživatelů a/nebo požadavků), existuje několik způsobů, jak zkrátit dobu odezvy na přijatelnou úroveň. Většina těchto řešení však zahrnuje ruční zásah.
Například prvním krokem, který je třeba udělat, je podívat se na různá nastavení databáze související s výkonem a vyladit je tak, aby co nejlépe odpovídala vzorcům scénářů použití aplikací. Pokud to nestačí, můžete zvolit měřítko databáze svisle nebo vodorovně.
Škálování aplikace znamená aktualizaci instance serveru, obvykle přidáním více procesorů/jádrů, větší paměti RAM, rychlejšího úložiště atd. Přidání dalších hardwarových prostředků má za následek zvýšení výkonu databáze, měřeno primárně v počtu transakcí za sekundu, a latenci transakcí pro systémy OLTP. Relační databázové systémy (které používají vícevláknový přístup), jako je MySQL, se dobře vertikálně škálují.
Tento přístup má několik nevýhod, ale nejviditelnější je maximální velikost serveru na trhu. Jakmile je dosaženo největšího limitu instance serveru, zbývá pouze jedna cesta: zmenšit.
Scale-out je přístup, který přidává další servery do clusteru, aby se v ideálním případě lineárně zvýšil výkon s přibývajícími servery. Většina tradiční databázové systémy se neškálují dobře nebo se neškálují vůbec. Například MySQL může škálovat pro čtení přidáním slave čteček, ale nemůže škálovat pro zápisy.
Na druhou stranu může Cloud Spanner díky své povaze snadno horizontálně škálovat s minimálními zásahy.
Plně vybavený DBMS jako služba je třeba hodnotit z různých úhlů pohledu. Jako základ jsme vzali nejoblíbenější DBMS v cloudu – pro Google GCP Cloud SQL a pro Amazon AWS RDS. V našem hodnocení jsme se zaměřili na následující kategorie:
- Mapování funkcí: rozsah SQL, DDL, DML; připojovací knihovny/konektory, podpora transakcí a tak dále.
- Podpora vývoje: Snadný vývoj a testování.
- Podpora administrace: Správa instancí, jako je škálování nahoru/dolů a aktualizace instancí; SLA, zálohování a obnova; zabezpečení/kontrola přístupu.
Použití Cloud Spanner jako řešení OLTP s podporou OLAP
I když Google výslovně neuvádí, že Cloud Spanner je určen pro analýzu, sdílí některé atributy s jinými motory, jako jsou Apache Impala & Kudu a YugaByte, které jsou navrženy pro pracovní zátěže OLAP.
I kdyby existovala jen malá šance, že Cloud Spanner obsahuje konzistentní škálovatelný HTAP (Hybrid Transactional/Analytic Processing) engine s (více či méně) použitelnou sadou funkcí OLAP, myslíme si, že by si to zasloužilo naši pozornost.
S ohledem na to jsme se podívali na následující kategorie:
- Podpora načítání dat, indexů a dělení
- Výkon dotazů a DML
2. Cloud klíč v kostce
Google Spanner je seskupený systém pro správu relačních databází (RDBMS), který Google používá pro několik svých vlastních služeb. Google ji na začátku roku 2017 veřejně zpřístupnil uživatelům Google Cloud Platform.
Zde jsou některé atributy Cloud Spanner:
- Vysoce konzistentní, škálovatelný cluster RDBMS: Používá hardwarovou synchronizaci času k zajištění konzistence dat.
- Podpora transakcí napříč tabulkami: Transakce mohou zahrnovat více tabulek – nemusí být nutně omezeny na jednu tabulku (na rozdíl od Apache HBase nebo Apache Kudu).
- Tabulky založené na primárním klíči: Všechny tabulky musí mít deklarovaný primární klíč (PC), který se může skládat z více sloupců tabulky. Tabulková data jsou uložena v PC pořadí, což je velmi efektivní a rychlé pro PC vyhledávání. Stejně jako u jiných systémů na bázi PC musí být implementace modelována s ohledem na předem vytvořené případy použití, aby bylo dosaženo .
- Pruhované tabulky: Tabulky mohou mít na sobě fyzické závislosti. Řádky podřízené tabulky lze porovnat s řádky nadřazené tabulky. Tento přístup urychluje hledání vztahů, které lze určit ve fázi datového modelování, například při spojování zákazníků a jejich faktur.
- Indexy: Cloud Spanner podporuje sekundární indexy. Index se skládá z indexovaných sloupců a všech sloupců PC. Volitelně může index obsahovat také další neindexované sloupce. Index lze prokládat s nadřazenou tabulkou pro urychlení dotazů. Na indexy se vztahuje několik omezení, například maximální počet dalších sloupců, které lze uložit do indexu. Také dotazy prostřednictvím indexů nemusí být tak přímočaré jako v jiných RDBMS.
„Cloud Spanner vybírá index automaticky pouze ve výjimečných případech. Cloud Spanner zejména automaticky nevybere sekundární index, pokud dotaz vyžaduje sloupce, které nejsou uloženy ".
- Smlouva o úrovni služeb (SLA): Nasazení v jednom regionu s 99,99 % SLA; multiregionální nasazení s 99,999% SLA. I když samotná smlouva SLA je pouze dohodou a nikoli zárukou jakéhokoli druhu, domnívám se, že lidé z Googlu mají některá tvrdá data, aby mohli vznést tak silné tvrzení. (Pro informaci, 99,999 % znamená 26,3 sekund výpadku služby za měsíc.)
- Další:
Poznámka: Projekt Apache Tephra přidává pokročilou podporu transakcí do Apache HBase (také nyní implementován v Apache Phoenix jako beta).
3. Naše hodnocení
Všichni jsme tedy četli prohlášení společnosti Google o výhodách Cloud Spanner – prakticky neomezené horizontální škálování při zachování vysoké konzistence a velmi vysoké SLA. Přestože je těchto tvrzení v každém případě extrémně obtížné dosáhnout, naším cílem nebylo je vyvrátit. Místo toho se zaměřme na jiné věci, které většinu uživatelů databáze zajímají: paritu a použitelnost.
Cloud Spanner jsme hodnotili jako náhradu za Sharded MySQL
Google Cloud SQL a Amazon AWS RDS, dvě z nejpopulárnějších OLTP databází na cloudovém trhu, mají velmi rozsáhlou sadu funkcí. Chcete-li však škálovat tyto databáze nad velikost jednoho uzlu, musíte provést rozdělení aplikací. Tento přístup vytváří další složitost pro aplikace i správu. Podívali jsme se na to, jak Spanner zapadá do scénáře kombinování více úlomků do jedné instance a jaké funkce (pokud vůbec nějaké) bude třeba obětovat.
Podpora pro SQL, DML a DDL, stejně jako konektor a knihovny?
Za prvé, když začínáte s jakoukoli databází, musíte vytvořit datový model. Pokud si myslíte, že můžete připojit JDBC Spanner ke svému oblíbenému nástroji SQL, zjistíte, že s ním můžete dotazovat svá data, ale nemůžete jej použít k vytvoření tabulky nebo aktualizace (DDL) nebo jakéhokoli vkládání/aktualizace/mazání operace (DML). Oficiální JDBC Google také nepodporuje.
"Ovladače aktuálně nepodporují příkazy DML nebo DDL."
Dokumentace klíče
S konzolí GCP není situace o nic lepší – můžete odesílat pouze SELECT dotazy. Naštěstí existuje ovladač JDBC s podporou DML a DDL od komunity včetně transakcí . I když je tento ovladač mimořádně užitečný, absence vlastního ovladače JDBC od Googlu je překvapivá. Naštěstí Google nabízí poměrně širokou podporu klientských knihoven (založeno na gRPC): C#, Go, Java, node.js, PHP, Python a Ruby.
Téměř povinné použití vlastních API Cloud Spanner (kvůli nedostatku DDL a DML v JDBC) má za následek určitá omezení pro související oblasti kódu, jako je sdružování připojení nebo rámce pro vazby databáze (jako Spring MVC). Obecně platí, že při používání JDBC si můžete vybrat svůj oblíbený fond připojení (např. HikariCP, DBCP, C3PO atd.), který je otestován a funguje dobře. V případě vlastních Spanner API se musíme spolehnout na frameworky/binding/session pools, které jsme sami vytvořili.
Design orientovaný na primární klíč (PC) umožňuje Cloud Spanner být velmi rychlý při přístupu k datům přes PC, ale také přináší některé problémy s dotazy.
- Nelze aktualizovat hodnotu primárního klíče; Nejprve musíte smazat původní položku PC a znovu ji vložit s novou hodnotou. (Je to podobné jako u jiných databázových/úložišť orientovaných na PC.)
- Jakékoli příkazy UPDATE a DELETE musí specifikovat PC v WHERE, proto nemohou být prázdné příkazy DELETE all - vždy musí existovat poddotaz, například: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Chybí možnost automatického zvýšení nebo něco podobného, co nastavuje sekvenci pro pole PC. Aby to fungovalo, musí být na straně aplikace vytvořena odpovídající hodnota.
Sekundární indexy?
Google Cloud Spanner má vestavěnou podporu pro sekundární indexy. To je velmi příjemná funkce, která u jiných technologií není vždy přítomna. Apache Kudu v současné době vůbec nepodporuje sekundární indexy a Apache HBase nepodporuje indexy přímo, ale může je přidat přes Apache Phoenix.
Indexy v Kudu a HBase lze modelovat jako samostatnou tabulku s různým složením primárních klíčů, ale atomicita operací prováděných na nadřazené tabulce a souvisejících indexových tabulkách musí být prováděna na aplikační úrovni a její správná implementace není triviální.
Jak bylo zmíněno v recenzi Cloud Spanner, jeho indexy se mohou lišit od indexů MySQL. Proto je třeba věnovat zvláštní pozornost vytváření dotazů a profilování, aby bylo zajištěno použití správného indexu tam, kde je to potřeba.
Reprezentace?
Velmi oblíbeným a užitečným objektem v databázi jsou pohledy. Mohou být užitečné pro velké množství případů použití; moje dvě oblíbené jsou vrstva logické abstrakce a vrstva zabezpečení. Cloud Spanner bohužel nepodporuje zobrazení. To nás však omezuje pouze částečně, protože neexistuje žádná granularita na úrovni sloupců pro přístupová oprávnění, kde mohou být pohledy přijatelným řešením.
Část popisující kvóty a limity naleznete v dokumentaci Cloud Spanner (), jedna konkrétní může být pro některé aplikace problematická: Cloud Spanner má po vybalení maximálně 100 databází na instanci. Je zřejmé, že to může být hlavní překážka pro databázi, která je navržena tak, aby se škálovala na více než 100 databází. Naštěstí jsme po rozhovoru s naším technickým zástupcem Google zjistili, že tento limit lze prostřednictvím podpory Google zvýšit téměř na jakoukoli hodnotu.
Podpora rozvoje?
Cloud Spanner nabízí docela slušnou podporu programovacího jazyka pro práci s jeho API. Oficiálně podporované knihovny jsou v oblasti C#, Go, Java, node.js, PHP, Python a Ruby. Dokumentace je poměrně podrobná, ale stejně jako u jiných špičkových technologií je komunita ve srovnání s nejoblíbenějšími databázovými technologiemi poměrně malá, což může mít za následek více času stráveného méně běžnými případy použití nebo problémy.
Jak je to tedy s podporou místního rozvoje?
Nenašli jsme způsob, jak vytvořit místní instanci Cloud Spanner. Nejblíže jsme dostali obrázek Docker který je v principu podobný, ale v praxi velmi odlišný. Například CockroachDB může používat PostgreSQL JDBC. Vzhledem k tomu, že vývojové prostředí by mělo být co nejblíže produkčnímu prostředí, Cloud Spanner není ideální, protože se musíte spolehnout na plnou instanci Spanner. Chcete-li ušetřit náklady, můžete vybrat jednu instanci regionu.
Administrativní podpora?
Vytvoření instance Cloud Spanner je velmi jednoduché. Stačí si vybrat mezi vytvořením instance s více oblastmi nebo s jednou oblastí, zadat oblast(y) a počet uzlů. Za méně než minutu bude instance spuštěna.
Několik základních metrik je přímo dostupných na stránce Spanner v Google Console. Podrobnější pohledy jsou k dispozici prostřednictvím Stackdriveru, kde můžete také nastavit prahové hodnoty metrik a zásady upozornění.
Přístup ke zdrojům?
MySQL nabízí rozsáhlé a velmi podrobné nastavení uživatelských oprávnění/rolí. Můžete snadno přizpůsobit přístup ke konkrétní tabulce nebo dokonce jen k podmnožině jejích sloupců. Cloud Spanner využívá nástroj Google Identity & Access Management (IAM), který umožňuje nastavit zásady a oprávnění pouze na velmi vysoké úrovni. Nejpodrobnější možností je oprávnění na úrovni databáze, které se nehodí do většiny produkčních případů. Toto omezení vás nutí přidat další bezpečnostní opatření do vašeho kódu, infrastruktury nebo obojího, abyste zabránili neoprávněnému použití zdrojů Spanner.
zálohy?
Jednoduše řečeno, v Cloud Spanner nejsou žádné zálohy. Vysoké požadavky Google na SLA sice mohou zajistit, že nepřijdete o žádná data v důsledku selhání hardwaru nebo databáze, lidské chyby, defektů aplikací atd. Všichni známe pravidlo: vysoká dostupnost nenahrazuje strategii chytrého zálohování. V současné době je jediným způsobem zálohování dat programově je streamovat z databáze do prostředí odděleného úložiště.
Výkon dotazu?
K načítání dat a testování dotazů jsme použili Yahoo!. Benchmark poskytování cloudu. Níže uvedená tabulka ukazuje pracovní zátěž B YCSB s poměrem 95 % čtení k 5 % zápisu.
* Test zátěže byl spuštěn na n1-standard-32 Compute Engine (CE) (32 vCPU, 120 GB paměti) a testovací instance nikdy nebyla úzkým hrdlem testů.
** Maximální počet vláken v jedné instanci YCSB je 400. Celkem muselo být spuštěno šest paralelních instancí testů YCSB, aby bylo získáno celkem 2400 vláken.
Při pohledu na výsledky benchmarku, zejména na kombinaci zátěže CPU a TPS, jasně vidíme, že Cloud Spanner se škáluje docela dobře. Velké zatížení vytvořené velkým počtem vláken je kompenzováno velkým počtem uzlů v clusteru Cloud Spanner. Ačkoli latence vypadá poměrně vysoko, zejména při běhu na 2400 vláknech, může být nutné znovu otestovat se 6 menšími instancemi výpočetního jádra, abyste získali přesnější čísla. Každá instance spustí jeden test YCSB namísto jedné velké instance CE se 6 paralelními testy. To usnadní rozlišení mezi zpožděními požadavků Cloud Spanner a zpožděními přidanými síťovým připojením mezi Cloud Spanner a instancí CE, na které se test provádí.
Jak Cloud Spanner funguje jako OLAP?
Dělení oddílů?
Rozdělení dat do fyzicky a/nebo logicky nezávislých segmentů, nazývaných oddíly, je velmi populární koncept, který se nachází ve většině OLAP enginů. Oddíly mohou výrazně zlepšit výkon dotazů a udržovatelnost databáze. Další vrtání do dělení by bylo na samostatný článek (články), takže zmiňme jen důležitost schématu rozdělování a dělení na dílčí oddíly. Schopnost rozdělit data na oddíly a ještě dále na pododdíly je klíčem k výkonu analytických dotazů.
Cloud Spanner nepodporuje oddíly jako takové. Data vnitřně odděluje na tzv rozdělit-s na základě rozsahů primárních klíčů. Rozdělení se provádí automaticky, aby se vyrovnalo zatížení clusteru Cloud Spanner. Velmi šikovnou funkcí Cloud Spanner je rozdělení základního zatížení nadřazené tabulky (tabulky, která není proložena jinou). Spanner automaticky zjistí, zda obsahuje rozdělit data, která jsou čtena častěji než data v jiných rozdělit-ah, a může rozhodnout o dalším oddělení. Do požadavku tak může být zapojeno více uzlů, což také efektivně zvyšuje propustnost.
Načítání dat?
Metoda Cloud Spanner pro hromadná data je stejná jako pro běžné nahrávání. Chcete-li dosáhnout maximálního výkonu, musíte dodržovat několik pokynů, včetně:
- Seřaďte svá data podle primárního klíče.
- Vydělte je 10*počet uzlů jednotlivé sekce.
- Vytvořte sadu pracovních úloh, které načítají data paralelně.
Toto načtení dat využívá všechny uzly Cloud Spanner.
Použili jsme pracovní zátěž A YCSB k vygenerování 10milionové datové sady řádků.
* Test zátěže byl spuštěn na výpočetním enginu n1-standard-32 (32 vCPU, 120 GB paměti) a testovací instance nikdy nebyla úzkým hrdlem testů.
** Nastavení 1 uzlu se nedoporučuje pro jakoukoli produkční zátěž.
Jak bylo uvedeno výše, Cloud Spanner automaticky zpracovává rozdělení v závislosti na jejich zatížení, takže výsledky se po několika po sobě jdoucích iteracích testu zlepší. Zde uvedené výsledky jsou nejlepšími výsledky, kterých jsme dosáhli. Když se podíváme na výše uvedená čísla, můžeme vidět, jak se Cloud Spanner mění (dobře), jak se zvyšuje počet uzlů v clusteru. Čísla, která vynikají, jsou extrémně nízká průměrná latence, která kontrastuje s výsledky ze smíšené pracovní zátěže (95 % čtení a 5 % zápis), jak je popsáno v části výše.
Škálování?
Zvyšování a snižování počtu uzlů Cloud Spanner je úkol jedním kliknutím. Pokud chcete data načítat rychle, můžete zvážit zvýšení instance na maximum (v našem případě to bylo 25 uzlů v regionu US-EAST) a poté snížit počet uzlů vhodných pro vaše běžné zatížení po všech datech. v databázi s ohledem na limit 2 TB/uzel.
Tento limit nám byl připomenut i u mnohem menší databáze. Po několika testech zátěže měla naše databáze velikost asi 155 GB a při zmenšení na instanci 1 uzlu jsme dostali následující chybu:
Dokázali jsme zmenšit z 25 na 2 instance, ale uvízli jsme na dvou uzlech.
Zvyšování a snižování počtu uzlů v clusteru Cloud Spanner lze automatizovat pomocí REST API. To může být užitečné zejména pro snížení zvýšené zátěže systému během rušných hodin.
Výkon dotazů OLAP?
Původně jsme plánovali věnovat našemu hodnocení Spanneru v této části značný čas. Po několika SELECT COUNTS jsme si okamžitě uvědomili, že test bude krátký a že Spanner NEBUDE vhodný engine pro OLAP. Bez ohledu na počet uzlů v clusteru trvala jednoduchá volba počtu řádků v tabulce řádků 10 milionů 55 až 60 sekund. Také jakýkoli dotaz, který vyžadoval více paměti k uložení mezivýsledků, selhal s chybou OOM.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Některá čísla pro dotazy TPC-H lze nalézt v článku Todda Lipcona , snímky 42 a 43. Tato čísla jsou v souladu s našimi vlastními výsledky (bohužel).
4. Naše zjištění
Vzhledem k současnému stavu funkcí Cloud Spanner je těžké jej považovat za jednoduchou náhradu za stávající řešení OLTP, zvláště když je vaše potřeby přerostou. Značné množství času by muselo strávit budováním řešení nedostatků Cloud Spanner.
Když jsme začali vyhodnocovat Cloud Spanner, očekávali jsme, že jeho funkce pro správu budou srovnatelné s jinými řešeními Google SQL nebo jim alespoň nebudou daleko. Překvapil nás ale naprostý nedostatek záloh a velmi omezená kontrola přístupu ke zdrojům. Nemluvě o žádných pohledech, lokálním vývojovém prostředí, nepodporovaných sekvencích, JDBC bez podpory DML a DDL a tak dále.
Kam se tedy obrátit pro někoho, kdo potřebuje škálovat transakční databázi? Zdá se, že na trhu zatím neexistuje jediné řešení, které by vyhovovalo všem případům použití. Existuje mnoho uzavřených a otevřených řešení (některá z nich jsou zmíněna v tomto článku), každé má své silné a slabé stránky, ale žádné z nich nenabízí SaaS s 99,999% SLA a vysokou mírou konzistence. Pokud je vaším primárním cílem vysoká SLA a nechcete budovat vlastní řešení pro více cloudů, Cloud Spanner může být řešením, které hledáte. Ale měli byste si být vědomi všech jeho omezení.
Abychom byli spravedliví, Cloud Spanner byl pro veřejnost vydán teprve na jaře roku 2017, takže je rozumné očekávat, že některé z jeho současných nedostatků nakonec zmizí (doufejme), a když se tak stane, může to změnit hru. Cloud Spanner totiž pro Google není jen vedlejším projektem. Google jej používá jako základ pro další produkty Google. A když Google nedávno nahradil Megastore v Google Cloud Storage Cloud Spanner, umožnil Google Cloud Storage stát se vysoce konzistentní pro seznamy objektů v globálním měřítku (což stále neplatí pro ).
Takže stále je naděje... doufáme.
To je vše. Stejně jako autor článku i my nadále doufáme, ale co si o tom myslíte vy? Pište do komentářů
Zveme všechny k návštěvě našeho ve kterém vám podrobně povíme o kurzu od společnosti OTUS.
Zdroj: www.habr.com