Teel serverivabade andmebaaside poole — kuidas ja miks

Tere kõigile! Minu nimi on Nikolai Golov. Varem töötasin Avitos ja kuus aastat juhtisin Data Platformi, teisisõnu, tegelesin kõigi andmebaasidega: analüütilised (Vertica, ClickHouse), voogandmed ja OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Selle aja jooksul olen süvenenud paljude andmebaaside, ehkki väga erinevate ja ebatavaliste, ning nende mittestandardsed kasutusjuhtumid.

Praegu töötan ManyChatis. Põhimõtteliselt on see idufirma - uus, ambitsioonikas ja kiiresti kasvav. Ja kui ma just ettevõttesse tulin, tekkis klassikaline küsimus: 'Mida peaks noor idufirma andmebaaside turult praegu valima?'.

Selles artiklis, mis põhineb minu ettekandel online-festivalil RIT++2020, vastan sellele küsimusele. Ettekanne on saadaval videoversioonina YouTube.

Tuntud andmebaasid 2020. aastast

On 2020. aasta, vaatan ringi ja näen kolme tüüpi andmebaase.

Esimene tüüp - klassikalised OLTP andmebaasid: PostgreSQL, SQL Server, Oracle, MySQL. Need on kirjutatud ammu, kuid on endiselt asjakohased, kuna on arendajate kogukonnale hästi tuttavad.

Teine tüüp - nullide ajastu andmebaasid.Need püüdsid eemalduda klassikalistest mustritest, loobudes SQL-st, traditsioonilistest struktuuridest ja ACID-ist, lisades sisseehitatud sharding'i ja muid atraktiivseid funktsioone. Näiteks on need Cassandra, MongoDB, Redis või Tarantool. Kõik need lahendused soovisid turule pakkuda midagi põhimõtteliselt uut ja leidsid oma niši, kuna osutusid teatud ülesannete täitmisel äärmiselt mugavaks. Need andmebaasid nimetan NOSQL-i teenusena.

Nullide ajastu on möödas, NOSQL andmebaasidega on harjutud ning maailm, minu arvates, on teinud järgmise sammu - haldamise alla võetud andmebaaside suunas.Nendel andmebaasidel on sama tuum nagu klassikalistel OLTP andmebaasidel või uutel NoSQL-i andmebaasidel. Kuid neil puudub vajadus DBA ja DevOps-i järele ning need töötavad hallatud riistvaral pilves. Arendajale on see 'lihtsalt andmebaas', mis kuskil töötab, ja see, kuidas see serverisse paigaldatud on, kes serverit seadistab ja kes seda uuendab, kedagi ei huvit.

Selliste andmebaaside näited on:

• AWS RDS - hallatud kiht PostgreSQL/MySQL üle.
• DynamoDB - AWS analoog dokumentide põhisele andmebaasile, sarnaneb Redis ja MongoDB-iga.
• Amazon Redshift - hallatud analüütiline andmebaas.

Põhikoht on, et need on vanad andmebaasid, kuid hallatav keskkond tõstab need esile, ilma seadme haldamise vajaduseta.

Märkus. Näited on toodud AWS keskkonnas, kuid nende analoogid on saadaval ka Microsoft Azure, Google Cloudi või Yandex.Cloudis.

Mis on uus? 2020. aastal ei ole midagi uut.

Serverless kontseptsioon

Turul 2020. aastal turule ilmunud uus asi on serveritundlikud või serverituks muudetud lahendused.

Püüan selgitada, mida see tähendab, tavalise teenuse või tagaosa rakenduse näitel.
Tavalise tagaosa rakenduse käitamiseks ostame või rendime serveri, kopeerime sellele koodi, avaldame välise lõpp-punkti ja maksame regulaarselt rendi, elektri ja andmekeskuse teenuste eest. See on standardne skeem.

Kas on kuidagi teisiti? Serveritundlike teenustega on see võimalik.

Mis on selle lähenemise fookus: serverit ei ole, isegi mitte virtuaalset instantsi pilves. Teenuse käitamiseks kopeerime koodi (funktsioonid) hoidlasse ja avaldame välise lõpp-punkti. Edasi maksame lihtsalt iga selle funktsiooni kutsumise eest, ignoreerides täielikult riistvara, kus see teostatakse.

Püüan illustreerida seda lähenemist joonistega.


Klassikaline rakendamine. Meil on teenus teatud koormusega. Käivitame kaks instantsi: füüsilisi servereid või AWS-i instantsi. Nendele instantsidele suunatakse välised päringud, mida seal töödeldakse.

Nagu pildilt näha, on serverid erinevalt koormatud. Üks on 100% koormatud, seal on kaks päringut, ja teine ainult 50% — on osaliselt vabade. Kui tuleb mitte kolm päringut, vaid 30, siis kogu süsteem ei suuda koormust taluda ja hakkab tõrkeid tekitama.

Serveritundlik rakendus. Serveritundlikus keskkonnas sellisel teenusel ei ole instantsseid ja servereid. On mingisugune kogum kuumutatud ressursse — väiksed ettevalmistatud Docker-konteinerid koos funktsiooni koodi käitamisega. Süsteem saab väliseid päringuid ja igaühe jaoks tõstab serveritundlik raamistik väikese konteineri koodiga: töötleb just selle päringu ja tapab konteineri.

Üks päring — üks tõstetud konteiner, 1000 päringut — 1000 konteinerit. Ja käitamine raua serverites on juba pilveteenuse pakkuja töö. See on täielikult varjatud serveritundliku raamistiku taha. Selles kontseptsioonis maksame iga kutsumise eest. Näiteks, kui üks kutsumine tuleb päevas — maksame ühe kutsumise eest, tuli miljon minutis — maksime miljoni eest. Või sekundis, seda juhtub samuti.

Serverless funktsiooni publikatsiooni kontseptsioon sobib stateless teenusele. Kui aga vajate (state) statefull teenust, lisame teenusele andmebaasi. Sellisel juhul, kui jõuame state'i töötlemiseni, kirjutab ja loeb iga statefull funktsioon lihtsalt andmebaasist. Pealegi mistahes kolmest tüübist andmebaasist, nagu artikli alguses kirjeldatud.

Mis on kõigi nende andmebaaside peamine piirang? See on pidevalt kasutatava pilve- või riistvara serveri (või mitme serveri) kulud. Pole tähtis, kas kasutame klassikalist andmebaasi või haldusandmebaasi, kas on DevOps ja administraator või mitte, maksame nii või teisiti 24/7 riistvara, elektri ja andmekeskuse rendi eest. Kui meil on klassikaline andmebaas, maksame masteri ja slave'i eest. Kui kõrge koormusega sharded andmebaas — maksame 10, 20 või 30 serveri eest, ja maksame pidevalt.

Kulusstruktuuri pidev serverite reserv on varem olnud vältimatu kurbus. Tavalistel andmebaasidel on ka teisi raskusi, nagu ühenduste arvule kehtestatud piirangud, skaleeritavuse kahjustamine, geograafiline konsensus — neid saab mõnes andmebaasis mõnevõrra lahendada, kuid mitte kõik korraga ega ideaalselt.

Serverless andmebaas — teooria

Küsimus 2020. aastast: kas andmebaasi saab ka serverless teha? Kõik on kuulnud serverless tagaplaanist... mis siis, kui proovime ka andmebaasi serverless teha?

See kõlab kummaliselt, sest andmebaas on ju statefull teenus, mis ei sobi väga hästi serverless infrastruktuuri. Samas on jaanus äärmiselt suur: gigabaitide, terabaitide ja analüütilistes andmebaasides isegi petabaitideni. Seda ei ole nii lihtsalt kergete Docker-konteinerite sees üles tõsta.

Teisest küljest, praktiliselt kõik tänapäevased andmebaasid sisaldavad tohutut hulka loogikat ja komponente: tehingud, terviklikkuse tagamine, protseduurid, seosed ja palju loogikat. Suuremas osas andmebaasi loogikast on vajalik ainult vähene state. Gigabaitide ja terabaitide andmeid kasutatakse otse ainult väikese osa andmebaasi loogikast, mis on seotud vahetu päringute täitmisega.

Seega idee: kui väike osa loogikast võimaldab stateless täitmist, miks mitte jagada andmebaasi stateful ja stateless osadeks.

Serverless OLAP lahenduste jaoks

Vaatame, kuidas võib andmebaasi jagamine stateful ja stateless osadeks välja näha praktiliste näidete põhjal.

Näiteks, meil on analüütiline andmebaas: välistest andmetest (punane silinder vasakul), ETL-protsess, mis laadib andmed andmebaasi, ja analüütik, kes saadab andmebaasi SQL-päringud. See on klassikaline andmete ladustamise töö skeem.

Selles skeemis täidetakse ETL tinglikult üks kord. Edasi tuleb pidevalt maksta serverite eest, kus asub ETL-laaditud andmebaas, et oleks, kuhu päringud suunata.

Vaatame alternatiivset lähenemist, mis on rakendatud AWS Athena Serverless andmebaasis. Siin pole pidevalt eraldatud riistvara, kus laaditud andmed asuvad. Selle asemel:

• Kasutaja saadab SQL-päringu Athendale. Athena optimeerija analüüsib SQL-päringut ja otsib andmehoidlast (Metadata) spetsiifilisi andmeid, mis on vajalikud päringu täitmiseks.
• Optimeerija, tuginedes kogutud andmetele, tõmbab vajalikud andmed välistest allikatest ajutisse andmehoidlasse (ajutisse andmebaasi).
• Ajutises andmehoidlas täidetakse kasutaja SQL-päring, tulemused tagastatakse kasutajale.
• Ajutine andmehoidla puhastatakse, ressursid vabastatakse.

Selles arhitektuuris maksame ainult päringu täitmise protsessi eest. Pole päringuid — pole kulusid.

See on toimiv lähenemine, ja seda rakendatakse mitte ainult Athena Serverless'is, vaid ka Redshift Spectrumis (AWS-is).

Athena näitel on näha, et Serverless andmebaas toimib tegelike päringute põhjal, millega käsitletakse kümneid ja sadu terabaiti andmeid. Saja terabaiti jaoks on vajalik sadu servereid, kuid me ei pea nende eest maksma — maksame päringute eest. Iga päringu kiirus on (väga) madal võrreldes spetsialiseeritud analüütiliste andmebaasidega nagu Vertica, kuid me ei maksa seisakute eest.

Selline andmebaas on rakendatav harvade analüütiliste ad-hoc päringute jaoks. Näiteks siis, kui otsustame spontaanselt kontrollida hüpoteesi hiiglaslikus andmemahtudes. Neid juhtumeid jaoks sobib Athena ideaalselt. Regulaarsete päringute puhul osutub selline süsteem kalliks. Sel juhul salvestage andmed mõnes spetsialiseeritud lahenduses.

Serverless OLTP lahenduste jaoks

Eelnevas näites vaadeldi OLAP-ülesandeid (analüütilised). Nüüd vaatame OLTP-ülesandeid.

Kujundame skaleeritav PostgreSQL või MySQL. Loome tavalise hallatava instantsi PostgreSQL või MySQL minimaalsete ressurssidega. Kui instantsile tuleb rohkem koormust, ühendame täiendavaid koopiaid, kuhu jaotame osa lugemisekoormusest. Kui päringut ja koormust pole — lülitame koopiad välja. Esimene instants on peamine ja ülejäänud on koopiad.

See idee on ellu viidud andmebaasis nimega Aurora Serverless AWS. Princips on lihtne: väliste rakenduste päringud võtab vastu proxy fleet. Näha koormuse kasvu, eraldatakse arvutusressursid eelnevalt soojendatud minimaalsetest instantsidest — ühendamine toimub maksimaalselt kiiresti. Instantside väljalülitamine toimub samuti.

Aurora-s on mõisted Aurora Capacity Unit, ACU. See on (tinglikult) instants (server). Iga konkreetne ACU võib olla peamine või koopia. Igal Capacity Unit'il on oma operatiivmälu, protsessor ja minimaalne ketas. Vastavalt on üks peamine ja ülejäänud ainult lugemiseks koopiad.

Nende töötavate Aurora Capacity Unit'ide arv on seadistatav parameeter. Minimaalne arv võib olla üks või null (sel juhul andmebaas ei tööta, kui päringuid ei ole).

Kui andmebaas saab päringute, tõstab proxy fleet Aurora Capacity Units, suurendades süsteemi tootmisressursse. Võime ressursse suurendada ja vähendada võimaldab süsteemil "jongleerida" ressurssidega: automaatselt välja lülitada üksikud ACU (asendades need uutega) ja rakendada välja lülitatud ressurssidele kõik uuendused.

Aurora Serverless andmebaas suudab skaleerida lugemisekoormust. Kuid dokumentatsioonis ei ole sellest otseselt öeldud. Võib tekkida tunne, et nad saavad tõsta multi-masteri. Imesid pole siin aga.

See and on infrusturi, et viia ei oleneb, kui ta ei ole lüganud süsteemide. Näiteks, MVP või visiitkaardilehtede loomise puhul ei ootame tavaliselt stabiilset koormust. Seega, kui juurdepääsu ei ole, ei maksa me instantside eest. Kui ootamatult tekib koormus, näiteks pärast konverentsi või reklaamikampaaniat, plahvatavad ligipääsu ja koormus tõuseb kiiresti, Aurora Serverless võtab automaatselt selle koormuse ja kiirelt ühendab lisavähendused (ACU). Järgmine konverents läheb, kõik unustavad prototüübi, serverid (ACU) kustutatakse ja kulud langevad nulli — mugav.

See lahendus ei sobi stabiilse kõrge koormuse korral, kuna see ei oska skaleerida kirjutamiskoormust. Kõik need ressursid ühendavad ja lahti ühendavad toimuvad nii-öelda 'scale point'i' hetkel — ajal, mil andmebaas ei ole tehingu all, ajutised tabelid ei hoia. Näiteks, nädalas võib scale point mitte toimuda ja andmebaas töötab üksi ressursidega ning ei saa ei laieneda, ega väheneda.

Mingeid imesid ei ole — see on tavaline PostgreSQL. Kuid masinate lisamise ja lahtiühendamise protsess on osaliselt automatiseeritud.

Serverless by design

Aurora Serverless on vana andmebaas, ümber kirjutatud pilve jaoks, et kasutada eraldi Serverless'i eeliseid. Nüüd räägin andmebaasist, mis on algselt kirjutatud pilve jaoks, serverless lähenemise alla — Serverless-by-design. Seda arendati kohe ilma eelduseta, et see töötab füüsilistel serveritel.

See andmebaas on nimega Snowflake. Sellel on kolm peamist plokki.

Esimene — see on metaandmete plokk. See on kiire in-memory teenus, mis lahendab turvakahtlused, metaandmed, tehingud, päringute optimeerimise (vasakul joonisel).

Teine plokk — see on hulk virtuaalseid arvutusklastreid arvutuste jaoks (joonisel — siniste ringide kogum).

Kolmas plokk — andmete salvestamise süsteem, mis põhineb S3-l. S3 on mõõtmeteta objektide salvestus AWS-is, just nagu mõõtmeteta Dropbox ettevõtetele.

Vaadake, kuidas Snowflake töötab külma käivitamise eeldustes. See tähendab, et andmebaas on olemas, andmed on laaditud, kuid töötavaid päringuid pole. Seega, kui andmebaasi ei tule päringuid, siis on meil üles tõstetud kiire in-memory Metaandmete teenus (esimene plokk). Ja meil on S3 salvestus, kus on andmed tabelite kohta, jagatud nn mikropartiidesse. Lihtsuse huvides: kui tabelis on tehingud, siis on mikropartiid tehingute päevad. Iga päev on eraldi mikroparti, eraldi fail. Ja kui andmebaas töötab sellises režiimis, maksate ainult andmete kasutatud koha eest. Lisaks on koha maksumus väga madal (eriti arvestades olulist tihendamist). Metaandmete teenus töötab samuti pidevalt, kuid päringute optimeerimise jaoks ei ole palju ressursse vajalik, seega võib teenust pidada tinglikult tasuta.

Nüüd kujutame ette, et meie andmebaasi on tulnud kasutaja ja esitanud SQL-päringu. SQL-päring saadetakse kohe töötlemiseks Metaandmete teenusele. Seega, pärast päringu saamist, analüüsib see teenus päringut, saadaval olevaid andmeid, kasutaja õigusi ja kui kõik on hästi, koostab töötlemise plaani.

Seejärel käivitab teenus arvutusklastri. Arvutusklaster on serverite klaster, mis teostab arvutusi. See tähendab, et klaster võib sisaldada 1 serverit, 2 serverit, 4, 8, 16, 32 — nii palju kui soovite. Te esitate päringu ja selle jaoks algab klastrite käivitamine sekundite jooksul.

Edasi, pärast seda, kui klaster on käivitatud, hakkavad S3-st klastrisse kopeeruma mikropartitsioonid, mis on vajalikud just teie päringu töötlemiseks. Eeldame, et SQL-päringu täitmiseks on vaja kahte partitsiooni ühest tabelist ja ühte teisest. Niisiis kopeeritakse klastrisse ainult kolm vajalikku partitsiooni, mitte kõik tabelid täielikult. Just seetõttu, et kõik asub samas andmekeskuses ja on ühendatud väga kiirete kanalitega, toimub kogu edastamisprotsess äärmiselt kiiresti: sekunditega, väga harva — minutitega, kui jutt ei käi mingi väga keerulise päringu kohta. Vastavalt sellele kopeeritakse mikropartitsioonid arvutusklastrisse ja pärast lõpetamist täidetakse SQL-päring just sellel arvutusklastril. Selle päringu tulemuseks võib olla üks rida, mitu rida või tabel — need saadetakse välja kasutajale, et ta saaks need alla laadida, oma BI-tööriistas näidata või muul viisil kasutada.

Iga SQL-päring mitte ainult ei loe agrageeritud andmeid varasemalt laaditud andmetest, vaid võib ka laadida/luua uusi andmeid andmebaasis. See tähendab, et see võib olla päring, mis näiteks sisestab teise tabelisse uusi kirjeid, mis toob kaasa uue partitsiooni tekkimise arvutusklassis, mis omakorda salvestatakse automaatselt ühte S3 salvestusse.

Ülaltoodud stsenaarium, alates kasutaja saabumisest kuni klastrite tõstmiseni, andmete laadimine, päringute täitmine ja tulemuste saamine, arvestatakse välja tõstetud virtuaalse arvutusklastri, virtuaalse ladustamise, kasutamise minutitasu alusel. Tasu varieerub sõltuvalt AWS tsoonist ja klastrisuurusest, kuid keskmiselt on see paar dollarit tunnis. Neli masinat sisaldav klaster maksab kaks korda rohkem kui kaks masinat, kaheksa masinat maksab veel kaks korda rohkem. Saadaval on variandid 16, 32 masinaga, sõltuvalt päringute keerukusest. Kuid te maksate ainult selle eest, kui klaster reaalselt töötab, kuna päringute puudumisel kui te nagu eemaldatud käed, ja pärast 5-10-minutilist ootamist (kohandatav parameeter) lülitub see iseenesest välja, vabastab ressursid ja muutub tasuta.

On täiesti reaalne stsenaarium, kus esitades päringu kerkib klaster üles, nii öelda, minuti jooksul, veel minut ta arvutab, seejärel viis minutit välja lülitamiseks, ning lõpuks maksate te selle klastiku töö eest seitsme minuti alusel, mitte kuude ja aastate kaupa.

Esimene stsenaarium kirjeldas Snowflake'i kasutamist ühemõtmelises variandis. Nüüd kujutame ette, et kasutajaid on palju, mis on juba lähemal reaalsetele stsenaariumidele.

Oletame, et meil on palju analüütikuid ja Tableau aruandeid, mis pidevalt pommitavad meie andmebaasi suure hulga mitte liiga keeruliste analüütiliste SQL-päringutega.

Peale selle oletame, et meil on leidlikud andateadlased, kes proovivad andmetega hirmsaid asju teha, käsitledes kümneid terabaite, analüüsides miljardeid ja triljoneid andmereale.

Ülaltoodud kahe koormustüübi jaoks võimaldab Snowflake tõsta mitmeid sõltumatuid arvutusklastreid erineva võimsusega. Veel enam, need arvutusklastrid töötavad iseseisvalt, kuid jagavad ühist kooskõlastatud teavet.

Paljude kergete päringute jaoks saab tõsta 2-3 väikest klastrit, mis on suuruselt, öeldes tinglikult, 2 masinat igaühes. See käitumine on rakendatav ka automaatsete seadistuste abil. St ütlete: „Snowflake, tõsta väike klaster. Kui koormus sellel kasvab üle teatud parameetri, tõsta sarnane teine, kolmas. Kui koormus hakkab langema—lülita liigsed välja.” Selleks, et sõltumata sellest, kui palju analüütikuid tuleb ja aruandeid vaatab, jaguks kõigile ressursse.

Sel juhul, kui analüütikud magavad ja keegi aruandeid ei vaata — klastrid võivad täielikult välja lülituda, ja te lõpetate nende eest maksmise.

Samas, raskete päringute (andateadlastelt) jaoks võite tõsta ühe väga suure klastriga, näiteks 32 masinat. Seda klastrit hakatakse samuti arvestama ainult nende minutite ja tundide eest, mil seal töötab teie hiiglaslik päring.

Ülaltoodud võimalus võimaldab jagada klastreid mitte ainult kahe, vaid ka rohkemate koormustüüpide vahel (ETL, monitooring, aruannete materialiseerimine,…).

Teeme kokkuvõtte Snowflake'ist. Andmebaas ühendab kauni idee ja töötava rakenduse. ManyChat'is kasutame Snowflake'i kõigi olemasolevate andmete analüüsiks. Meil ei ole klastreid kolm, nagu näites, vaid 5 kuni 9, erineva suurusega. Meil on tinglikult 16-masinilised, 2-masinilised ning superväikesed 1-masinilised teatud ülesannete jaoks. Nad jaotavad koormust tõhusalt ja aitavad meil palju kokku hoida.

Andmebaas suudab edukalt skaleerida nii lugemise kui kirjutamise koormust. See on tohutu erinevus ja suur läbimurre võrreldes näiteks „Aurora’ga”, mis toetas vaid lugemise koormust. Snowflake võimaldab nende arvutuste klastrite abil skaleerida ka kirjutamise koormust. Nagu mainisin, kasutame ManyChat'is mitut klastrit, kus väikesed ja superväikesed klastrid on peamiselt kasutusel ETL-ks, andmete laadimiseks. Analüütikud töötavad keskmistel klastritel, mis ei puutu ETL-koormusse, seega töötavad nad väga kiiresti.

Seega sobib andmebaas hästi OLAP-ülesannete jaoks. Kahjuks ei ole see veel rakendatav OLTP-koormuste jaoks. Esiteks on see andmebaas veergude põhine, koos kõikide sellest tulenevate tagajärgedega. Teiseks, ise lähenemine, kus iga päringu korral tõstate vastavalt vajadusele arvutusklastri ja täidate selle andmetega, on kahjuks OLTP-koormuste jaoks veel liiga aeglane. Sekundite ootamine OLAP-ülesannete jaoks on normaalne, kuid OLTP-ülesannete puhul on see vastuvõetamatu; parem oleks 100 ms, veel parem — 10 ms.

Kokkuvõte

Serverless andmebaas on võimalik tänu andmebaasi jagamisele staatless ja stateful osadeks. Olete kindlasti märganud, et kõigis toodud näidetes on stateful osa – tinglikult öeldes, mikropartitsioonide salvestamine S3-s, samas kui stateless on optimeerija, tegevus metaandmetega, turvalisuse küsimuste töötlemine, mida saab tõsta sõltumatute kergete stateless teenustena.

SQL-päringute täitmist saab samuti välja võtta teenustena, millel on kerge olek, mis võivad ilmuda serverless režiimis, nagu Snowflake'i arvutuskogud, alla laadida ainult vajalikud andmed, teostada päring ja "surnud".

Serverless andmete baasid tootmisvõimsusega on juba kasutamiseks saadaval ja need töötavad. Need serverless andmebaasid on juba valmis toime tulema OLAP-ülesannetega. Kahjuks kasutatakse neid OLTP-ülesannete puhul... teatud eripäradega, kuna on piiranguid. Ühelt poolt on see miinus. Teiselt poolt on see võimalus. Võib-olla leiab mõni lugeja viisi, kuidas OLTP-andmebaasi täielikult serverless'iks teha, ilma Aurora piiranguteta.

Loodan, et see oli huvitav. Serverless'i tulevik on tulemas 🙂

Allikas: habr.com