Pozdravljeni vsi skupaj! Moje ime je Golov Nikolay. Prej sem delal v podjetju Avito in šest let upravljal Data Platformo, torej sem delal na vseh bazah podatkov: analitičnih (Vertica, ClickHouse), pretočnih in OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). V tem času sem imel opravka z velikim številom baz podatkov - zelo različnih in nenavadnih ter z nestandardnimi primeri njihove uporabe.
Trenutno delam pri ManyChat. V bistvu je to startup – nov, ambiciozen in hitro rastoč. In ko sem se prvič pridružil podjetju, se je pojavilo klasično vprašanje: "Kaj naj mladi startup zdaj vzame s trga DBMS in baz podatkov?"
V tem članku na podlagi mojega poročila pri , bom odgovoril na to vprašanje. Video različica poročila je na voljo na .
Splošno znane zbirke podatkov 2020
Leto 2020 je, pogledal sem naokoli in videl tri vrste baz podatkov.
Prva vrsta - klasične baze podatkov OLTP: PostgreSQL, SQL Server, Oracle, MySQL. Napisani so bili že zdavnaj, vendar so še vedno pomembni, ker so tako znani skupnosti razvijalcev.
Druga vrsta je baze iz "nule". Od klasičnih vzorcev so se poskušali odmakniti z opustitvijo SQL, tradicionalnih struktur in ACID-a, z dodajanjem vgrajenega razdeljevanja in drugih privlačnih funkcij. Na primer, to je Cassandra, MongoDB, Redis ali Tarantool. Vse te rešitve so želele trgu ponuditi nekaj bistveno novega in so zasedle svojo nišo, saj so se izkazale za izjemno priročne za določena opravila. Te podatkovne baze bom označil s krovnim izrazom NOSQL.
»Ničle« so mimo, navadili smo se na baze podatkov NOSQL in svet je z mojega vidika naredil naslednji korak - upravljane baze podatkov. Te baze podatkov imajo enako jedro kot klasične baze podatkov OLTP ali nove baze podatkov NoSQL. Vendar ne potrebujejo DBA in DevOps in delujejo na upravljani strojni opremi v oblaku. Za razvijalca je to “samo baza”, ki nekje deluje, a nikogar ne zanima, kako je nameščena na strežniku, kdo je konfiguriral strežnik in kdo ga posodablja.
Primeri takih baz podatkov:
- AWS RDS je upravljani ovoj za PostgreSQL/MySQL.
- DynamoDB je AWS analog baze podatkov, ki temelji na dokumentih, podobno kot Redis in MongoDB.
- Amazon Redshift je upravljana analitična zbirka podatkov.
To so v bistvu stare baze podatkov, vendar vzgojene v upravljanem okolju, brez potrebe po delu s strojno opremo.
Opomba. Primeri so vzeti za okolje AWS, vendar njihovi analogi obstajajo tudi v Microsoft Azure, Google Cloud ali Yandex.Cloud.
Kaj je novega na tem? Leta 2020 nič od tega.
Koncept brez strežnika
Kar je resnično novo na trgu leta 2020, so rešitve brez strežnika ali brez strežnika.
Kaj to pomeni, bom poskušal razložiti na primeru običajne storitve ali zaledne aplikacije.
Za uvedbo običajne zaledne aplikacije kupimo ali najamemo strežnik, vanj kopiramo kodo, objavimo končno točko zunaj in redno plačujemo najemnino, elektriko in storitve podatkovnega centra. To je standardna shema.
Obstaja še kakšna pot? S storitvami brez strežnika lahko.
Kaj je fokus tega pristopa: ni strežnika, ni niti najema virtualne instance v oblaku. Če želite uvesti storitev, kopirajte kodo (funkcije) v repozitorij in jo objavite na končni točki. Nato preprosto plačamo za vsak klic te funkcije, popolnoma ignoriramo strojno opremo, kjer se izvaja.
Ta pristop bom poskušal ponazoriti s slikami.
Klasična uvedba. Imamo storitev z določeno obremenitvijo. Vzpostavimo dve instanci: fizične strežnike ali instance v AWS. Zunanje zahteve so poslane na te instance in tam obdelane.
Kot lahko vidite na sliki, strežniki niso razporejeni enakomerno. Ena je 100% izkoriščena, dve zahtevi sta, ena pa je le 50% - delno neaktivna. Če ne pridejo tri zahteve, ampak 30, potem celoten sistem ne bo mogel obvladati obremenitve in se bo začel upočasnjevati.
Namestitev brez strežnika. V brezstrežniškem okolju taka storitev nima primerkov ali strežnikov. Obstaja določena zbirka ogrevanih virov - majhni pripravljeni vsebniki Docker z razporejeno funkcijsko kodo. Sistem prejme zunanje zahteve in za vsako od njih ogrodje brez strežnika dvigne majhen vsebnik s kodo: obdela to posebno zahtevo in ubije vsebnik.
Ena zahteva - en dvignjen kontejner, 1000 zahtev - 1000 kontejnerjev. In postavitev na strežnikih strojne opreme je že delo ponudnika oblaka. Brezstrežniško ogrodje ga popolnoma skriva. V tem konceptu plačamo za vsak klic. Na primer, en klic je prišel na dan - plačali smo en klic, milijon je prišlo na minuto - plačali smo milijon. Ali pa se v sekundi zgodi tudi to.
Koncept objave funkcije brez strežnika je primeren za storitev brez stanja. In če potrebujete (državno) storitev s polnim stanjem, potem storitvi dodamo bazo podatkov. V tem primeru, ko gre za delo s stanjem, vsaka funkcija s polnim stanjem preprosto piše in bere iz baze podatkov. Poleg tega iz baze podatkov katere koli od treh vrst, opisanih na začetku članka.
Kaj je skupna omejitev vseh teh baz podatkov? To so stroški stalno uporabljenega oblaka ali strežnika strojne opreme (ali več strežnikov). Ne glede na to, ali uporabljamo klasično ali upravljano bazo, ali imamo Devops in admina ali ne, še vedno plačujemo strojno opremo, elektriko in najem podatkovnega centra 24/7. Če imamo klasično bazo, plačamo master in slave. Če gre za zelo obremenjeno razdrobljeno bazo podatkov, plačamo 10, 20 ali 30 strežnikov in to nenehno.
Prisotnost stalno rezerviranih strežnikov v strukturi stroškov je bila prej pojmovana kot nujno zlo. Konvencionalne baze podatkov imajo tudi druge težave, kot so omejitve števila povezav, omejitve skaliranja, geografsko porazdeljeno soglasje - v določenih bazah jih je mogoče nekako rešiti, vendar ne vse naenkrat in ne idealno.
Brezstrežniška baza podatkov - teorija
Vprašanje leta 2020: ali je mogoče narediti tudi bazo podatkov brez strežnika? Vsi so že slišali za zaledje brez strežnikov ... poskusimo bazo podatkov narediti brez strežnika?
To se sliši nenavadno, saj je baza podatkov storitev s polnim stanjem, ki ni zelo primerna za infrastrukturo brez strežnika. Hkrati je stanje podatkovne baze zelo veliko: gigabajti, terabajti, v analitičnih bazah celo petabajti. Vzgojiti ga v lahkih Docker posodah ni tako enostavno.
Po drugi strani pa skoraj vse sodobne baze podatkov vsebujejo ogromno logike in komponent: transakcije, koordinacijo integritete, procedure, relacijske odvisnosti in veliko logike. Za precej veliko logike baze podatkov je dovolj majhno stanje. Gigabajte in terabajte neposredno uporablja le majhen del logike baze podatkov, ki sodeluje pri neposrednem izvajanju poizvedb.
V skladu s tem je ideja: če del logike dovoljuje izvajanje brez stanja, zakaj ne bi baze razdelili na dela z stanjem in brez stanja.
Brez strežnika za rešitve OLAP
Oglejmo si, kako lahko izgleda razrez baze podatkov na dele Stateful in Stateless na praktičnih primerih.
Na primer, imamo analitično bazo podatkov: zunanji podatki (rdeči valj na levi), proces ETL, ki nalaga podatke v bazo podatkov, in analitik, ki v bazo pošilja SQL poizvedbe. To je klasična shema delovanja podatkovnega skladišča.
V tej shemi se ETL pogojno izvede enkrat. Potem morate nenehno plačevati za strežnike, na katerih teče baza podatkov s podatki, napolnjenimi z ETL, tako da je nekaj za pošiljanje poizvedb.
Oglejmo si alternativni pristop, implementiran v AWS Athena Serverless. Ni trajno namenske strojne opreme, na kateri bi bili shranjeni preneseni podatki. Namesto tega:
- Uporabnik Atheni pošlje poizvedbo SQL. Optimizator Athena analizira poizvedbo SQL in v shrambi metapodatkov (Metapodatki) poišče specifične podatke, potrebne za izvedbo poizvedbe.
- Optimizator na podlagi zbranih podatkov prenese potrebne podatke iz zunanjih virov v začasno shrambo (začasna baza).
- Poizvedba SQL uporabnika se izvede v začasni shrambi in rezultat se vrne uporabniku.
- Začasna shramba je počiščena in viri so sproščeni.
V tej arhitekturi plačamo samo postopek izvedbe zahteve. Brez zahtev - brez stroškov.
To je delujoč pristop in se izvaja ne le v Athena Serverless, ampak tudi v Redshift Spectrum (v AWS).
Primer Athena kaže, da baza podatkov Serverless deluje na resničnih poizvedbah z desetinami in stotinami terabajtov podatkov. Na stotine terabajtov bo zahtevalo na stotine strežnikov, vendar nam zanje ni treba plačati – plačamo za zahteve. Hitrost vsake zahteve je (zelo) nizka v primerjavi s specializiranimi analitičnimi zbirkami podatkov, kot je Vertica, vendar ne plačujemo obdobij izpadov.
Takšna zbirka podatkov je uporabna za redke analitične ad hoc poizvedbe. Na primer, ko se spontano odločimo preizkusiti hipotezo na neki ogromni količini podatkov. Athena je kot nalašč za te primere. Za redne zahteve je tak sistem drag. V tem primeru predpomnite podatke v kakšni specializirani rešitvi.
Brez strežnika za rešitve OLTP
Prejšnji primer je obravnaval (analitične) naloge OLAP. Zdaj pa si poglejmo naloge OLTP.
Predstavljajmo si razširljiv PostgreSQL ali MySQL. Vzpostavimo običajni upravljani primerek PostgreSQL ali MySQL z minimalnimi viri. Ko bo instanca bolj obremenjena, bomo povezali dodatne replike, na katere bomo porazdelili del bralne obremenitve. Če ni zahtev ali nalaganja, izklopimo replike. Prvi primerek je master, ostali pa so replike.
Ta zamisel je implementirana v bazi podatkov, imenovani Aurora Serverless AWS. Načelo je preprosto: proxy flota sprejema zahteve iz zunanjih aplikacij. Ko opazi povečanje obremenitve, dodeli računalniške vire iz predhodno ogretih minimalnih primerkov - povezava se vzpostavi čim hitreje. Onemogočanje primerkov se zgodi na enak način.
Znotraj Aurore obstaja koncept Aurora Capacity Unit, ACU. To je (pogojno) instanca (strežnik). Vsak poseben ACU je lahko glavni ali podrejeni. Vsaka zmogljivostna enota ima svoj RAM, procesor in minimalni disk. V skladu s tem je eden mojster, ostali so samo berljive replike.
Število teh enot Aurora Capacity, ki delujejo, je nastavljiv parameter. Najmanjša količina je lahko ena ali nič (v tem primeru baza ne deluje, če ni zahtev).
Ko baza prejme zahteve, proxy flota dvigne Aurora CapacityUnits, s čimer se povečajo viri zmogljivosti sistema. Zmožnost povečevanja in zmanjševanja virov omogoča sistemu, da "žonglira" z viri: samodejno prikaže posamezne enote ACU (jih nadomesti z novimi) in uvede vse trenutne posodobitve za umaknjene vire.
Brezstrežniška baza Aurora lahko poveča bralno obremenitev. Toda dokumentacija tega ne pove neposredno. Morda se zdi, kot da lahko dvignejo več mojstrov. Ni čarovnije.
Ta zbirka podatkov je zelo primerna, da se izognete porabi ogromnih količin denarja za sisteme z nepredvidljivim dostopom. Na primer, ko ustvarjamo MVP ali tržimo spletna mesta z vizitkami, običajno ne pričakujemo stabilne obremenitve. V skladu s tem, če ni dostopa, ne plačamo primerkov. Ko pride do nepričakovane obremenitve, na primer po konferenci ali oglaševalski kampanji, množica ljudi obišče stran in se obremenitev dramatično poveča, Aurora Serverless samodejno prevzame to obremenitev in hitro poveže manjkajoče vire (ACU). Potem konferenca mine, vsi pozabijo na prototip, strežniki (ACU) zatemnijo in stroški padejo na nič - ugodno.
Ta rešitev ni primerna za stabilno visoko obremenitev, ker ne prilagaja pisalne obremenitve. Vse te povezave in prekinitve povezav virov se zgodijo na tako imenovani "točki lestvice" - točki v času, ko zbirka podatkov ni podprta s transakcijo ali začasnimi tabelami. Na primer, v enem tednu se lahko točka lestvice ne zgodi, baza pa deluje na istih virih in se preprosto ne more razširiti ali skrčiti.
Ni čarovnije - to je navaden PostgreSQL. Toda postopek dodajanja strojev in njihovega odklopa je delno avtomatiziran.
Zasnova brez strežnika
Aurora Serverless je stara zbirka podatkov, ki je bila na novo napisana za oblak, da bi izkoristila nekatere prednosti brezstrežniškega strežnika. In zdaj vam bom povedal o osnovi, ki je bila prvotno napisana za oblak, za pristop brez strežnika - Serverless-by-design. Takoj so ga razvili brez predpostavke, da bo deloval na fizičnih strežnikih.
Ta osnova se imenuje Snowflake. Ima tri ključne bloke.
Prvi je blok metapodatkov. To je hitra storitev v pomnilniku, ki rešuje težave z varnostjo, metapodatki, transakcijami in optimizacijo poizvedb (prikazano na sliki na levi).
Drugi blok je nabor virtualnih računalniških gruč za izračune (na sliki je nabor modrih krogov).
Tretji blok je sistem za shranjevanje podatkov, ki temelji na S3. S3 je brezdimenzionalno shranjevanje objektov v AWS, nekako kot brezdimenzijski Dropbox za podjetja.
Poglejmo, kako deluje Snowflake ob predpostavki hladnega zagona. To pomeni, da obstaja baza podatkov, podatki se naložijo vanjo, ni tekočih poizvedb. V skladu s tem, če ni zahtev za bazo podatkov, smo dvignili hitro storitev metapodatkov v pomnilniku (prvi blok). In imamo shrambo S3, kjer so shranjeni podatki tabel, razdeljeni na tako imenovane mikroparticije. Za poenostavitev: če tabela vsebuje transakcije, so mikroparticije dnevi transakcij. Vsak dan je ločena mikroparticija, ločena datoteka. In ko baza podatkov deluje v tem načinu, plačate samo za prostor, ki ga zasedajo podatki. Poleg tega je stopnja na sedež zelo nizka (zlasti ob upoštevanju znatne kompresije). Metapodatkovna storitev prav tako deluje nenehno, vendar za optimizacijo poizvedb ne potrebujete veliko virov, storitev pa lahko štejemo za skupno programsko opremo.
Zdaj pa si predstavljajmo, da je uporabnik prišel do naše baze podatkov in poslal poizvedbo SQL. Poizvedba SQL se takoj pošlje v obdelavo storitvi Metadata. V skladu s tem ta storitev ob prejemu zahteve analizira zahtevo, razpoložljive podatke, uporabniška dovoljenja in, če je vse v redu, sestavi načrt obdelave zahteve.
Nato storitev sproži zagon računalniške gruče. Računalniška gruča je gruča strežnikov, ki izvajajo izračune. Se pravi, to je gruča, ki lahko vsebuje 1 strežnik, 2 strežnika, 4, 8, 16, 32 - kolikor želite. Vržete zahtevo in takoj se začne zagon te gruče. Res traja nekaj sekund.
Nato se po zagonu gruče mikroparticije, potrebne za obdelavo vaše zahteve, začnejo kopirati v gručo iz S3. To pomeni, da si predstavljamo, da za izvedbo poizvedbe SQL potrebujete dve particiji iz ene tabele in eno iz druge tabele. V tem primeru bodo v gručo kopirane le tri potrebne particije in ne vse tabele v celoti. Zato in prav zato, ker se vse nahaja v enem podatkovnem centru in je povezano z zelo hitrimi kanali, se celoten proces prenosa zgodi zelo hitro: v sekundah, zelo redko v minutah, razen če ne govorimo o kakšnih pošastnih zahtevah. V skladu s tem se mikroparticije prekopirajo v računalniško gručo in po zaključku se na tej računalniški gruči izvede poizvedba SQL. Rezultat te zahteve je lahko ena vrstica, več vrstic ali tabela – uporabniku se pošljejo navzven, da jo lahko prenese, prikaže v svojem BI orodju ali kako drugače uporabi.
Vsaka poizvedba SQL ne more samo prebrati agregatov iz predhodno naloženih podatkov, ampak tudi naložiti/generirati nove podatke v bazi podatkov. To pomeni, da je lahko poizvedba, ki na primer vstavi nove zapise v drugo tabelo, kar vodi do pojava nove particije v računalniški gruči, ki se nato samodejno shrani v eno samo shrambo S3.
Zgoraj opisani scenarij od prihoda uporabnika do dviga gruče, nalaganja podatkov, izvajanja poizvedb, pridobivanja rezultatov se plača po tarifi za minute uporabe dvignjenega virtualnega računalniškega grozda, virtualnega skladišča. Stopnja se razlikuje glede na območje AWS in velikost gruče, vendar je v povprečju nekaj dolarjev na uro. Grozd štirih strojev je dvakrat dražji od grozda dveh strojev, grozd osmih strojev pa je še vedno dvakrat dražji. Na voljo so možnosti 16, 32 strojev, odvisno od kompleksnosti zahtev. Plačaš pa le tiste minute, ko gruča dejansko teče, ker ko ni zahtev, nekako odmakneš roke in po 5-10 minutah čakanja (nastavljiv parameter) se ugasne sam, sprostite vire in postanite svobodni.
Popolnoma realen scenarij je, ko pošlješ zahtevo, se grozd pojavi, relativno gledano v minuti, šteje še minuto, nato pet minut, da se ugasne, na koncu plačaš sedem minut delovanja tega grozda in ne mesece in leta.
Prvi scenarij opisuje uporabo Snowflake v nastavitvi za enega uporabnika. Zdaj pa si predstavljajmo, da je uporabnikov veliko, kar je bližje realnemu scenariju.
Recimo, da imamo veliko analitikov in poročil Tableau, ki nenehno bombardirajo našo bazo podatkov z velikim številom preprostih analitičnih poizvedb SQL.
Poleg tega recimo, da imamo inventivne podatkovne znanstvenike, ki poskušajo s podatki narediti pošastne stvari, operirajo z desetinami terabajtov, analizirajo milijarde in trilijone vrstic podatkov.
Za zgoraj opisani dve vrsti delovne obremenitve vam Snowflake omogoča dvig več neodvisnih računalniških gruč različnih zmogljivosti. Poleg tega ti računalniški grozdi delujejo neodvisno, vendar s skupnimi doslednimi podatki.
Za veliko število lahkih poizvedb lahko ustvarite 2-3 majhne gruče, vsaka približno 2 stroja. To vedenje je mogoče izvajati med drugim z uporabo samodejnih nastavitev. Torej rečeš: »Snežinka, dvigni majhen grozd. Če se obremenitev na njem poveča nad določen parameter, dvignite podoben drugi, tretji. Ko obremenitev začne popuščati, pogasi presežek.” Tako, da ne glede na to, koliko analitikov pride in začne gledati poročila, imajo vsi dovolj sredstev.
Hkrati, če analitiki spijo in nihče ne pogleda poročil, lahko grozdi popolnoma zatemnijo in nehate plačevati zanje.
Hkrati lahko za težke poizvedbe (od Data Scientists) ustvarite eno zelo veliko gručo za 32 strojev. Tudi ta grozd bo plačan samo za tiste minute in ure, ko se tam izvaja vaša velikanska zahteva.
Zgoraj opisana priložnost omogoča razdelitev ne samo 2, ampak tudi več vrst delovnih obremenitev v grozde (ETL, spremljanje, materializacija poročil,...).
Povzemimo Snežinko. Osnova združuje lepo idejo in uporabno izvedbo. Pri ManyChat uporabljamo Snowflake za analizo vseh podatkov, ki jih imamo. Nimamo treh grozdov, kot v primeru, ampak od 5 do 9, različnih velikosti. Za nekatere naloge imamo običajne 16-strojne, 2-strojne in tudi super-majhne 1-strojne. Uspešno porazdelijo obremenitev in nam omogočajo, da veliko prihranimo.
Baza podatkov uspešno prilagaja obremenitev branja in pisanja. To je velika razlika in velik preboj v primerjavi z isto "Auroro", ki je nosila le obremenitev branja. Snowflake vam omogoča, da s temi računalniškimi gručami povečate pisalno obremenitev. Se pravi, kot sem že omenil, v ManyChatu uporabljamo več gruč, majhni in super-majhni grozdi se uporabljajo predvsem za ETL, za nalaganje podatkov. In analitiki že živijo na srednjih grozdih, na katere obremenitev ETL absolutno ne vpliva, zato delujejo zelo hitro.
V skladu s tem je baza podatkov zelo primerna za naloge OLAP. Vendar na žalost še ni uporabna za delovne obremenitve OLTP. Prvič, ta zbirka podatkov je stolpična z vsemi posledičnimi posledicami. Drugič, sam pristop, ko za vsako zahtevo, če je treba, dvigneš računalniško gručo in jo zasipaš s podatki, žal še ni dovolj hiter za nalaganja OLTP. Čakalne sekunde za opravila OLAP so običajne, za opravila OLTP pa nesprejemljive; bolje bi bilo 100 ms ali še bolje 10 ms.
Skupaj
Podatkovna baza brez strežnika je možna z razdelitvijo baze podatkov na dela brez stanja in stanja. Morda ste opazili, da v vseh zgornjih primerih del Stateful relativno gledano shranjuje mikro particije v S3, Stateless pa je optimizator, ki dela z metapodatki in obravnava varnostna vprašanja, ki jih je mogoče izpostaviti kot neodvisne lahke storitve Stateless.
Izvajanje poizvedb SQL je mogoče zaznati tudi kot storitve lahkega stanja, ki se lahko pojavijo v brezstrežniškem načinu, kot so računalniške gruče Snowflake, prenesejo samo potrebne podatke, izvedejo poizvedbo in "odidejo".
Baze podatkov na produkcijski ravni brez strežnika so že na voljo za uporabo, delujejo. Te baze podatkov brez strežnika so že pripravljene za obdelavo nalog OLAP. Na žalost se za naloge OLTP uporabljajo ... z niansami, saj obstajajo omejitve. Po eni strani je to minus. A po drugi strani je to priložnost. Morda bo kdo od bralcev našel način, kako bazo podatkov OLTP narediti popolnoma brezstrežniško, brez omejitev Aurore.
Upam, da vam je bilo zanimivo. Brez strežnika je prihodnost :)
Vir: www.habr.com