Za\u010dasna shramba se o\u010disti, viri se sprostijo.<\/li>\n<\/ul>\nV tej arhitekturi pla\u010damo le za postopek izvr\u0161itve poizvedbe. Ni poizvedb \u2013 ni stro\u0161kov.<\/p>\n
Na primeru Athene je razvidno, da Serverless baza podatkov deluje na realnih poizvedbah z desetinami in stotinami terabajtov podatkov. Za stotine terabajtov potrebujemo stotine stre\u017enikov, vendar za njih ne pla\u010damo \u2013 pla\u010damo za poizvedbe. Hitrost vsake poizvedbe je (zelo) nizka v primerjavi s specializiranimi analiti\u010dnimi bazami, kot je Vertica, vendar ne pla\u010dujemo obdobij zastoja.<\/p>\n
Tak\u0161na baza podatkov je primerna za redke analiti\u010dne ad-hoc poizvedbe. Na primer, ko se spontano odlo\u010dimo preveriti hipotezo na nekem ogromnem volumnu podatkov. Za te primere je Athena popolna. Za redne poizvedbe je ta sistem drag. V tem primeru bazo podatkov shranite v nekem specializiranem re\u0161enju. <\/p>\n
Serverless za OLTP re\u0161itve<\/h2>\n \nV prej\u0161njem primeru smo obravnavali OLAP naloge (analiti\u010dne). Zdaj bomo obravnavali OLTP naloge.<\/p>\n
Predstavimo skalirni PostgreSQL ali MySQL. Dvignimo obi\u010dajno upravljano instanco PostgreSQL ali MySQL z minimalnimi viri. Ko bo na instanco pri\u0161la ve\u010dja obremenitev, bomo povezali dodatne replikate, na katere bomo razporedili del berljive obremenitve. \u010ce ni poizvedb in obremenitve \u2014 izklju\u010dimo replike. Prva instanca je master, ostale so replike.<\/p>\n
Ta ideja je uresni\u010dena v bazi imenovani Aurora Serverless AWS. Na\u010delo je preprosto: poizvedbe iz zunanjih aplikacij sprejema proxy flota. Ko zazna rast obremenitve, dodeli ra\u010dunalni\u0161ke vire iz vnaprej segretih minimalnih instanc \u2014 povezava se izvede \u010dim hitreje. Izklapljanje instanc poteka prav tako.<\/p>\n
V okviru Aurora obstaja pojem Aurora Capacity Unit, ACU. To je (odvzetno) \u2014 instanca (stre\u017enik). Vsak dolo\u010den ACU je lahko master ali slave. Vsaka enota kapacitete ima svojo operativno pomnilnik, procesor in minimalno diskovno kapaciteto. Tako imamo enega master, ostale pa so le berljive replike.<\/p>\n
\u0160tevilo teh delujo\u010dih Aurora Capacity Units je nastavljiv parameter. Minimalno \u0161tevilo je lahko ena ali ni\u010d (v tem primeru baza ne deluje, \u010de ni poizvedb).<\/p>\n
Baza Aurora Serverless lahko skalira berljivo obremenitev. Vendar pa v dokumentaciji o tem ni povedano neposredno. Lahko se pojavi ob\u010dutek, da lahko dvignejo multi-master. Kakor koli, tu ni nobene \u010darovnije. <\/p>\n
Ta baza je odli\u010dna za izbegavanje velikih tro\u0161kova na sistemima sa nepredvidivim pristupom. Na primer, kada kreiramo MVP ili marketin\u0161ke sajtove, obi\u010dno ne o\u010dekujemo stabilno optere\u0107enje. U skladu s tim, kada nema pristupa, ne pla\u0107amo instance. Kada iznenada do\u0111e do optere\u0107enja, poput onog posle konferencije ili marketin\u0161ke kampanje, mase ljudi posete sajt i optere\u0107enje naglo raste, Aurora Serverless automatski prihvata to optere\u0107enje i brzo dodaje potrebne resurse (ACU). Nakon konferencije, svi zaborave na prototip, serveri (ACU) se gase i tro\u0161kovi opadaju na nulu \u2014 prakti\u010dno.<\/p>\n
Ovo re\u0161enje nije pogodno za stabilno visoko optere\u0107enje, jer ne mo\u017ee da skalira upisno optere\u0107enje. Sva ta povezivanja i odspajanja resursa de\u0161avaju se u trenutku poznatom kao \u201escale point\u201c \u2014 trenutku kada baza nije pod transakcijom, niti su zauzete privremene tabele. Na primer, tokom nedelje scale point mo\u017eda ne\u0107e nastati, a baza funkcioni\u0161e na istim resursima i jednostavno ne mo\u017ee ni da se pove\u0107a, ni da se smanji. <\/p>\n
Nema magije \u2014 to je obi\u010dan PostgreSQL. Ali proces dodavanja i isklju\u010divanja ma\u0161ina je delimi\u010dno automatizovan.<\/p>\n
Serverless po dizajnu<\/h2>\n \nAurora Serverless je stara baza koja je prilago\u0111ena oblaku tako da koristi odvojene prednosti Serverless. A sada \u0107u govoriti o bazi koja je prvobitno napisana za oblak, pod serverless pristupom \u2014 Serverless-by-design. Razvijana je bez pretpostavke da radi na fizi\u010dkim serverima.<\/p>\n
Ova baza se zove Snowflake. Ima tri klju\u010dna bloka.<\/p>\n
Drugi blok \u2014 to su brojni virtuelni ra\u010dunski klasteri za izra\u010dunavanja (na ilustraciji \u2014 set plavih krugova).<\/p>\n
Tre\u0107i blok \u2014 sistem skladi\u0161tenja podataka zasnovan na S3. S3 je neograni\u010deno objektno skladi\u0161te u AWS-u, ne\u0161to kao neograni\u010deni Dropbox za biznis.<\/p>\n
Poglejmo, kako Snowflake deluje v scenariju hladnega zagona. To pomeni, da baza obstaja, podatki so nalo\u017eeni v njo, vendar ni aktivnih poizvedb. Zato, \u010de ni poizvedb, imamo zagnan hiter in-memory Metadata servis (prvi sklop). Imamo tudi S3 shrambo, kjer so podatki tabel razdeljeni na t.i. mikroparticije. Poenostavljeno: \u010de tabela vsebuje posle, so mikroparticije dnevi poslov. Vsak dan je lo\u010dena mikroparticija, lo\u010dena datoteka. Ko baza deluje v tem na\u010dinu, pla\u010dujete samo za prostor, ki ga zasedajo podatki. Tarifa za prostor je zelo nizka (\u0161e posebej ob upo\u0161tevanju pomembne stiskanja). Metadata servis prav tako deluje neprekinjeno, vendar za optimizacijo poizvedb ne potrebuje veliko virov, zato ga lahko \u0161tejemo kot pogojno brezpla\u010dnega. <\/p>\n
Zdaj si predstavljajte, da je uporabnik poslal SQL poizvedbo na\u0161i bazi. SQL poizvedba takoj pride v obdelavo v Metadata servis. Takoj ko prejme poizvedbo, ta servis analizira poizvedbo, dostopne podatke, pooblastila uporabnika in, \u010de je vse v redu, pripravi na\u010drt obdelave poizvedbe.<\/p>\n
Nato servis spro\u017ei zagon izra\u010dunskega klastra. Izra\u010dunski klaster je skupina stre\u017enikov, ki izvajajo izra\u010dune. To pomeni, da klaster lahko vsebuje 1, 2, 4, 8, 16, 32 stre\u017enikov \u2014 kolikor \u017eelite. Po\u0161ljete poizvedbo in za njo se takoj za\u010dne zagon tega klasterja. To resni\u010dno traja sekunde.<\/p>\n
Vsaka SQL poizvedba lahko ne le pre\u0161teje agregate iz prej nalo\u017eenih podatkov, temve\u010d tudi nalo\u017ei\/formira nove podatke v bazi. To pomeni, da je to lahko poizvedba, ki, na primer, izvr\u0161i vstavljanje novih zapisov v drugo tabelo, kar vodi do pojavitve nove particije na ra\u010dunalni\u0161kem klastru, ki se nato samodejno shrani v enotno S3 shrambo.<\/p>\n
Opisani scenarij, od prihoda uporabnika do zagon klasterja, nalaganje podatkov, izvajanje poizvedb, pridobivanje rezultatov, se obra\u010dunava po tarifi za minute uporabe zagnanega virtualnega ra\u010dunalni\u0161kega klasterja, virtualnega skladi\u0161\u010da. Tarifa se razlikuje glede na obmo\u010dje AWS in velikost klasterja, a povpre\u010dno zna\u0161a nekaj dolarjev na uro. Klaster s \u0161tirimi stroji je dvakrat dra\u017eji od klasterja z dvema strojima, klaster z osmimi stroji pa je \u0161e dvakrat dra\u017eji. Na voljo so mo\u017enosti z 16, 32 stroji, odvisno od kompleksnosti poizvedb. Pla\u010date pa le za tiste minute, ko klaster dejansko deluje, ker, ko ni poizvedb, vi prakti\u010dno umaknete roke, in po 5-10 minutah \u010dakanja (nastavljiv parameter) se sam ugasne, sprosti vire in postane brezpla\u010den.<\/p>\n
Skenarij je potpuno realan kada po\u0161aljete zahtev, klaster se pojavljuje, da ka\u017eemo, za minut, jo\u0161 minut traje prora\u010dun, zatim pet minuta na ga\u0161enje, i na kraju pla\u0107ate za sedam minuta rada tog klastera, a ne za mesece i godine.<\/p>\n
Prvi scenario opisuje kori\u0161\u0107enje Snowflake u jednopostavlja\u010dkom re\u017eimu. Sada zamislite da ima mnogo korisnika, \u0161to ve\u0107 bli\u017ee stvarnom scenariju.<\/p>\n
Pretpostavimo da imamo mnogo analiti\u010dara i Tableau izve\u0161taja koji neprekidno bombarduju na\u0161u bazu velikim brojem jednostavnih analiti\u010dkih SQL zahteva.<\/p>\n
Osim toga, pretpostavimo da imamo inventivne Data Scientists koji poku\u0161avaju da rade u\u017easne stvari sa podacima, upravljaju\u0107i desetinama terabajta, analiziraju\u0107i milijarde i trilione redova podataka. <\/p>\n
Za navedena dva tipa optere\u0107enja, Snowflake omogu\u0107ava pokretanje vi\u0161e nezavisnih ra\u010dunarskih klastera razli\u010ditih kapaciteta. Ovi ra\u010dunarski klasteri rade nezavisno, ali sa zajedni\u010dkim doslednim podacima.<\/p>\n
Za veliki broj lakih zahteva, mo\u017eete pokrenuti 2-3 mala klastera, veli\u010dine, recimo, po 2 ma\u0161ine svaki. Ovo pona\u0161anje je ostvarivo, izme\u0111u ostalog, putem automatskih pode\u0161avanja. Dakle, ka\u017eete: 'Snowflake, pokreni mali klaster. Ako optere\u0107enje poraste iznad odre\u0111enog parametra, pokreni sli\u010dan drugi, tre\u0107i. Kada optere\u0107enje po\u010dne da opada \u2013 ugasi suvi\u0161ne.' Tako da, bez obzira na to koliko analiti\u010dara do\u0111e i po\u010dne da pregleda izve\u0161taje, svima \u0107e biti dovoljno resursa.<\/p>\n
Pri tome, ako analiti\u010dari spavaju, i izve\u0161taje niko ne gleda \u2013 klasteri se mogu potpuno ugasiti, i prestajete da pla\u0107ate za njih.<\/p>\n
U me\u0111uvremenu, za te\u0161ke zahteve (od Data Scientists), mo\u017eete pokrenuti jedan veoma veliki klaster na, recimo, 32 ma\u0161ine. Ovaj klaster \u0107e tako\u0111e biti napla\u0107en samo za one minute i sate kada va\u0161 ogroman zahtev radi.<\/p>\n
Ova opisano mogu\u0107nost omogu\u0107ava deljenje klastera ne samo po 2, ve\u0107 po vi\u0161e vrsta optere\u0107enja (ETL, monitoring, materijalizacija izve\u0161taja,\u2026).<\/p>\n
Povzemimo Snowflake. Osnova zdru\u017euje lepo idejo in delujo\u010do implementacijo. V ManyChat uporabljamo Snowflake za analitiko vseh razpolo\u017eljivih podatkov. Klasterjev imamo ne tri, kot v primeru, ampak od 5 do 9, razli\u010dnih velikosti. Imamo nekak\u0161ne 16-strojne, 2-strojne, pa tudi super-mahne 1-strojne naprave za nekatere naloge. Uspe\u0161no porazdelijo obremenitev in nam omogo\u010dajo veliko var\u010devanje.<\/p>\n
Osnova uspe\u0161no skalira bralno in pisno obremenitev. To je ogromna razlika in velik preboj v primerjavi z 'Avro', ki je obvladovala le bralno obremenitev. Snowflake omogo\u010da skaliranje s temi izra\u010dunskimi klasterji in pisno obremenitev. Tako kot sem omenil, imamo v ManyChatu ve\u010d klasterjev, majhni in super-mahni klasterji se ve\u010dinoma uporabljajo za ETL, za nalaganje podatkov. Analitiki pa delujejo na srednjih klasterjih, ki niso obremenjeni z ETL nalogami, zato delujejo zelo hitro. <\/p>\n
Zato je osnova dobro primerna za OLAP naloge. Na \u017ealost pa za OLTP obremenitve \u0161e ni primerna. Prvi\u010d, ta baza je kolona\u010dna, s vsemi iz tega izhajajo\u010dimi posledicami. Drugi\u010d, sam pristop, ko ob vsakem povpra\u0161evanju po potrebi dvignete izra\u010dunski klaster in ga napolnite s podatki, je na \u017ealost za OLTP obremenitve \u0161e vedno prepo\u010dasen. Sekunde \u010dakanja za OLAP naloge so sprejemljive, za OLTP naloge pa nesprejemljive; raje bi imeli 100 ms, \u0161e bolje pa 10 ms.<\/p>\n
Zaklju\u010dek<\/h2>\n \nServerless podatkovna baza je mogo\u010da zaradi razdelitve baze podatkov na Stateless in Stateful dele. Verjetno ste opazili, da v vseh navedenih primerih Stateful del \u2014 to je, recimo, shranjevanje mikroparticij v S3, medtem ko je Stateless \u2014 optimizator, delo z meta-podatki, obdelava vpra\u0161anj varnosti, ki jih je mogo\u010de obravnavati kot neodvisne lahke Stateless storitve.<\/p>\n
Izvajanje SQL poizvedb se lahko prav tako dojame kot storitve z lahkim stanjem, ki se lahko pojavijo v brezstre\u017enem na\u010dinu, kot so izra\u010dunski klasterji Snowflake, prenesejo samo potrebne podatke, izvedejo poizvedbo in 'ugodijo'.<\/p>\n
Serverless baze produkcijske ravni so \u017ee na voljo za uporabo, delujejo. Te serverless baze so \u017ee pripravljene za obvladovanje OLAP nalog. Na \u017ealost pa pri OLTP nalogah obstajajo\u2026 nekatere omejitve, zato se uporabljajo z dodatnimi previdnostmi. Po eni strani je to slabost. Po drugi strani pa je to prilo\u017enost. Morda bo kdo med bralci na\u0161el na\u010din, kako narediti OLTP bazo povsem serverless, brez omejitev Aurora.<\/p>\n
Upam, da vam je bilo zanimivo. Serverless prihodnost \ud83d\ude42habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0413\u043e\u043b\u043e\u0432 \u041d\u0438\u043a\u043e\u043b\u0430\u0439. \u0420\u0430\u043d\u044c\u0448\u0435 \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u043b \u0432 \u0410\u0432\u0438\u0442\u043e \u0438 \u0448\u0435\u0441\u0442\u044c \u043b\u0435\u0442 \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u043b Data Platform, \u0442\u043e \u0435\u0441\u0442\u044c \u0437\u0430\u043d\u0438\u043c\u0430\u043b\u0441\u044f \u0432\u0441\u0435\u043c\u0438 \u0431\u0430\u0437\u0430\u043c\u0438: \u0430\u043d\u0430\u043b\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u043c\u0438 (Vertica, ClickHouse), \u043f\u043e\u0442\u043e\u043a\u043e\u0432\u044b\u043c\u0438 \u0438 OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). \u0417\u0430 \u044d\u0442\u043e \u0432\u0440\u0435\u043c\u044f \u044f \u0440\u0430\u0437\u043e\u0431\u0440\u0430\u043b\u0441\u044f \u0441 \u0431\u043e\u043b\u044c\u0448\u0438\u043c \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e\u043c \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 \u2014 \u0441\u0430\u043c\u044b\u0445 \u0440\u0430\u0437\u043d\u044b\u0445 \u0438 \u043d\u0435\u043e\u0431\u044b\u0447\u043d\u044b\u0445, \u0438 \u0441 \u043d\u0435\u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442\u043d\u044b\u043c\u0438 \u043a\u0435\u0439\u0441\u0430\u043c\u0438 \u0438\u0445 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f. \u0421\u0435\u0439\u0447\u0430\u0441 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91636,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91635","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t