Ahoj všichni! Jmenuji se Golov Nikolay. Dříve jsem pracoval ve společnosti Avito a šest let jsem spravoval Data Platform, to znamená, že jsem pracoval na všech databázích: analytické (Vertica, ClickHouse), streamingové a OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Za tuto dobu jsem řešil velké množství databází – velmi odlišných a neobvyklých a s nestandardními případy jejich použití.
V současné době pracuji ve společnosti ManyChat. V podstatě se jedná o startup – nový, ambiciózní a rychle rostoucí. A když jsem do společnosti poprvé vstoupil, vyvstala klasická otázka: „Co by si měl nyní mladý startup vzít z trhu DBMS a databází?“
V tomto článku, na základě mé zprávy na , na tuto otázku odpovím. Video verze zprávy je k dispozici na adrese .
Běžně známé databáze 2020
Je rok 2020, rozhlédl jsem se a viděl jsem tři typy databází.
První typ je klasické OLTP databáze: PostgreSQL, SQL Server, Oracle, MySQL. Byly napsány již dávno, ale stále jsou aktuální, protože jsou vývojářské komunitě tak známé.
Druhý typ je báze od "nuly". Pokusili se odklonit od klasických vzorů tím, že opustili SQL, tradiční struktury a ACID, přidali vestavěné sharding a další atraktivní funkce. Jde například o Cassandru, MongoDB, Redis nebo Tarantool. Všechna tato řešení chtěla nabídnout trhu něco zásadně nového a obsadila své místo, protože se ukázalo, že jsou pro určité úkoly mimořádně vhodná. Tyto databáze budu označovat zastřešujícím pojmem NOSQL.
„Nuly“ skončily, zvykli jsme si na databáze NOSQL a svět z mého pohledu udělal další krok – spravované databáze. Tyto databáze mají stejné jádro jako klasické OLTP databáze nebo nové NoSQL. Nepotřebují však DBA a DevOps a běží na spravovaném hardwaru v cloudu. Pro vývojáře je to „jen základ“, který někde funguje, ale nikoho nezajímá, jak je na serveru nainstalován, kdo server konfiguroval a kdo jej aktualizuje.
Příklady takových databází:
- AWS RDS je spravovaný obal pro PostgreSQL/MySQL.
- DynamoDB je analogem AWS databáze založené na dokumentech, podobně jako Redis a MongoDB.
- Amazon Redshift je spravovaná analytická databáze.
Jde v podstatě o staré databáze, ale vychované ve spravovaném prostředí, bez nutnosti práce s hardwarem.
Poznámka. Příklady jsou převzaty pro prostředí AWS, ale jejich analogy existují také v Microsoft Azure, Google Cloud nebo Yandex.Cloud.
Co je na tom nového? V roce 2020 nic z toho.
Koncept bez serveru
Skutečnou novinkou na trhu v roce 2020 jsou řešení bez serveru nebo bez serveru.
Pokusím se vysvětlit, co to znamená, na příkladu běžné služby nebo backendové aplikace.
Pro nasazení běžné backendové aplikace si koupíme nebo pronajmeme server, zkopírujeme na něj kód, publikujeme koncový bod venku a pravidelně platíme nájem, elektřinu a služby datového centra. Toto je standardní schéma.
Existuje nějaký jiný způsob? Se službami bez serveru můžete.
Na co se tento přístup zaměřuje: neexistuje server, dokonce neexistuje ani pronájem virtuální instance v cloudu. Chcete-li službu nasadit, zkopírujte kód (funkce) do úložiště a publikujte jej do koncového bodu. Pak jednoduše platíme za každé volání této funkce, přičemž zcela ignorujeme hardware, kde se provádí.
Pokusím se tento přístup ilustrovat pomocí obrázků.
Klasické nasazení. Máme službu s určitým zatížením. Vytváříme dvě instance: fyzické servery nebo instance v AWS. Externí požadavky jsou odesílány do těchto instancí a tam zpracovávány.
Jak můžete vidět na obrázku, servery nejsou nakládány stejně. Jeden je 100% využit, jsou dva požadavky a jeden je pouze z 50% – částečně nečinný. Pokud nepřijdou tři požadavky, ale 30, pak celý systém nebude schopen zvládnout zátěž a začne se zpomalovat.
Nasazení bez serveru. V prostředí bez serveru taková služba nemá instance ani servery. Existuje určitý fond vyhřívaných zdrojů - malé připravené kontejnery Docker s nasazeným funkčním kódem. Systém přijímá externí požadavky a pro každý z nich bezserverový framework vytvoří malý kontejner s kódem: zpracuje tento konkrétní požadavek a kontejner zabije.
Jeden požadavek - jeden kontejner zvednutý, 1000 požadavků - 1000 kontejnerů. A nasazení na hardwarové servery je již dílem poskytovatele cloudu. Je zcela skryta bezserverovým frameworkem. V tomto konceptu platíme za každý hovor. Například přišel jeden hovor za den – zaplatili jsme za jeden hovor, přišel milion za minutu – zaplatili jsme milion. Nebo ve vteřině se to také stane.
Koncept publikování bezserverové funkce je vhodný pro bezstavovou službu. A pokud potřebujete (státní) stavovou službu, pak ke službě přidáme databázi. V tomto případě, pokud jde o práci se stavem, každá stavová funkce jednoduše zapisuje a čte z databáze. Navíc z databáze kteréhokoli ze tří typů popsaných na začátku článku.
Jaké je společné omezení všech těchto databází? Jedná se o náklady na neustále používaný cloud nebo hardwarový server (nebo několik serverů). Nezáleží na tom, zda používáme klasickou nebo spravovanou databázi, ať máme Devops a admina nebo ne, stále platíme za hardware, elektřinu a pronájem datového centra 24/7. Pokud máme klasickou základnu, platíme za master a slave. Pokud se jedná o vysoce zatíženou shardovanou databázi, platíme za 10, 20 nebo 30 serverů a platíme neustále.
Přítomnost trvale rezervovaných serverů ve struktuře nákladů byla dříve vnímána jako nutné zlo. Konvenční databáze mají i další úskalí, jako jsou limity na počet připojení, omezení škálování, geograficky distribuovaný konsensus – ty se v určitých databázích nějak řešit dají, ale ne všechny najednou a ne ideálně.
Bezserverová databáze - teorie
Otázka roku 2020: Je možné vytvořit databázi bez serveru? Každý slyšel o backendu bez serveru... zkusíme udělat databázi bez serveru?
To zní divně, protože databáze je stavová služba, která není příliš vhodná pro infrastrukturu bez serveru. Zároveň je stav databáze velmi velký: gigabajty, terabajty a v analytických databázích dokonce petabajty. Není tak snadné jej zvednout v lehkých kontejnerech Docker.
Na druhou stranu téměř všechny moderní databáze obsahují obrovské množství logiky a komponent: transakce, koordinaci integrity, procedury, relační závislosti a spoustu logiky. Pro poměrně hodně databázové logiky stačí malý stav. Gigabajty a terabajty jsou přímo využívány pouze malou částí databázové logiky zapojené do přímého provádění dotazů.
Myšlenka tedy zní: pokud část logiky umožňuje bezstavové provádění, proč nerozdělit základnu na stavovou a bezstavovou část.
Bez serveru pro řešení OLAP
Podívejme se na praktických příkladech, jak by mohlo vypadat rozřezání databáze na části Stateful a Stateless.
Máme například analytickou databázi: externí data (červený válec vlevo), proces ETL, který načítá data do databáze, a analytik, který odesílá SQL dotazy do databáze. Jedná se o klasické schéma provozu datového skladu.
V tomto schématu se ETL podmíněně provádí jednou. Pak je potřeba neustále platit za servery, na kterých databáze běží daty naplněnými ETL, aby bylo na co posílat dotazy.
Podívejme se na alternativní přístup implementovaný v AWS Athena Serverless. Neexistuje žádný trvale vyhrazený hardware, na kterém jsou uložena stažená data. Místo toho:
- Uživatel odešle dotaz SQL společnosti Athena. Optimalizátor Athena analyzuje dotaz SQL a hledá v úložišti metadat (Metadata) konkrétní data potřebná k provedení dotazu.
- Optimalizátor na základě nasbíraných dat stáhne potřebná data z externích zdrojů do dočasného úložiště (dočasné databáze).
- SQL dotaz od uživatele se provede v dočasném úložišti a výsledek se vrátí uživateli.
- Dočasné úložiště je vymazáno a zdroje jsou uvolněny.
V této architektuře platíme pouze za proces vyřízení požadavku. Žádné požadavky - žádné náklady.
Toto je pracovní přístup a je implementován nejen v Athena Serverless, ale také v Redshift Spectrum (v AWS).
Příklad Athena ukazuje, že databáze Serverless pracuje na skutečných dotazech s desítkami a stovkami terabajtů dat. Stovky terabajtů budou vyžadovat stovky serverů, ale my za ně nemusíme platit – platíme za požadavky. Rychlost každého požadavku je (velmi) nízká ve srovnání se specializovanými analytickými databázemi, jako je Vertica, ale neplatíme za prostoje.
Taková databáze je použitelná pro vzácné analytické ad-hoc dotazy. Například když se spontánně rozhodneme otestovat hypotézu na nějakém gigantickém množství dat. Athena je pro tyto případy ideální. Pro běžné požadavky je takový systém drahý. V takovém případě uložte data do mezipaměti v nějakém specializovaném řešení.
Bez serveru pro řešení OLTP
Předchozí příklad se zabýval OLAP (analytickými) úlohami. Nyní se podíváme na úlohy OLTP.
Představme si škálovatelné PostgreSQL nebo MySQL. Vytvořme běžnou spravovanou instanci PostgreSQL nebo MySQL s minimálními prostředky. Když instance obdrží větší zátěž, připojíme další repliky, na které rozložíme část zátěže čtení. Pokud nejsou žádné požadavky nebo zatížení, repliky vypneme. První instance je hlavní a zbytek jsou repliky.
Tato myšlenka je implementována v databázi s názvem Aurora Serverless AWS. Princip je jednoduchý: požadavky z externích aplikací jsou přijímány proxy flotilou. Když vidí nárůst zátěže, přiděluje výpočetní zdroje z předem zahřátých minimálních instancí - připojení je vytvořeno co nejrychleji. Zakázání instancí probíhá stejným způsobem.
V rámci Aurory existuje koncept Aurora Capacity Unit, ACU. Toto je (podmíněně) instance (server). Každý konkrétní ACU může být master nebo slave. Každá jednotka kapacity má vlastní RAM, procesor a minimální disk. V souladu s tím je jeden master, zbytek jsou repliky pouze pro čtení.
Počet těchto jednotek Aurora Capacity Unit běžících je konfigurovatelný parametr. Minimální množství může být jedna nebo nula (v tomto případě databáze nefunguje, pokud nejsou žádné požadavky).
Když základna obdrží požadavky, flotila proxy zvýší počet jednotek Aurora CapacityUnits, čímž zvýší výkon systému. Schopnost zvyšovat a snižovat zdroje umožňuje systému „žonglovat“ se zdroji: automaticky zobrazovat jednotlivé ACU (nahrazovat je novými) a zavádět všechny aktuální aktualizace odebraných zdrojů.
Základna Aurora Serverless může škálovat zatížení čtení. Dokumentace to ale přímo neříká. Může se zdát, že dokážou zvednout multi-mastera. Neexistuje žádná magie.
Tato databáze se dobře hodí k tomu, aby se zabránilo utrácení obrovského množství peněz za systémy s nepředvídatelným přístupem. Například při vytváření stránek MVP nebo marketingových vizitek většinou nepočítáme se stabilní zátěží. Pokud tedy není přístup, neplatíme za instance. Když dojde k neočekávané zátěži, například po konferenci nebo reklamní kampani, stránky navštíví davy lidí a zátěž se dramaticky zvýší, Aurora Serverless tuto zátěž automaticky převezme a rychle připojí chybějící zdroje (ACU). Pak konference projde, všichni zapomenou na prototyp, servery (ACU) zhasnou a náklady klesnou na nulu – pohodlné.
Toto řešení není vhodné pro stabilní vysoké zatížení, protože nezvětšuje zatížení zápisu. Všechna tato připojení a odpojení zdrojů se odehrávají v takzvaném „měřicím bodě“ – v okamžiku, kdy databáze není podporována transakcí nebo dočasnými tabulkami. Například do týdne se bod škály nemusí stát a základna pracuje na stejných zdrojích a jednoduše se nemůže rozšiřovat ani smršťovat.
Neexistuje žádná magie - je to běžný PostgreSQL. Ale proces přidávání strojů a jejich odpojování je částečně automatizován.
Designově bez serveru
Aurora Serverless je stará databáze přepsaná pro cloud, aby využila některé z výhod Serverless. A teď vám řeknu o základně, která byla původně napsána pro cloud, pro přístup bez serveru – Serverless-by-design. Byl okamžitě vyvinut bez předpokladu, že bude běžet na fyzických serverech.
Tato báze se nazývá Snowflake. Má tři klíčové bloky.
První je blok metadat. Jedná se o rychlou službu v paměti, která řeší problémy se zabezpečením, metadaty, transakcemi a optimalizací dotazů (zobrazeno na obrázku vlevo).
Druhým blokem je sada virtuálních výpočetních clusterů pro výpočty (na obrázku je sada modrých kroužků).
Třetím blokem je systém ukládání dat založený na S3. S3 je bezrozměrné úložiště objektů v AWS, něco jako bezrozměrný Dropbox pro podnikání.
Podívejme se, jak Snowflake funguje, za předpokladu studeného startu. To znamená, že existuje databáze, data se do ní načítají, neprobíhají žádné dotazy. Pokud tedy do databáze nejsou žádné požadavky, aktivovali jsme rychlou službu metadat v paměti (první blok). A máme tu úložiště S3, kde se ukládají tabulková data, rozdělená do tzv. mikrooddílů. Pro jednoduchost: pokud tabulka obsahuje transakce, pak mikrooddíly jsou dny transakcí. Každý den je samostatný mikrooddíl, samostatný soubor. A když databáze funguje v tomto režimu, platíte pouze za prostor, který zabírají data. Navíc je sazba za sedadlo velmi nízká (zejména s přihlédnutím k výrazné kompresi). Služba metadat také funguje neustále, ale k optimalizaci dotazů nepotřebujete mnoho zdrojů a službu lze považovat za shareware.
Nyní si představme, že uživatel přišel do naší databáze a odeslal SQL dotaz. SQL dotaz je okamžitě odeslán ke zpracování do služby Metadata. Podle toho tato služba po obdržení požadavku analyzuje požadavek, dostupná data, uživatelská oprávnění a pokud je vše v pořádku, sestaví plán zpracování požadavku.
Dále služba zahájí spuštění výpočetního clusteru. Výpočetní cluster je shluk serverů, které provádějí výpočty. To znamená, že se jedná o cluster, který může obsahovat 1 server, 2 servery, 4, 8, 16, 32 – tolik, kolik chcete. Vyhodíte požadavek a okamžitě začne spuštění tohoto clusteru. Opravdu to trvá vteřiny.
Poté, co se klastr spustí, začnou se mikrooddíly potřebné ke zpracování vašeho požadavku kopírovat do klastru z S3. To znamená, že si představme, že k provedení SQL dotazu potřebujete dva oddíly z jedné tabulky a jeden z druhé. V tomto případě budou do clusteru zkopírovány pouze tři nezbytné oddíly a ne všechny tabulky úplně. Proto a právě proto, že je vše umístěno v jednom datovém centru a propojeno velmi rychlými kanály, celý proces přenosu probíhá velmi rychle: v sekundách, velmi zřídka v minutách, pokud nemluvíme o nějakých obludných požadavcích . V souladu s tím jsou mikrooddíly zkopírovány do výpočetního clusteru a po dokončení je na tomto výpočetním clusteru proveden dotaz SQL. Výsledkem tohoto požadavku může být jeden řádek, více řádků nebo tabulka – ty jsou odeslány externě uživateli, aby si je mohl stáhnout, zobrazit ve svém BI nástroji nebo jinak použít.
Každý SQL dotaz dokáže nejen číst agregace z dříve načtených dat, ale také načítat/generovat nová data v databázi. To znamená, že to může být dotaz, který například vkládá nové záznamy do jiné tabulky, což vede k tomu, že se na výpočetním clusteru objeví nový oddíl, který se zase automaticky uloží do jediného úložiště S3.
Výše popsaný scénář, od příchodu uživatele po zvednutí klastru, načtení dat, provedení dotazů, získání výsledků, je placen sazbou za minuty používání zvednutého virtuálního výpočetního klastru, virtuálního skladu. Sazba se liší v závislosti na zóně AWS a velikosti clusteru, ale v průměru je to několik dolarů za hodinu. Cluster čtyř strojů je dvakrát dražší než cluster dvou strojů a cluster osmi strojů je stále dvakrát dražší. K dispozici jsou možnosti 16, 32 strojů v závislosti na složitosti požadavků. Ale platíte jen za ty minuty, kdy cluster skutečně běží, protože když nejsou žádné požadavky, tak dáte ruce pryč a po 5-10 minutách čekání (nastavitelný parametr) to samo zhasne, uvolněte zdroje a staňte se svobodnými.
Zcela realistický scénář je, když odešlete požadavek, cluster naskočí, relativně vzato, za minutu, počítá další minutu, pak pět minut do vypnutí a nakonec zaplatíte za sedm minut provozu tohoto clusteru a ne měsíce a roky.
První scénář popsal použití Snowflake v nastavení pro jednoho uživatele. Nyní si představme, že existuje mnoho uživatelů, což se blíží skutečnému scénáři.
Řekněme, že máme spoustu analytiků a zpráv Tableau, kteří neustále bombardují naši databázi velkým množstvím jednoduchých analytických SQL dotazů.
Navíc řekněme, že máme vynalézavé Data Scientists, kteří se snaží dělat s daty monstrózní věci, operují s desítkami terabajtů, analyzují miliardy a biliony řádků dat.
Pro dva typy zátěže popsané výše vám Snowflake umožňuje vytvořit několik nezávislých výpočetních clusterů různých kapacit. Navíc tyto výpočetní clustery pracují nezávisle, ale se společnými konzistentními daty.
Pro velký počet lehkých dotazů můžete vytvořit 2-3 malé clustery, každý zhruba 2 stroje. Toto chování lze implementovat mimo jiné pomocí automatického nastavení. Takže řekneš: "Sněhová vločka, zvedni malý shluk." Pokud se zatížení na něm zvýší nad určitý parametr, zvedněte podobný druhý, třetí. Když zátěž začne ustupovat, uhaste přebytek.“ Takže bez ohledu na to, kolik analytiků přijde a začne se dívat na zprávy, každý má dostatek zdrojů.
Zároveň, pokud analytici spí a nikdo se nedívá na zprávy, shluky mohou úplně ztmavnout a vy za ně přestanete platit.
Zároveň pro náročné dotazy (od Data Scientists) můžete vytvořit jeden velmi velký cluster pro 32 počítačů. Tento cluster bude také placen pouze za ty minuty a hodiny, kdy tam běží váš obří požadavek.
Výše popsaná příležitost umožňuje rozdělit nejen 2, ale i více druhů zátěže do clusterů (ETL, monitoring, materializace reportů,...).
Pojďme si shrnout Snowflake. Základ spojuje krásný nápad a proveditelnou realizaci. Na ManyChat používáme Snowflake k analýze všech dat, která máme. Nemáme tři shluky jako v příkladu, ale 5 až 9 různých velikostí. Pro některé úkoly máme konvenční 16-stroj, 2-stroj a také supermalý 1-stroj. Úspěšně rozloží zátěž a umožní nám hodně ušetřit.
Databáze úspěšně škáluje zatížení čtení a zápisu. To je obrovský rozdíl a obrovský průlom ve srovnání se stejnou „Aurorou“, která nesla pouze čtecí zátěž. Snowflake vám umožňuje škálovat vaše psaní pomocí těchto výpočetních clusterů. To znamená, jak jsem již zmínil, v ManyChat používáme několik clusterů, malé a supermalé clustery se používají hlavně pro ETL, pro načítání dat. A analytici už žijí na středních klastrech, které zatížení ETL absolutně neovlivňuje, takže pracují velmi rychle.
V souladu s tím je databáze vhodná pro úlohy OLAP. Bohužel to zatím není použitelné pro pracovní zátěže OLTP. Za prvé, tato databáze je sloupcová se všemi z toho vyplývajícími důsledky. Zadruhé samotný přístup, kdy pro každý požadavek v případě potřeby zvednete výpočetní cluster a zahltíte jej daty, bohužel zatím není dostatečně rychlý na zatížení OLTP. Čekání v sekundách na úlohy OLAP je normální, ale pro úlohy OLTP je to nepřijatelné; 100 ms by bylo lepších nebo 10 ms by bylo ještě lepší.
Celkový
Bezserverová databáze je možná rozdělením databáze na bezstavovou a stavovou část. Možná jste si všimli, že ve všech výše uvedených příkladech část Stateful relativně vzato ukládá mikrooddíly v S3 a Stateless je optimalizátor, který pracuje s metadaty a řeší problémy se zabezpečením, které lze nastolit jako nezávislé odlehčené služby Stateless.
Provádění SQL dotazů lze také vnímat jako služby v lehkém stavu, které se mohou objevit v režimu bez serveru, jako jsou výpočetní clustery Snowflake, stáhnout pouze nezbytná data, provést dotaz a „vypnout“.
Bezserverové databáze na produkční úrovni jsou již k dispozici, fungují. Tyto databáze bez serveru jsou již připraveny ke zpracování úloh OLAP. Bohužel pro úlohy OLTP se používají... s nuancemi, protože existují omezení. Na jednu stranu je to mínus. Ale na druhou stranu je to příležitost. Možná některý ze čtenářů najde způsob, jak učinit databázi OLTP zcela bez serveru, bez omezení Aurory.
Doufám, že vás to zaujalo. Budoucnost je bez serveru :)
Zdroj: www.habr.com