Zdravo svima! Moje ime je Golov Nikolay. Prethodno sam radio u Avitu i šest godina upravljao Data Platformom, odnosno radio sam na svim bazama podataka: analitičkim (Vertica, ClickHouse), streaming i OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Za to vrijeme bavio sam se velikim brojem baza podataka – vrlo različitim i neobičnim, te nestandardnim slučajevima njihovog korištenja.
Trenutno radim u ManyChat-u. U suštini, ovo je startup - nov, ambiciozan i brzo rastući. I kada sam se tek pridružio kompaniji, postavilo se klasično pitanje: „Šta bi mladi startup sada trebao uzeti od tržišta DBMS-a i baza podataka?”
U ovom članku, na osnovu mog izvještaja na , ja ću odgovoriti na ovo pitanje. Video verzija izvještaja dostupna je na .
Općepoznate baze podataka 2020
2020. je, pogledao sam okolo i vidio tri vrste baza podataka.
Prvi tip - klasične OLTP baze podataka: PostgreSQL, SQL Server, Oracle, MySQL. Napisane su davno, ali su još uvijek relevantne jer su toliko poznate zajednici programera.
Drugi tip je baze od "nule". Pokušali su da se odmaknu od klasičnih obrazaca napuštanjem SQL-a, tradicionalnih struktura i ACID-a, dodavanjem ugrađenog šardiranja i drugih atraktivnih karakteristika. Na primjer, ovo je Cassandra, MongoDB, Redis ili Tarantool. Sva ova rješenja željela su tržištu ponuditi nešto suštinski novo i zauzela su svoju nišu jer su se pokazala izuzetno pogodnim za određene zadatke. Ove baze podataka ću označiti krovnim terminom NOSQL.
“Nule” su gotove, navikli smo na NOSQL baze podataka, a svijet je, s moje tačke gledišta, napravio sljedeći korak - da upravljane baze podataka. Ove baze podataka imaju istu jezgru kao klasične OLTP baze podataka ili nove NoSQL. Ali nemaju potrebu za DBA i DevOps-om i rade na upravljanom hardveru u oblacima. Za programera je ovo „samo baza“ koja negdje radi, ali nikoga nije briga kako je instalirana na serveru, ko je konfigurirao server i ko ga ažurira.
Primjeri takvih baza podataka:
- AWS RDS je upravljani omotač za PostgreSQL/MySQL.
- DynamoDB je AWS analog baze podataka zasnovane na dokumentima, sličan Redis i MongoDB.
- Amazon Redshift je upravljana analitička baza podataka.
To su u osnovi stare baze podataka, ali podignute u upravljanom okruženju, bez potrebe za radom sa hardverom.
Bilješka. Primeri su uzeti za AWS okruženje, ali njihovi analozi postoje i u Microsoft Azure, Google Cloud ili Yandex.Cloud.
Šta ima novo u vezi ovoga? 2020. ništa od ovoga.
Koncept bez servera
Ono što je zaista novo na tržištu u 2020. su rješenja bez servera ili bez servera.
Pokušat ću objasniti što to znači na primjeru obične servisne ili pozadinske aplikacije.
Da bismo implementirali redovnu backend aplikaciju, kupujemo ili iznajmljujemo server, kopiramo kod na njega, objavljujemo krajnju tačku van i redovno plaćamo najam, struju i usluge data centra. Ovo je standardna šema.
Postoji li neki drugi način? Sa uslugama bez servera možete.
Šta je fokus ovog pristupa: nema servera, nema čak ni iznajmljivanja virtuelne instance u oblaku. Da biste implementirali uslugu, kopirajte kod (funkcije) u spremište i objavite ga na krajnjoj tački. Zatim jednostavno plaćamo svaki poziv ovoj funkciji, potpuno zanemarujući hardver na kojem se izvršava.
Pokušaću da ilustrujem ovaj pristup slikama.
Klasična implementacija. Imamo servis sa određenim opterećenjem. Podižemo dvije instance: fizičke servere ili instance u AWS-u. Eksterni zahtjevi se šalju ovim instancama i tamo obrađuju.
Kao što možete vidjeti na slici, serveri se ne raspolažu jednako. Jedan je 100% iskorišten, postoje dva zahtjeva, a jedan je samo 50% - djelimično neaktivan. Ako ne stignu tri zahtjeva, već 30, onda cijeli sistem neće moći da se nosi sa opterećenjem i počeće da usporava.
Implementacija bez servera. U okruženju bez servera, takva usluga nema instance ili servere. Postoji određeni bazen zagrijanih resursa - mali pripremljeni Docker kontejneri sa raspoređenim kodom funkcije. Sistem prima eksterne zahteve i za svaki od njih okvir bez servera podiže mali kontejner sa kodom: obrađuje ovaj zahtev i ubija kontejner.
Jedan zahtjev - jedan kontejner podignut, 1000 zahtjeva - 1000 kontejnera. A implementacija na hardverske servere je već posao provajdera u oblaku. Potpuno je skriven okvirom bez servera. U ovom konceptu plaćamo svaki poziv. Recimo, jedan poziv je došao dnevno – platili smo jedan poziv, milion je došao u minuti – platili smo milion. Ili se u sekundi i ovo dešava.
Koncept objavljivanja funkcije bez servera je prikladan za uslugu bez stanja. A ako vam je potrebna (stanje) usluga puna stanja, tada servisu dodajemo bazu podataka. U ovom slučaju, kada je u pitanju rad sa stanjem, svaka funkcija puna stanja jednostavno piše i čita iz baze podataka. Štaviše, iz baze podataka bilo koje od tri vrste opisane na početku članka.
Koje je zajedničko ograničenje svih ovih baza podataka? Ovo su troškovi stalno korišćenog cloud ili hardverskog servera (ili nekoliko servera). Nije bitno da li koristimo klasičnu ili upravljanu bazu podataka, da li imamo Devops i administratora ili ne, i dalje plaćamo hardver, struju i najam data centra 24/7. Ako imamo klasičnu bazu, plaćamo za master i slave. Ako se radi o visoko opterećenoj podijeljenoj bazi podataka, plaćamo 10, 20 ili 30 servera i plaćamo stalno.
Prisustvo trajno rezervisanih servera u strukturi troškova ranije se doživljavalo kao nužno zlo. Konvencionalne baze podataka imaju i druge poteškoće, kao što su ograničenja u broju konekcija, ograničenja skaliranja, geo-distribuirani konsenzus - oni se nekako mogu riješiti u određenim bazama podataka, ali ne sve odjednom i ne idealno.
Baza podataka bez servera - teorija
Pitanje 2020: da li je moguće napraviti i bazu podataka bez servera? Svi su čuli za backend bez servera... hajde da pokušamo da bazu podataka napravimo bez servera?
Ovo zvuči čudno, jer je baza podataka usluga pune stanja, nije baš pogodna za infrastrukturu bez servera. Istovremeno, stanje baze podataka je vrlo veliko: gigabajti, terabajti, au analitičkim bazama čak i petabajti. Nije ga tako lako odgajati u laganim Docker kontejnerima.
S druge strane, gotovo sve moderne baze podataka sadrže ogromnu količinu logike i komponenti: transakcije, koordinaciju integriteta, procedure, relacijske zavisnosti i puno logike. Za dosta logike baze podataka, dovoljno je malo stanje. Gigabajte i terabajte direktno koristi samo mali dio logike baze podataka koji je uključen u direktno izvršavanje upita.
Shodno tome, ideja je: ako dio logike dozvoljava izvršavanje bez stanja, zašto ne podijeliti bazu na dijelove sa stanjem i bez stanja.
Bez servera za OLAP rješenja
Pogledajmo kako bi rezanje baze podataka na dijelove sa stanjem i bez stanja moglo izgledati koristeći praktične primjere.
Na primjer, imamo analitičku bazu podataka: vanjski podaci (crveni cilindar lijevo), ETL proces koji učitava podatke u bazu podataka i analitičar koji šalje SQL upite bazi podataka. Ovo je klasična šema rada skladišta podataka.
U ovoj šemi, ETL se uslovno izvodi jednom. Zatim morate stalno plaćati servere na kojima radi baza podataka sa ETL-om popunjenim, kako bi imalo čemu slati upite.
Pogledajmo alternativni pristup implementiran u AWS Athena Serverless. Ne postoji trajno namjenski hardver na kojem se pohranjuju preuzeti podaci. umjesto ovoga:
- Korisnik Ateni šalje SQL upit. Athena optimizator analizira SQL upit i pretražuje skladište metapodataka (Metadata) za specifične podatke potrebne za izvršavanje upita.
- Optimizator, na osnovu prikupljenih podataka, preuzima potrebne podatke iz eksternih izvora u privremenu memoriju (privremenu bazu podataka).
- SQL upit od korisnika se izvršava u privremenoj memoriji i rezultat se vraća korisniku.
- Privremena pohrana se briše i resursi se oslobađaju.
U ovoj arhitekturi plaćamo samo proces izvršenja zahtjeva. Nema zahtjeva - nema troškova.
Ovo je radni pristup i implementiran je ne samo u Athena Serverless, već iu Redshift Spectrum (u AWS).
Primer Athene pokazuje da baza podataka bez servera radi na stvarnim upitima sa desetinama i stotinama terabajta podataka. Stotine terabajta će zahtijevati stotine servera, ali mi ne moramo platiti za njih - mi plaćamo zahtjeve. Brzina svakog zahtjeva je (vrlo) mala u odnosu na specijalizirane analitičke baze podataka kao što je Vertica, ali ne plaćamo zastoje.
Takva baza podataka je primjenjiva za rijetke analitičke ad-hoc upite. Na primjer, kada spontano odlučimo testirati hipotezu na nekoj gigantskoj količini podataka. Athena je savršena za ove slučajeve. Za redovne zahtjeve takav sistem je skup. U ovom slučaju, keširajte podatke u nekom specijaliziranom rješenju.
Bez servera za OLTP rješenja
Prethodni primjer je razmatrao OLAP (analitičke) zadatke. Pogledajmo sada OLTP zadatke.
Zamislimo skalabilni PostgreSQL ili MySQL. Hajde da podignemo regularnu upravljanu instancu PostgreSQL ili MySQL sa minimalnim resursima. Kada instanca primi više opterećenja, spojit ćemo dodatne replike na koje ćemo rasporediti dio opterećenja čitanja. Ako nema zahtjeva ili učitavanja, isključujemo replike. Prva instanca je master, a ostalo su replike.
Ova ideja je implementirana u bazi podataka pod nazivom Aurora Serverless AWS. Princip je jednostavan: zahtjeve iz vanjskih aplikacija prihvaća flota proksija. Vidjevši povećanje opterećenja, alocira računarske resurse iz prethodno zagrijanih minimalnih instanci - veza se ostvaruje što je brže moguće. Onemogućavanje instanci se događa na isti način.
Unutar Aurore postoji koncept Aurora Capacity Unit, ACU. Ovo je (uslovno) instanca (server). Svaki određeni ACU može biti glavni ili slave. Svaka jedinica kapaciteta ima svoju RAM memoriju, procesor i minimalni disk. Prema tome, jedan je master, ostali su replike samo za čitanje.
Broj ovih jedinica Aurora kapaciteta koje rade je parametar koji se može konfigurirati. Minimalna količina može biti jedan ili nula (u ovom slučaju baza podataka ne radi ako nema zahtjeva).
Kada baza primi zahtjeve, proxy flota podiže Aurora CapacityUnits, povećavajući resurse performansi sistema. Mogućnost povećanja i smanjenja resursa omogućava sistemu da „žonglira“ resursima: automatski prikazuje pojedinačne ACU-ove (zamjenjujući ih novima) i uvodi sva trenutna ažuriranja povučenih resursa.
Aurora baza bez servera može skalirati opterećenje čitanja. Ali dokumentacija to ne govori direktno. Može se osjećati kao da mogu podići multi-master. Nema magije.
Ova baza podataka je vrlo pogodna za izbjegavanje trošenja ogromne količine novca na sisteme s nepredvidivim pristupom. Na primjer, kada kreiramo MVP ili marketinške stranice sa vizit kartama, obično ne očekujemo stabilno opterećenje. Shodno tome, ako nema pristupa, ne plaćamo instance. Kada dođe do neočekivanog opterećenja, na primjer nakon konferencije ili reklamne kampanje, gomile ljudi posjećuju stranicu i opterećenje se dramatično povećava, Aurora Serverless automatski preuzima ovo opterećenje i brzo povezuje nedostajuće resurse (ACU). Onda konferencija prođe, svi zaborave na prototip, serveri (ACU) zamrače, a troškovi padaju na nulu - zgodno.
Ovo rješenje nije prikladno za stabilno visoko opterećenje jer ne povećava opterećenje pisanja. Sva ova povezivanja i isključenja resursa se dešavaju u takozvanoj „tački skale“ – trenutku kada baza podataka nije podržana transakcijom ili privremenim tabelama. Na primjer, u roku od nedelju dana tačka na skali se možda neće dogoditi, a baza radi na istim resursima i jednostavno se ne može proširiti ili skupiti.
Nema magije - to je običan PostgreSQL. Ali proces dodavanja mašina i njihovog isključivanja je delimično automatizovan.
Bez servera po dizajnu
Aurora bez servera je stara baza podataka prepisana za oblak kako bi se iskoristile neke od prednosti bez servera. A sada ću vam reći o bazi, koja je prvobitno napisana za oblak, za pristup bez servera - Serverless-by-Design. Odmah je razvijen bez pretpostavke da će raditi na fizičkim serverima.
Ova baza se zove Pahuljica. Ima tri ključna bloka.
Prvi je blok metapodataka. Ovo je brza usluga u memoriji koja rješava probleme sa sigurnošću, metapodacima, transakcijama i optimizacijom upita (prikazano na ilustraciji lijevo).
Drugi blok je skup virtuelnih računarskih klastera za proračune (na ilustraciji je skup plavih krugova).
Treći blok je sistem za skladištenje podataka baziran na S3. S3 je bezdimenzionalno skladištenje objekata u AWS-u, nešto poput Dropboxa bez dimenzija za posao.
Hajde da vidimo kako radi Snowflake, pod pretpostavkom hladnog starta. To jest, postoji baza podataka, podaci se učitavaju u nju, nema pokrenutih upita. Shodno tome, ako nema zahtjeva prema bazi podataka, tada smo podigli brzi servis metapodataka u memoriji (prvi blok). I imamo S3 skladište, gdje se pohranjuju podaci tablice, podijeljeni na takozvane mikroparticije. Radi jednostavnosti: ako tabela sadrži transakcije, mikroparticije su dani transakcija. Svaki dan je posebna mikroparticija, zaseban fajl. A kada baza podataka radi u ovom režimu, plaćate samo za prostor koji podaci zauzimaju. Štaviše, stopa po sjedištu je vrlo niska (posebno uzimajući u obzir značajnu kompresiju). Usluga metapodataka također radi konstantno, ali vam ne treba puno resursa za optimizaciju upita, a usluga se može smatrati shareware-om.
Sada zamislimo da je korisnik došao u našu bazu podataka i poslao SQL upit. SQL upit se odmah šalje servisu Metapodataka na obradu. Shodno tome, po prijemu zahtjeva, ovaj servis analizira zahtjev, dostupne podatke, korisničke dozvole i, ako je sve u redu, izrađuje plan obrade zahtjeva.
Zatim servis pokreće pokretanje računarskog klastera. Računarski klaster je klaster servera koji obavljaju proračune. To jest, ovo je klaster koji može sadržavati 1 server, 2 servera, 4, 8, 16, 32 - koliko god želite. Bacite zahtjev i pokretanje ovog klastera odmah počinje. Zaista traje nekoliko sekundi.
Zatim, nakon što se klaster pokrene, mikroparticije potrebne za obradu vašeg zahtjeva počinju se kopirati u klaster iz S3. To jest, zamislimo da su vam za izvršavanje SQL upita potrebne dvije particije iz jedne tablice i jedna iz druge. U ovom slučaju, samo tri potrebne particije će biti kopirane u klaster, a ne sve tablice u potpunosti. Zato, a upravo zato što se sve nalazi unutar jednog data centra i povezano je veoma brzim kanalima, ceo proces prenosa se odvija veoma brzo: u sekundi, vrlo retko u minutima, osim ako je reč o nekim monstruoznim zahtevima. U skladu s tim, mikroparticije se kopiraju u računarski klaster i, po završetku, SQL upit se izvršava na ovom računarskom klasteru. Rezultat ovog zahtjeva može biti jedan red, nekoliko redova ili tabela - oni se šalju eksterno korisniku kako bi ih mogao preuzeti, prikazati u svom BI alatu ili koristiti na neki drugi način.
Svaki SQL upit ne može samo čitati agregate iz prethodno učitanih podataka, već i učitavati/generirati nove podatke u bazi podataka. Odnosno, to može biti upit koji, na primjer, ubacuje nove zapise u drugu tabelu, što dovodi do pojave nove particije na računarskom klasteru, koja se zauzvrat automatski pohranjuje u jednu S3 memoriju.
Gore opisani scenario, od dolaska korisnika do podizanja klastera, učitavanja podataka, izvršavanja upita, dobijanja rezultata, plaća se po minuti korišćenja podignutog virtuelnog računarskog klastera, virtuelnog skladišta. Stopa varira u zavisnosti od AWS zone i veličine klastera, ali u prosjeku iznosi nekoliko dolara po satu. Grupa od četiri mašine je duplo skuplja od grupe od dve mašine, a grupa od osam mašina je još uvek duplo skuplja. Dostupne su opcije od 16, 32 mašine, u zavisnosti od složenosti zahteva. Ali plaćate samo one minute kada klaster stvarno radi, jer kada nema zahtjeva, nekako maknete ruke i nakon 5-10 minuta čekanja (podesivi parametar) on će se sam ugasiti, oslobodite resurse i postanite slobodni.
Potpuno realan scenario je kada pošaljete zahtev, klaster iskoči, relativno govoreći, za minut, broji još minut, pa pet minuta da se isključi i na kraju platite sedam minuta rada ovog klastera, i ne mesecima i godinama.
Prvi scenarij je opisan korištenjem Snowflake u postavci za jednog korisnika. Sada zamislimo da ima mnogo korisnika, što je bliže stvarnom scenariju.
Recimo da imamo puno analitičara i Tableau izvještaja koji konstantno bombardiraju našu bazu podataka velikim brojem jednostavnih analitičkih SQL upita.
Uz to, recimo da imamo inventivne Data Scientists koji pokušavaju da urade monstruozne stvari sa podacima, operišu sa desetinama terabajta, analiziraju milijarde i trilione redova podataka.
Za dvije gore opisane vrste opterećenja, Snowflake vam omogućava da podignete nekoliko nezavisnih računarskih klastera različitih kapaciteta. Štaviše, ovi računarski klasteri rade nezavisno, ali sa zajedničkim konzistentnim podacima.
Za veliki broj lakih upita možete podići 2-3 mala klastera, otprilike po 2 mašine. Ovo ponašanje se može implementirati, između ostalog, korištenjem automatskih postavki. Pa vi kažete: „Pahuljice, podigni mali grozd. Ako se opterećenje na njemu poveća iznad određenog parametra, podignite sličan drugi, treći. Kada opterećenje počne da opada, ugasite višak.” Tako da bez obzira koliko analitičara dođe i počne da gleda izvještaje, svi imaju dovoljno resursa.
U isto vrijeme, ako analitičari spavaju i niko ne gleda izvještaje, klasteri mogu potpuno zamračiti, a vi prestanete da ih plaćate.
Istovremeno, za teške upite (od Data Scientists), možete podići jedan veoma veliki klaster za 32 mašine. Ovaj klaster će također biti plaćen samo za one minute i sate kada tamo radi vaš veliki zahtjev.
Gore opisana prilika vam omogućava da podijelite ne samo 2, već i više vrsta opterećenja u klastere (ETL, praćenje, materijalizacija izvještaja,...).
Hajde da sumiramo Pahuljicu. Baza kombinuje prelepu ideju i izvodljivu implementaciju. U ManyChat-u koristimo Snowflake za analizu svih podataka koje imamo. Nemamo tri klastera, kao u primjeru, već od 5 do 9, različitih veličina. Imamo konvencionalne 16-mašine, 2-mašine, ali i super-male 1-mašine za neke zadatke. Oni uspješno raspoređuju opterećenje i omogućavaju nam da uštedimo mnogo.
Baza podataka uspješno skalira opterećenje čitanja i pisanja. Ovo je ogromna razlika i veliki napredak u poređenju sa istom „Aurorom“, koja je nosila samo opterećenje čitanja. Snowflake vam omogućava da povećate svoje radno opterećenje pisanja pomoću ovih računarskih klastera. Odnosno, kao što sam spomenuo, koristimo nekoliko klastera u ManyChat-u, mali i super-mali klasteri se uglavnom koriste za ETL, za učitavanje podataka. A analitičari već žive na srednjim klasterima, na koje ETL opterećenje apsolutno ne utiče, tako da rade vrlo brzo.
Shodno tome, baza podataka je vrlo pogodna za OLAP zadatke. Međutim, nažalost, još uvijek nije primjenjiv za OLTP radna opterećenja. Prvo, ova baza podataka je stupasta, sa svim posljedicama koje iz toga proizlaze. Drugo, sam pristup, kada za svaki zahtjev, ako je potrebno, podignete računski klaster i preplavite ga podacima, nažalost još uvijek nije dovoljno brz za OLTP opterećenja. Čekanje sekundi za OLAP zadatke je normalno, ali za OLTP zadatke je neprihvatljivo; 100 ms bi bilo bolje, ili 10 ms bi bilo još bolje.
Rezultat
Baza podataka bez servera je moguća podjelom baze podataka na dijelove bez stanja i bez stanja. Možda ste primijetili da je u svim gornjim primjerima Stateful dio, relativno govoreći, pohranjivanje mikro-particija u S3, a Stateless je optimizator, koji radi s metapodacima, rješavajući sigurnosna pitanja koja se mogu pokrenuti kao nezavisne lagane usluge bez državljanstva.
Izvršavanje SQL upita također se može smatrati uslugama svijetlog stanja koje mogu iskočiti u načinu rada bez servera, poput računalnih klastera Snowflake, preuzeti samo potrebne podatke, izvršiti upit i „izaći“.
Baze podataka nivoa proizvodnje bez servera su već dostupne za upotrebu, rade. Ove baze podataka bez servera su već spremne za rukovanje OLAP zadacima. Nažalost, za OLTP zadatke se koriste... sa nijansama, jer postoje ograničenja. S jedne strane, ovo je minus. Ali, s druge strane, ovo je prilika. Možda će neko od čitalaca pronaći način da OLTP bazu podataka učini potpuno bez servera, bez ograničenja Aurore.
Nadam se da vam je bilo zanimljivo. Budućnost je bez servera :)
izvor: www.habr.com