Tere kõigile! Minu nimi on Golov Nikolay. Varem töötasin Avitos ja juhtisin kuus aastat andmeplatvormi, st töötasin kõikide andmebaasidega: analüütilise (Vertica, ClickHouse), voogedastusega ja OLTP-ga (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Selle aja jooksul tegelesin suure hulga andmebaasidega – väga erinevate ja ebatavaliste ning nende kasutamise ebastandardsete juhtumitega.
Praegu töötan ManyChatis. Sisuliselt on see startup – uus, ambitsioonikas ja kiiresti kasvav. Ja kui ma esimest korda ettevõttega liitusin, tekkis klassikaline küsimus: "Mida peaks noor startup nüüd DBMS-i ja andmebaaside turult võtma?"
Selles artiklis, mis põhineb minu aruandel aadressil , vastan sellele küsimusele. Aruande videoversioon on saadaval aadressil .
Üldtuntud andmebaasid 2020
On aasta 2020, vaatasin ringi ja nägin kolme tüüpi andmebaase.
Esimene tüüp - klassikalised OLTP andmebaasid: PostgreSQL, SQL Server, Oracle, MySQL. Need on kirjutatud kaua aega tagasi, kuid on endiselt asjakohased, kuna need on arendajatele nii tuttavad.
Teine tüüp on alused "nullist". Nad püüdsid klassikalistest mustritest eemalduda, loobudes SQL-ist, traditsioonilistest struktuuridest ja ACID-st, lisades sisseehitatud shardingi ja muid atraktiivseid funktsioone. Näiteks on see Cassandra, MongoDB, Redis või Tarantool. Kõik need lahendused tahtsid pakkuda turule midagi põhimõtteliselt uut ja hõivasid oma niši, sest osutusid teatud ülesannete täitmiseks ülimalt mugavaks. Tähistan need andmebaasid katusterminiga NOSQL.
“Nullid” on möödas, harjusime NOSQL-i andmebaasidega ja maailm astus minu vaatenurgast järgmise sammu – et hallatavad andmebaasid. Nendel andmebaasidel on sama tuum, mis klassikalistel OLTP andmebaasidel või uutel NoSQL-i andmebaasidel. Kuid nad ei vaja DBA-d ja DevOpsi ning töötavad hallatud riistvaraga pilvedes. Arendaja jaoks on see "lihtsalt baas", mis kuskil töötab, kuid kedagi ei huvita, kuidas see serverisse installitakse, kes serveri seadistas ja kes värskendab.
Selliste andmebaaside näited:
- AWS RDS on PostgreSQL-i/MySQL-i hallatav ümbris.
- DynamoDB on dokumendipõhise andmebaasi AWS-i analoog, mis sarnaneb Redise ja MongoDB-ga.
- Amazon Redshift on hallatav analüütiline andmebaas.
Need on põhimõtteliselt vanad andmebaasid, kuid loodud hallatavas keskkonnas, ilma et oleks vaja töötada riistvaraga.
Märge. Näited on võetud AWS-i keskkonna jaoks, kuid nende analoogid on olemas ka Microsoft Azure'is, Google Cloudis või Yandex.Cloudis.
Mis on selles uut? 2020. aastal mitte midagi sellest.
Serverita kontseptsioon
Mis on 2020. aastal turul tõeliselt uus, on serverita või serverita lahendused.
Püüan tavateenuse või taustarakenduse näitel selgitada, mida see tähendab.
Tavalise taustarakenduse juurutamiseks ostame või rendime serveri, kopeerime sellele koodi, avaldame lõpp-punkti väljaspool ning maksame regulaarselt üüri, elektri ja andmekeskuse teenuste eest. See on standardskeem.
Kas on muud võimalust? Serverita teenustega saate seda teha.
Millele see lähenemine keskendub: serverit pole, pilves pole isegi virtuaalset eksemplari rentida. Teenuse juurutamiseks kopeerige kood (funktsioonid) hoidlasse ja avaldage see lõpp-punktis. Seejärel maksame lihtsalt iga selle funktsiooni kõne eest, ignoreerides täielikult riistvara, kus see käivitatakse.
Püüan seda lähenemist piltidega illustreerida.
Klassikaline juurutamine. Meil on teatud koormusega teenus. Toome välja kaks eksemplari: füüsilised serverid või eksemplarid AWS-is. Nendele eksemplaridele saadetakse välised päringud ja neid töödeldakse seal.
Nagu pildilt näha, ei utiliseerita servereid võrdselt. Üks on 100% kasutatud, on kaks taotlust ja üks on ainult 50% - osaliselt jõude. Kui saabub mitte kolm taotlust, vaid 30, siis ei saa kogu süsteem koormusega toime ja hakkab aeglustuma.
Serverita juurutamine. Serverita keskkonnas pole sellisel teenusel eksemplare ega servereid. Seal on teatud kogum köetavaid ressursse - väikesed ettevalmistatud Dockeri konteinerid koos juurutatud funktsioonikoodiga. Süsteem võtab vastu välised päringud ja igaühe jaoks tõstab serverita raamistik väikese koodiga konteineri: töötleb selle konkreetse päringu ja tapab konteineri.
Üks taotlus – üks konteiner tõstetud, 1000 taotlust – 1000 konteinerit. Ja riistvaraserverites juurutamine on juba pilveteenuse pakkuja töö. Serverita raamistik on selle täielikult peidetud. Selles kontseptsioonis maksame iga kõne eest. Näiteks tuli üks kõne päevas – maksime ühe kõne eest, miljon tuli minutis – maksime miljoni eest. Või sekundiga juhtub ka see.
Serverita funktsiooni avaldamise kontseptsioon sobib olekuta teenuse jaoks. Ja kui vajate (osariigi) statefull teenust, siis lisame teenusele andmebaasi. Sel juhul olekuga töötamisel iga olekutäielik funktsioon lihtsalt kirjutab ja loeb andmebaasist. Veelgi enam, mis tahes kolmest artikli alguses kirjeldatud tüübist andmebaasist.
Mis on kõigi nende andmebaaside ühine piirang? Need on pidevalt kasutatava pilve- või riistvaraserveri (või mitme serveri) kulud. Pole vahet, kas kasutame klassikalist või hallatavat andmebaasi, kas meil on Devops ja administraator või mitte, riistvara, elektri ja andmekeskuse rentimise eest maksame ikka 24/7. Kui meil on klassikaline baas, maksame peremehe ja orja eest. Kui tegemist on suure koormusega killustatud andmebaasiga, maksame 10, 20 või 30 serveri eest ja maksame pidevalt.
Püsireserveeritud serverite olemasolu kulustruktuuris peeti varem vajalikuks paheks. Tavapärastel andmebaasidel on ka muid raskusi, näiteks ühenduste arvu piirangud, skaleerimispiirangud, geo-jaotatud konsensus – neid saab teatud andmebaasides kuidagi lahendada, aga mitte kõiki korraga ja mitte ideaalis.
Serverita andmebaas – teooria
2020. aasta küsimus: kas andmebaasi on võimalik ka serverivabaks muuta? Kõik on kuulnud serverita taustaprogrammist... proovime teha andmebaasi serverivabaks?
See kõlab kummaliselt, sest andmebaas on olekut täis teenus, mis ei sobi serverita infrastruktuuri jaoks. Samas on andmebaasi olek väga suur: gigabaite, terabaite ja analüütilistes andmebaasides isegi petabaite. Kergetesse Dockeri konteineritesse pole seda nii lihtne tõsta.
Teisest küljest sisaldavad peaaegu kõik kaasaegsed andmebaasid tohutul hulgal loogikat ja komponente: tehingud, terviklikkuse koordineerimine, protseduurid, relatsioonilised sõltuvused ja palju loogikat. Päris suure andmebaasiloogika jaoks piisab väikesest olekust. Gigabaite ja terabaite kasutab otseselt vaid väike osa andmebaasi loogikast, mis on seotud päringute otsese täitmisega.
Sellest lähtuvalt on idee järgmine: kui osa loogikast võimaldab olekuta täitmist, siis miks mitte jagada baas olekupõhisteks ja olekuta osadeks.
Serverita OLAP-lahenduste jaoks
Vaatame praktiliste näidete abil, kuidas võiks välja näha andmebaasi olekuga ja olekuta osadeks lõikamine.
Näiteks on meil analüütiline andmebaas: välisandmed (vasakul punane silinder), ETL protsess, mis laadib andmed andmebaasi ja analüütik, kes saadab andmebaasi SQL päringuid. See on klassikaline andmelao tööskeem.
Selles skeemis teostatakse ETL tingimuslikult üks kord. Siis tuleb pidevalt ETL-iga täidetud andmetega maksta serverite eest, millel andmebaas töötab, et oleks, kuhu päringuid saata.
Vaatame AWS Athena Serverlessis rakendatud alternatiivset lähenemisviisi. Allalaaditud andmete salvestamiseks pole püsivalt spetsiaalset riistvara. Selle asemel:
- Kasutaja saadab Athenale SQL-päringu. Athena optimeerija analüüsib SQL-päringut ja otsib metaandmete salvest (Metadata) päringu täitmiseks vajalikke konkreetseid andmeid.
- Optimeerija laeb kogutud andmete põhjal vajalikud andmed välistest allikatest ajutisse salvestusruumi (ajutisse andmebaasi).
- Kasutajalt saadud SQL-päring käivitatakse ajutises salvestusruumis ja tulemus tagastatakse kasutajale.
- Ajutine salvestusruum tühjendatakse ja ressursid vabastatakse.
Selles arhitektuuris maksame ainult päringu täitmise protsessi eest. Pole taotlusi - pole kulusid.
See on töötav lähenemisviis ja seda rakendatakse mitte ainult Athena Serverlessis, vaid ka Redshift Spectrumis (AWS-is).
Athena näide näitab, et serverita andmebaas töötab reaalsete päringute puhul, mis sisaldavad kümneid ja sadu terabaite andmeid. Sajad terabaidid nõuavad sadu servereid, kuid me ei pea nende eest maksma – me maksame päringute eest. Iga päringu kiirus on (väga) madal võrreldes spetsiaalsete analüütiliste andmebaasidega nagu Vertica, kuid me ei maksa seisakuperioodide eest.
Selline andmebaas on rakendatav harvaesinevate analüütiliste ad-hoc päringute jaoks. Näiteks kui otsustame spontaanselt testida hüpoteesi mõnel hiiglaslikul hulgal andmetel. Athena on nendel juhtudel ideaalne. Tavapäringute puhul on selline süsteem kallis. Sel juhul salvestage andmed vahemällu mõnes spetsiaalses lahenduses.
Serverita OLTP-lahenduste jaoks
Eelmises näites vaadeldi OLAP-i (analüütilisi) ülesandeid. Vaatame nüüd OLTP ülesandeid.
Kujutagem ette skaleeritavat PostgreSQL-i või MySQL-i. Tõstame minimaalsete ressurssidega tavalise hallatava PostgreSQL-i või MySQL-i eksemplari. Kui eksemplar saab rohkem koormust, ühendame täiendavad koopiad, millele jagame osa lugemiskoormusest. Kui taotlusi või laadimist pole, lülitame koopiad välja. Esimene eksemplar on juht ja ülejäänud on koopiad.
Seda ideed rakendatakse andmebaasis nimega Aurora Serverless AWS. Põhimõte on lihtne: väliste rakenduste päringud võetakse vastu puhverserveri laevastiku poolt. Nähes koormuse kasvu, eraldab see arvutusressursse eelsoojendatud minimaalsetest eksemplaridest - ühendus luuakse nii kiiresti kui võimalik. Juhtumite keelamine toimub samal viisil.
Auroras on Aurora võimsusüksuse kontseptsioon ACU. See on (tinglikult) eksemplar (server). Iga konkreetne ACU võib olla ülem- või alamseade. Igal võimsusüksusel on oma RAM, protsessor ja minimaalne ketas. Sellest lähtuvalt on üks kapten, ülejäänud on ainult lugemiseks mõeldud koopiad.
Nende töötavate Aurora mahuühikute arv on konfigureeritav parameeter. Minimaalne kogus võib olla üks või null (sel juhul andmebaas ei tööta, kui päringuid pole).
Kui baas saab päringuid, tõstab puhverserveri laevastik Aurora võimsusühikuid, suurendades süsteemi jõudlusressursse. Võimalus ressursse suurendada ja vähendada võimaldab süsteemil ressurssidega “žongleerida”: kuvada automaatselt üksikud ACU-d (asendades need uutega) ja käivitada kõik väljavõetud ressursside praegused värskendused.
Aurora Serverless baas suudab lugemiskoormust skaleerida. Kuid dokumentatsioon seda otseselt ei ütle. Võib tunduda, et nad suudavad multimasterit tõsta. Maagiat pole.
See andmebaas sobib hästi selleks, et vältida tohutute rahasummade kulutamist ettearvamatu juurdepääsuga süsteemidele. Näiteks MVP või visiitkaartide saitide turundamisel me tavaliselt stabiilset koormust ei oota. Seega, kui juurdepääsu pole, siis me juhtumite eest ei maksa. Ootamatu koormuse korral, näiteks pärast konverentsi või reklaamikampaaniat, külastab saiti palju inimesi ja koormus suureneb hüppeliselt, võtab Aurora Serverless selle koormuse automaatselt ja ühendab kiiresti puuduvad ressursid (ACU). Siis konverents möödub, kõik unustavad prototüübi, serverid (ACU) lähevad pimedaks ja kulud langevad nulli – mugav.
See lahendus ei sobi stabiilse suure koormuse jaoks, kuna see ei skaleeri kirjutamiskoormust. Kõik need ressursside ühendused ja lahtiühendamised toimuvad nn mastaabipunktis - ajahetkel, mil andmebaasi ei toeta tehing ega ajutised tabelid. Näiteks nädala jooksul ei pruugi mastaabipunkti toimuda ja baas töötab samadel ressurssidel ega saa lihtsalt laieneda ega kahaneda.
Maagiat pole – see on tavaline PostgreSQL. Kuid masinate lisamise ja lahtiühendamise protsess on osaliselt automatiseeritud.
Disainilt serverivaba
Aurora Serverless on vana andmebaas, mis on pilve jaoks ümber kirjutatud, et kasutada ära mõningaid Serverlessi eeliseid. Ja nüüd räägin teile baasist, mis oli algselt kirjutatud pilve jaoks serverivaba lähenemisviisi jaoks - Serverless-by-design. See töötati kohe välja, eeldamata, et see töötab füüsilistes serverites.
Seda alust nimetatakse lumehelbeks. Sellel on kolm võtmeplokki.
Esimene on metaandmete plokk. See on kiire mälusisene teenus, mis lahendab turvalisuse, metaandmete, tehingute ja päringute optimeerimisega seotud probleemid (näidatud vasakpoolsel joonisel).
Teine plokk on arvutuste jaoks mõeldud virtuaalsete andmetöötlusklastrite komplekt (illustratsioonil on siniste ringide komplekt).
Kolmas plokk on S3-l põhinev andmesalvestussüsteem. S3 on mõõtmeteta objektide salvestamine AWS-is, omamoodi nagu dimensioonitu Dropbox äri jaoks.
Vaatame, kuidas Snowflake töötab, eeldades külmkäivitust. See tähendab, et andmebaas on olemas, andmed laaditakse sellesse, jooksvaid päringuid pole. Vastavalt sellele, kui andmebaasi päringuid pole, oleme tõstnud kiire mälusisese metaandmete teenuse (esimene plokk). Ja meil on S3 salvestusruum, kuhu salvestatakse tabeliandmed, mis on jagatud nn mikropartitsioonideks. Lihtsuse mõttes: kui tabel sisaldab tehinguid, siis mikropartitsioonid on tehingute päevad. Iga päev on eraldi mikropartitsioon, eraldi fail. Ja kui andmebaas töötab selles režiimis, maksate ainult andmetega hõivatud ruumi eest. Pealegi on määr istme kohta väga madal (eriti kui arvestada märkimisväärset kokkusurumist). Metaandmete teenus töötab samuti pidevalt, kuid päringute optimeerimiseks pole vaja palju ressursse ja teenust võib pidada jagamisvaraks.
Kujutagem nüüd ette, et kasutaja tuli meie andmebaasi ja saatis SQL-päringu. SQL-päring saadetakse koheselt töötlemiseks metaandmete teenusesse. Sellest lähtuvalt analüüsib see teenus päringu saamisel päringut, saadaolevaid andmeid, kasutajaõigusi ja kui kõik on korras, koostab päringu töötlemise plaani.
Järgmisena käivitab teenus andmetöötlusklastri käivitamise. Arvutusklaster on arvutusi teostavate serverite klaster. See tähendab, et see on klaster, mis võib sisaldada 1 serverit, 2 serverit, 4, 8, 16, 32 - nii palju kui soovite. Esitate päringu ja selle klastri käivitamine algab kohe. See võtab tõesti sekundeid.
Järgmiseks, pärast klastri käivitamist, hakatakse teie päringu töötlemiseks vajalikke mikropartitsioone kopeerima S3-st. See tähendab, kujutame ette, et SQL-päringu täitmiseks vajate ühest tabelist kahte ja teisest ühte partitsiooni. Sel juhul kopeeritakse klastrisse ainult kolm vajalikku partitsiooni, mitte kõiki tabeleid. Seetõttu ja just seetõttu, et kõik asub ühes andmekeskuses ja on ühendatud väga kiirete kanalitega, toimub kogu edastusprotsess väga kiiresti: sekunditega, väga harva minutitega, kui me ei räägi mõnest koletutest taotlustest. Vastavalt sellele kopeeritakse mikropartitsioonid arvutusklastrisse ja pärast lõpetamist täidetakse selles andmetöötlusklastris SQL-päring. Selle päringu tulemuseks võib olla üks rida, mitu rida või tabel – need saadetakse kasutajale väljastpoolt, et ta saaks selle alla laadida, oma BI tööriistas kuvada või muul viisil kasutada.
Iga SQL-päring ei saa lugeda mitte ainult varem laaditud andmete koondfaile, vaid ka laadida / genereerida andmebaasis uusi andmeid. See tähendab, et see võib olla päring, mis lisab näiteks uued kirjed teise tabelisse, mis viib arvutusklastrisse uue partitsiooni ilmumiseni, mis omakorda salvestatakse automaatselt ühte S3-mällu.
Ülalkirjeldatud stsenaariumi eest, alates kasutaja saabumisest kuni klastri tõstmiseni, andmete laadimiseni, päringute täitmiseni, tulemusteni, tasutakse tõstetud virtuaalse arvutusklastri, virtuaallao kasutamise minutite määras. Kurss varieerub sõltuvalt AWS-i tsoonist ja klastri suurusest, kuid keskmiselt on see paar dollarit tunnis. Neljast masinast koosnev klaster on kaks korda kallim kui kahest masinast koosnev klaster ja kaheksast masinast koosnev klaster on endiselt kaks korda kallim. Olenevalt taotluste keerukusest on saadaval 16, 32 masina valikud. Kuid maksate ainult nende minutite eest, kui klaster tegelikult töötab, sest kui taotlusi pole, võtate oma käed ära ja pärast 5-10-minutilist ootamist (konfigureeritav parameeter) kustub see iseenesest, vabastage ressursse ja saate vabaks.
Täiesti realistlik stsenaarium on selline, et kui saadate päringu, siis klaster hüppab üles, suhteliselt minuti pärast, see loeb veel minut, seejärel viis minutit sulgemiseks ja maksate selle klastri seitsme minuti töötamise eest ja mitte kuude ja aastate jooksul.
Esimene stsenaarium, mida kirjeldati Snowflake'i kasutamist ühe kasutaja seades. Kujutagem nüüd ette, et kasutajaid on palju, mis on tegelikule stsenaariumile lähemal.
Oletame, et meil on palju analüütikuid ja Tableau raporteid, mis pommitavad meie andmebaasi pidevalt suure hulga lihtsate analüütiliste SQL-päringutega.
Lisaks oletame, et meil on leidlikud andmeteadlased, kes üritavad andmetega koletuid asju teha, opereerida kümnete terabaitidega, analüüsida miljardeid ja triljoneid andmeridasid.
Eespool kirjeldatud kahte tüüpi töökoormuse puhul võimaldab Snowflake luua mitu erineva võimsusega sõltumatut andmetöötlusklastrit. Lisaks töötavad need andmetöötlusklastrid iseseisvalt, kuid ühiste järjepidevate andmetega.
Suure hulga kergete päringute jaoks saate luua 2–3 väikest klastrit, igaühes ligikaudu 2 masinat. Seda käitumist saab muu hulgas rakendada automaatsete seadistuste abil. Nii et sa ütled: “Lumehelves, tõsta väike kobar. Kui selle koormus tõuseb üle teatud parameetri, tõstke samasugune teine, kolmas. Kui koormus hakkab taanduma, kustuta üleliigne. Et ükskõik kui palju analüütikuid tuleb ja aruandeid vaatama hakkab, on kõigil piisavalt ressursse.
Samal ajal, kui analüütikud magavad ja keegi aruandeid ei vaata, võivad klastrid täielikult pimedaks minna ja te lõpetate nende eest maksmise.
Samal ajal saate raskete päringute jaoks (Data Scientistsilt) luua ühe väga suure klastri 32 masina jaoks. Sellele klastrile makstakse ka ainult nende minutite ja tundide eest, mil teie hiiglaslik päring seal töötab.
Ülalkirjeldatud võimalus võimaldab klastritesse jagada mitte ainult 2, vaid ka rohkemat tüüpi töökoormust (ETL, monitooring, aruannete materialiseerimine,...).
Teeme lumehelbe kokkuvõtte. Alus ühendab endas ilusa idee ja toimiva teostuse. ManyChatis kasutame Snowflake'i kõigi meil olevate andmete analüüsimiseks. Meil ei ole kolme klastrit, nagu näites, vaid 5 kuni 9 erineva suurusega klastreid. Meil on mõnede ülesannete jaoks tavapärased 16-, 2-masinalised ja ka üliväikesed 1-masinalised. Nad jaotavad koormust edukalt ja võimaldavad meil palju kokku hoida.
Andmebaas skaleerib edukalt lugemis- ja kirjutamiskoormust. See on tohutu erinevus ja tohutu läbimurre võrreldes sama “Auroraga”, mis kandis ainult lugemiskoormust. Snowflake võimaldab teil nende andmetöötlusklastritega oma kirjutamiskoormust skaleerida. See tähendab, et nagu mainisin, kasutame ManyChatis mitut klastrit, väikseid ja üliväikesi klastreid kasutatakse peamiselt ETL-i jaoks, andmete laadimiseks. Ja analüütikud elavad juba keskmistes klastrites, mida ETL-i koormus absoluutselt ei mõjuta, nii et nad töötavad väga kiiresti.
Sellest lähtuvalt sobib andmebaas hästi OLAP-i ülesannete täitmiseks. Kahjuks pole see aga OLTP töökoormuste jaoks veel rakendatav. Esiteks on see andmebaas koos kõigi sellest tulenevate tagajärgedega veeruline. Teiseks, lähenemine ise, kui iga päringu puhul tõstad vajadusel üles arvutusklastri ja ujutad selle andmetega üle, ei ole kahjuks veel piisavalt kiire OLTP laadimiseks. OLAP-ülesannete jaoks sekundite ootamine on normaalne, kuid OLTP-ülesannete puhul on see vastuvõetamatu; 100 ms oleks parem või 10 ms veelgi parem.
Summaarne
Serverita andmebaas on võimalik, jagades andmebaasi olekuta ja olekuta osadeks. Võib-olla olete märganud, et kõigis ülaltoodud näidetes on Stateful osa suhteliselt S3-s mikropartitsioonide talletamine ja olekuta on optimeerija, mis töötab metaandmetega ja tegeleb turvaprobleemidega, mida saab tõstatada iseseisvate kergete olekuta teenustena.
SQL-päringute täitmist võib tajuda ka kerge oleku teenustena, mis võivad ilmuda serverita režiimis, näiteks Snowflake'i arvutusklastrid, laadida alla ainult vajalikud andmed, täita päringu ja "välja minna".
Serverita tootmistaseme andmebaasid on juba kasutamiseks saadaval, need töötavad. Need serverita andmebaasid on juba valmis OLAP-i toiminguid käsitlema. Kahjuks kasutatakse neid OLTP-ülesannete jaoks... nüanssidega, kuna on piiranguid. Ühest küljest on see miinus. Kuid teisest küljest on see võimalus. Võib-olla leiab keegi lugejatest võimaluse muuta OLTP andmebaas täiesti serverivabaks, ilma Aurora piiranguteta.
Loodan, et see oli teile huvitav. Serverita on tulevik :)
Allikas: www.habr.com