Až donedávna jste si při nákupu databáze museli vybrat: Škálovatelnost nebo konzistence? Databáze SQL, jako je MySQL, zaručují silnou konzistenci, ale nemají horizontální měřítko. (Ruční dělení pro škálovatelnost není nikomu představou legrace.) Databáze NoSQL, jako je MongoDB, se škálovávají krásně, ale nabízejí pouze případnou konzistenci. („Počkejte dostatečně dlouho a můžete si přečíst správnou odpověď“ - což není žádný způsob, jak provádět finanční transakce.)
Google Cloud Spanner, plně spravovaná relační databázová služba spuštěná na Google Compute Engine (GCE) vydaná v únoru 2017, má škálovatelnost databází NoSQL při zachování kompatibility s SQL, relačních schémat, transakcí ACID a silné externí konzistence. Spanner je horizontálně distribuovaná a replikovaná relační databáze, která využívá algoritmus Paxos k dosažení shody mezi svými uzly.
Jednou z alternativ k programu Spanner a předmětem této recenze je CockroachDB, otevřená, horizontálně škálovatelná distribuovaná databáze SQL vyvinutá ex-zaměstnanci společnosti Google, kteří byli seznámeni se společností Spanner. CockroachDB si od společnosti Google Spanner půjčuje design svého systému pro ukládání dat a k dosažení konsensu mezi svými uzly používá algoritmus Raft.
Stejně jako Cloud Spanner je CockroachDB distribuovaná databáze SQL postavená na transakčním a konzistentním úložišti klíč-hodnota, v případě CockroachDB na RocksDB. Primárním designovým cílem CockroachDB je podpora transakcí ACID, horizontální škálovatelnost a (především) schopnost přežití, odtud název.
CockroachDB je navržen tak, aby přežil selhání disku, stroje, stojanu a dokonce i datového centra s minimálním narušením latence a bez ručního zásahu. Samozřejmě, abyste toho dosáhli, musíte spustit shluk mnoha případů symetrických uzlů CockroachDB pomocí více disků, strojů, stojanů a datových center.
Na rozdíl od Cloud Spanner, který používá API TrueTime dostupné pro synchronizaci času v datových centrech Google, CockroachDB nemůže počítat s přítomností atomových hodin a satelitních hodin GPS pro přesnou synchronizaci času mezi uzly a datovými centry. To má řadu důsledků. Google TrueTime nejprve poskytuje horní mez pro časové posuny mezi uzly v klastru sedmi milisekund. To je dost malé na to, aby uzel Spanner počkal po zápisu sedm milisekund, než nahlásí, že se transakce zavázala, aby byla zaručena vnější konzistence.
Bez TrueTime nebo podobného zařízení musí CockroachDB klesnout zpět na NTP, což dává horní hranice synchronizace hodin mezi 100 milisekundami a 250 milisekundami. Vzhledem k tomu, že je větší časové okno, CockroachDB na zápisy nečeká. Místo toho někdy čeká před načtením, v zásadě restartuje transakci, pokud přečte hodnotu s časovým razítkem větším než začátek transakce, opět kvůli zajištění konzistence.
Když mají všechny uzly v klastru CockroachDB malé horní hranice pro posuny hodin, které můžete získat z GPS nebo atomových hodin, což je něco, co se právě stává dostupným na velkých veřejných cloudech, může mít smysl je spustit pomocí - linearizovatelné vlajka. Díky tomu čekají na maximální posun času před návratem úspěšného odevzdání, stejně jako Spanner.
Jak funguje CockroachDB
Každý uzel CockroachDB se skládá z pěti vrstev:
- SQL, který převádí dotazy klienta SQL na operace klíč – hodnota
- Transakce, která umožňuje atomové změny u více položek klíč – hodnota
- Distribuce, která představuje replikované rozsahy klíč – hodnota jako jednu entitu
- Replikace, která konzistentně a synchronně replikuje rozsahy klíč-hodnota napříč mnoha uzly a umožňuje konzistentní čtení prostřednictvím zapůjčení
- Úložiště, které zapisuje a čte data klíč – hodnota na disk
Vrstva SQL analyzuje dotazy na soubor Yacc a promění je v abstraktní syntaxový strom. Z abstraktního stromu syntaxe generuje CockroachDB strom uzlů plánu, které obsahují kód klíč – hodnota. Uzly plánu se poté provedou a komunikují s transakční vrstvou.
Transakční vrstva implementuje sémantiku transakcí ACID s dvoufázovými revizemi v celém klastru, včetně transakcí mezi rozsahy a křížovými tabulkami, přičemž jednotlivé příkazy považuje za transakce (také se nazývá režim automatického potvrzení). Dvoufázového potvrzení se dosáhne zaúčtováním transakčních záznamů a záměrů zápisu, provedením operací čtení a zpracováním všech záměrů zápisu zjištěných jako konflikty transakcí.
Distribuční vrstva přijímá požadavky z transakční vrstvy ve stejném uzlu. Poté identifikuje, které uzly by měl požadavek přijmout, a odešle požadavek do replikační vrstvy správného uzlu.
Vrstva replikace kopíruje data mezi uzly a zajišťuje konzistenci mezi těmito kopiemi implementací Raftova konsensuálního algoritmu. Faktor replikace můžete ovládat na úrovni klastru, databáze a tabulky pomocí zón replikace. Algoritmus konsensu se používá pouze pro zápisy a vyžaduje, aby kvorum replik souhlasilo s jakýmikoli změnami rozsahu před provedením těchto změn.
Úložná vrstva ukládá data jako páry klíč – hodnota na disk pomocí RocksDB. CockroachDB se při zpracování souběžných požadavků a zajištění konzistence silně spoléhá na řízení více verzí souběžnosti (MVCC). Velká část této práce se provádí pomocí časových značek hybridních logických hodin (HLC).
Stejně jako Spanner, CockroachDB podporuje dotazy na cestování v čase (povoleno MVCC). Mohou se vrátit zpět až k poslednímu uvolnění paměti databáze, které se provádí ve výchozím nastavení každý den.
Instalace a použití CockroachDB
CockroachDB běží na operačních systémech Mac, Linux a Windows, alespoň pro vývoj a testování. Databáze produkčních švábů obvykle běží na virtuálních počítačích se systémem Linux nebo na řízených kontejnerech, často hostovaných na veřejných cloudech ve více datových centrech. Windows binární CockroachDB je stále ve fázi beta a nedoporučuje se pro produkci a Apple již nevyrábí serverový hardware.
Laboratoře švábů Jak vidíte na snímku obrazovky výše, existují čtyři možnosti instalace CockroachDB na počítači Mac. Jako nejjednodušší ze všech čtyř jsem si vybral Homebrew.
Mimochodem, Cockroach Labs zveřejní varování na webu, které říká, že spuštění stavové aplikace, jako je CockroachDB v Dockeru, je složité, nedoporučuje se pro nasazení v produkci a místo toho používá k orchestraci nástroj jako Kubernetes nebo Docker Swarm. V další části se budu zabývat možnostmi orchestrace kontejnerů.
Instalace na počítači Mac je stejně snadná jako vařit instalovat šváb jak je uvedeno výše. V mém případě automatická aktualizace Homebrew trvala mnohem déle (dostatek času na vaření čaje) než skutečná instalace CockroachDB, která trvala jen několik sekund.
Jakmile máte nainstalován CockroachDB, je docela snadné roztočit místní cluster, i když je tu další krok generování bezpečnostních certifikátů pomocí šváb cert příkaz, pokud chcete, aby byl cluster zabezpečený. Jakmile máte spuštěný cluster (pomocí šváb start jednou pro každý uzel, s následujícími uzly nastavenými na připojení k clusteru prvního uzlu), můžete se připojit na stránku webové správy na libovolném uzlu pomocí prohlížeče a použít vložený šváb sql klient odesílat dotazy SQL do libovolného uzlu. Většina prohlížečů si bude stěžovat na weby s certifikáty generovanými CockroachDB, ale měli byste být schopni proklikat toto hrozné varování a pokračovat na web.
Doporučené nastavení produkce CockroachDB se liší od výchozích hodnot, které byly nastaveny pro vývojové a testovací instance. Pokud chcete, můžete se vyvíjet na klastru s jedním uzlem. Pro produkci byste měli mít minimálně tři uzly, spustit každý uzel na samostatném počítači, virtuálním počítači nebo kontejneru a dát každé instanci další mezipaměť a paměť SQL. Výchozí nastavení je 128 MB pro mezipaměť a paměť SQL; doporučené výrobní nastavení je dát každých 25 procent paměti RAM:
start švábů - cache = 25% --max-sql-paměť = 25%
Čím více uzlů spustíte, tím lepší bude odolnost. Čím větší a rychlejší uzly, tím lepší výkon. Pokud chcete mít uzly s výkonem zhruba srovnatelným s uzly Google Cloud Spanner, které poskytují 2 000 zápisů za sekundu a 10 000 čtení za sekundu, pak byste chtěli něco jako instance GCE n1-highcpu-8, které mají osm CPU a 8 GB RAM , s místními disky SSD (spíše než s rotujícími disky).
Čím více distribuujete své uzly do různých datových center, tím lépe můžete zajistit imunitu vůči poruchám na úrovni datového centra. Existuje však cena: Zpáteční zpoždění mezi datovými centry bude mít přímý vliv na výkon vaší databáze, přičemž mezikontinentální klastry fungují znatelně horší než klastry, ve kterých jsou všechny uzly geograficky blízko sebe.
Cockroach Labs supplies Podrobné pokyny pro nasazení na AWS, Digital Ocean, GCE a Azure. Doporučené konfigurace používají nástroje pro vyrovnávání zatížení, buď nativní spravované služby pro vyrovnávání zatížení, nebo nástroje pro vyrovnávání zatížení s otevřeným zdrojem, jako je HAProxy.
Orchestrace může snížit provozní režii clusteru CockroachDB téměř na nic. Cockroach Labs dokumentuje, jak to udělat pro produkci s Kubernetes a Docker Swarm. Úložiště CockroachDB-CloudFormation na GitHubu ukazuje, jak používat AWS CloudFormation a Kubernetes v jediné zóně dostupnosti pro vývoj a testování. Přizpůsobení tohoto pro produkci by zahrnovalo úpravu šablony CloudFormation pro použití více zón dostupnosti.
Programování a testování CockroachDB
CockroachDB podporuje drátový protokol PostgreSQL, takže svůj kód píšete, jako byste programovali proti Postgresu nebo alespoň podmnožině Postgresu. Tato stránka obsahuje seznam testovaných ovladačů pro různé vazby programovacích jazyků, včetně nejpopulárnějších jazyků na straně serveru. Tato stránka uvádí ukázky v 10 programovacích jazycích a pěti ORM. Při čtení kódu jsem se nestretl s žádným velkým překvapením, i když jsem v seznamech v dokumentaci zaznamenal několik pravděpodobných drobných chyb. Můžete také spustit svůj SQL pomocí interaktivního klienta zabudovaného do šváb spustitelný.
I když existuje repo věnované generátorům zátěže CockroachDB a další pro testování výkonu, není srovnávání klastrů CockroachDB snadné, zvláště pokud se pokoušíte smysluplně porovnat CockroachDB s jinými databázemi. Jedním problémem je, že síť mezi uzly může být krokem omezujícím rychlost v klastrech CockroachDB.
Další skutečnost, kterou je třeba vzít v úvahu, je, že většina konvenčních databází SQL se ve výchozím nastavení nespouští v izolačním režimu SERIALIZABLE; místo toho používají méně přísný režim s lepším výkonem. CockroachDB ve výchozím nastavení používá režim serializovatelné izolace. Bylo by také trochu nespravedlivé testovat výkon připojení CockroachDB SQL, který je stále nedokončenou pomocí sady TPC-C.
A přesto můžete snadno vidět provozní sílu CockroachDB. Například je třeba zastavit a restartovat mnoho databází, aby se zvětšily. Přidání uzlů při načítání v CockroachDB je hračka, zvláště pokud používáte nástroj pro orchestraci. Například výše uvedený snímek obrazovky ukazuje příkazy pro změnu a zobrazení uzlů v klastru Kubernetes a snímek obrazovky níže zobrazuje monitorovaný klastr při přidávání uzlů. Nástroj pro generování zátěže běžel nepřetržitě během celého procesu.
Ještě působivější ukázka ukazuje automatickou migraci mezi cloudy v klastru CockroachDB. Aby to bylo spravedlivé, to opravdu vyžaduje video; video je hostováno v odkazovaném blogovém příspěvku.
CockroachDB SQL
SQL v CockroachDB je víceméně standardní, na rozdíl od SQL v Cloud Spanner, který používá nestandardní syntaxi pro manipulaci s daty. CockroachDB SQL stále chybí mnoho funkcí.
Například V1.1 postrádá podporu JSON, která je plánována pro V1.2. Také mu chybí analýza XML, která není v plánu. Postrádá kaskády na úrovni řádků, plánované pro V1.2, a postrádá kurzory a spouštěče, které nejsou v plánu. Geoprostorové indexy jsou „potenciálními“ dodatky, které mohou v budoucnu vést k plánu.
Nejpozoruhodnější je, že počáteční implementace SQL spojení CockroachDB v roce 2016 byla záměrně zjednodušující a vykazovala kvadratické škálování, což je zbytečné pro dotazování velkých datových sad. Verze ve verzi 1.0, kterou provedl kooperativní student, implementovala hašovací spojení, díky čemuž mnoho operací spojování bylo lineárně škálováno; to dostalo CockroachDB na úroveň SQLite. Někdy v roce 2018, vzhledem k nedávnému kola financování, by měl mít CockroachDB výkon připojení, který se více podobá spojením PostgreSQL, a také zpracování spojení SQL distribuované po klastru.
