Hæ allir! Ég heiti Golov Nikolay. Áður starfaði ég hjá Avito og stýrði gagnapallinum í sex ár, það er að segja ég vann við alla gagnagrunna: greiningu (Vertica, ClickHouse), streymi og OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Á þessum tíma fékkst ég við mikinn fjölda gagnagrunna - mjög ólíkir og óvenjulegir og með óstöðluð tilvik um notkun þeirra.
Ég er núna að vinna hjá ManyChat. Í meginatriðum er þetta sprotafyrirtæki - nýtt, metnaðarfullt og ört vaxandi. Og þegar ég kom fyrst til liðs við fyrirtækið vaknaði klassísk spurning: „Hvað ætti ungt sprotafyrirtæki að taka af DBMS- og gagnagrunnsmarkaðnum?
Í þessari grein, byggt á skýrslu minni kl , Ég mun svara þessari spurningu. Myndbandsútgáfa af skýrslunni er aðgengileg á .
Almennt þekktir gagnagrunnar 2020
Það er 2020, ég leit í kringum mig og sá þrjár tegundir af gagnagrunnum.
Fyrsta tegund - klassískir OLTP gagnagrunnar: PostgreSQL, SQL Server, Oracle, MySQL. Þeir voru skrifaðir fyrir löngu síðan, en eiga samt við vegna þess að þeir eru svo kunnugir þróunarsamfélaginu.
Önnur tegundin er basar frá "núll". Þeir reyndu að hverfa frá klassískum mynstrum með því að yfirgefa SQL, hefðbundna mannvirki og ACID, með því að bæta við innbyggðri klippingu og öðrum aðlaðandi eiginleikum. Til dæmis er þetta Cassandra, MongoDB, Redis eða Tarantool. Allar þessar lausnir vildu bjóða markaðnum upp á eitthvað í grundvallaratriðum nýtt og tóku upp sess þeirra vegna þess að þær reyndust afar hentugar fyrir ákveðin verkefni. Ég mun tákna þessa gagnagrunna með regnhlífarhugtakinu NOSQL.
„Núllin“ eru liðin, við venjumst NOSQL gagnagrunnum og heimurinn, frá mínu sjónarhorni, tók næsta skref - að stýrðum gagnagrunnum. Þessir gagnagrunnar hafa sama kjarna og klassískir OLTP gagnagrunnar eða nýir NoSQL. En þeir hafa enga þörf fyrir DBA og DevOps og keyra á stýrðum vélbúnaði í skýjunum. Fyrir þróunaraðila er þetta „bara grunn“ sem virkar einhvers staðar, en engum er sama hvernig það er sett upp á þjóninum, hver stillti þjóninn og hver uppfærir hann.
Dæmi um slíka gagnagrunna:
- AWS RDS er stýrður umbúðir fyrir PostgreSQL/MySQL.
- DynamoDB er AWS hliðstæða skjalagrunns gagnagrunns, svipað Redis og MongoDB.
- Amazon Redshift er stýrður greiningargagnagrunnur.
Þetta eru í grundvallaratriðum gamlir gagnagrunnar, en aldir upp í stýrðu umhverfi, án þess að þurfa að vinna með vélbúnaði.
Athugið. Dæmin eru tekin fyrir AWS umhverfið, en hliðstæður þeirra eru einnig til í Microsoft Azure, Google Cloud eða Yandex.Cloud.
Hvað er nýtt við þetta? Árið 2020, ekkert af þessu.
Serverless hugtak
Það sem er í raun nýtt á markaðnum árið 2020 er netþjónalausar eða netþjónlausar lausnir.
Ég mun reyna að útskýra hvað þetta þýðir með því að nota dæmið um venjulega þjónustu eða bakendaforrit.
Til að setja upp venjulegt bakendaforrit kaupum við eða leigjum miðlara, afritum kóðann á hann, birtum endapunktinn fyrir utan og borgum reglulega fyrir leigu, rafmagn og þjónustu gagnavera. Þetta er staðlað kerfi.
Er einhver önnur leið? Með netþjónalausri þjónustu geturðu.
Hver er áherslan á þessari nálgun: það er enginn netþjónn, það er ekki einu sinni að leigja sýndartilvik í skýinu. Til að dreifa þjónustunni skaltu afrita kóðann (aðgerðirnar) í geymsluna og birta hann á endapunktinn. Þá borgum við einfaldlega fyrir hvert símtal í þessa aðgerð og hunsum algjörlega vélbúnaðinn þar sem hann er keyrður.
Ég mun reyna að útskýra þessa nálgun með myndum.
Klassísk dreifing. Við erum með þjónustu með ákveðið álag. Við tökum upp tvö tilvik: líkamlega netþjóna eða tilvik í AWS. Ytri beiðnir eru sendar til þessara aðila og afgreiddar þar.
Eins og þú sérð á myndinni er netþjónunum ekki ráðstafað jafnt. Ein er 100% nýtt, það eru tvær beiðnir og önnur er aðeins 50% - að hluta til aðgerðalaus. Ef ekki berast þrjár beiðnir, heldur 30, þá mun allt kerfið ekki ráða við álagið og fer að hægja á sér.
Serverlaus dreifing. Í netþjónslausu umhverfi hefur slík þjónusta ekki tilvik eða netþjóna. Það er ákveðinn hópur af upphituðum auðlindum - litlir tilbúnir Docker gámar með útfærðum aðgerðakóða. Kerfið tekur á móti utanaðkomandi beiðnum og fyrir hverja þeirra vekur netþjónalausi ramminn lítinn ílát með kóða: það vinnur úr þessari tilteknu beiðni og drepur ílátið.
Ein beiðni - einn gámur hækkaður, 1000 beiðnir - 1000 gámar. Og uppsetning á vélbúnaðarþjónum er nú þegar verk skýjaveitunnar. Það er algjörlega falið af netþjónalausa rammanum. Í þessari hugmynd greiðum við fyrir hvert símtal. Til dæmis kom eitt símtal á dag - við borguðum fyrir eitt símtal, milljón kom á mínútu - við borguðum fyrir milljón. Eða á einni sekúndu gerist þetta líka.
Hugmyndin um að gefa út netþjónalausa aðgerð hentar fyrir ríkisfangslausa þjónustu. Og ef þú þarft (ríkis) ríkisþjónustu, þá bætum við gagnagrunni við þjónustuna. Í þessu tilviki, þegar kemur að því að vinna með ástand, skrifar hver statefull aðgerð einfaldlega og les úr gagnagrunninum. Þar að auki, úr gagnagrunni af einhverjum af þeim þremur gerðum sem lýst er í upphafi greinarinnar.
Hver er sameiginleg takmörkun allra þessara gagnagrunna? Þetta er kostnaður við stöðugt notaðan skýja- eða vélbúnaðarþjón (eða nokkra netþjóna). Það skiptir ekki máli hvort við notum klassískan eða stýrðan gagnagrunn, hvort sem við erum með Devops og admin eða ekki, við borgum samt fyrir vélbúnað, rafmagn og gagnaveraleigu allan sólarhringinn. Ef við höfum klassískan grunn, borgum við fyrir húsbónda og þræl. Ef það er mjög hlaðinn rifinn gagnagrunnur, borgum við fyrir 24, 7 eða 10 netþjóna og við borgum stöðugt.
Tilvist varanlega frátekinna netþjóna í kostnaðarskipulaginu var áður talið nauðsynlegt illt. Hefðbundnir gagnagrunnar eiga líka við aðra erfiðleika að etja, eins og takmarkanir á fjölda tenginga, takmarkanir á stærðarstærð, landfræðileg dreifð samstaða - þeir geta einhvern veginn verið leystir í ákveðnum gagnagrunnum, en ekki allt í einu og ekki helst.
Serverless gagnagrunnur - kenning
Spurning 2020: er hægt að gera gagnagrunnsþjónslausan líka? Allir hafa heyrt um serverlausa bakendann... við skulum reyna að gera gagnagrunninn serverlausan?
Þetta hljómar undarlega, því gagnagrunnurinn er fullkomin þjónusta, ekki mjög hentug fyrir netþjónalausa innviði. Á sama tíma er ástand gagnagrunnsins mjög stórt: gígabæt, terabæt og í greiningargagnagrunnum jafnvel petabæt. Það er ekki svo auðvelt að ala það í léttum Docker gámum.
Á hinn bóginn innihalda næstum allir nútíma gagnagrunnar mikið magn af rökfræði og hlutum: færslum, samhæfingu heilleika, verklagsreglur, tengslaháðir og mikið af rökfræði. Fyrir töluvert af gagnagrunnsrökfræði er lítið ríki nóg. Gígabæt og terabæt eru notuð beint af aðeins litlum hluta gagnagrunnsrökfræðinnar sem tekur þátt í að framkvæma fyrirspurnir beint.
Í samræmi við það er hugmyndin þessi: ef hluti af rökfræðinni leyfir ríkisfangslausa aftöku, hvers vegna þá ekki að skipta grunninum í Stateful og Stateless hluta.
Serverless fyrir OLAP lausnir
Við skulum sjá hvernig klippa gagnagrunn í Stateful og Stateless hluta gæti litið út með því að nota hagnýt dæmi.
Til dæmis höfum við greiningargagnagrunn: ytri gögn (rauður hólkur til vinstri), ETL ferli sem hleður gögnum inn í gagnagrunninn og sérfræðingur sem sendir SQL fyrirspurnir í gagnagrunninn. Þetta er klassískt rekstrarkerfi fyrir gagnavöruhús.
Í þessu kerfi er ETL skilyrt framkvæmt einu sinni. Þá þarf stöðugt að borga fyrir netþjónana sem gagnagrunnurinn keyrir á með gögnum sem eru fyllt með ETL, svo það sé eitthvað til að senda fyrirspurnir á.
Við skulum skoða aðra nálgun sem er útfærð í AWS Athena Serverless. Það er enginn varanlega hollur vélbúnaður sem niðurhal gögn eru geymd á. Í staðinn fyrir þetta:
- Notandinn sendir SQL fyrirspurn til Aþenu. Athena optimizer greinir SQL fyrirspurnina og leitar í lýsigagnageymslunni (Metadata) að sérstökum gögnum sem þarf til að framkvæma fyrirspurnina.
- Fínstillingin, sem byggir á söfnuðu gögnunum, hleður niður nauðsynlegum gögnum frá utanaðkomandi aðilum í tímabundna geymslu (tímabundinn gagnagrunn).
- SQL fyrirspurn frá notanda er keyrð í tímabundinni geymslu og niðurstöðunni er skilað til notanda.
- Tímabundin geymsla er hreinsuð og tilföng losuð.
Í þessum arkitektúr greiðum við aðeins fyrir ferlið við að framkvæma beiðnina. Engar beiðnir - enginn kostnaður.
Þetta er vinnuaðferð og er ekki aðeins útfærð í Athena Serverless, heldur einnig í Redshift Spectrum (í AWS).
Athena dæmið sýnir að Serverless gagnagrunnurinn vinnur á raunverulegum fyrirspurnum með tugum og hundruðum terabæta af gögnum. Hundruð terabæta munu þurfa hundruð netþjóna, en við þurfum ekki að borga fyrir þá - við borgum fyrir beiðnirnar. Hraði hverrar beiðni er (mjög) lágur miðað við sérhæfða greiningargagnagrunna eins og Vertica, en við borgum ekki fyrir niðurtímatímabil.
Slíkur gagnagrunnur á við fyrir sjaldgæfar greiningarfyrirspurnir. Til dæmis þegar við ákveðum sjálfkrafa að prófa tilgátu á risastóru magni af gögnum. Athena er fullkomin fyrir þessi mál. Fyrir reglulegar beiðnir er slíkt kerfi dýrt. Í þessu tilviki skaltu vista gögnin í einhverri sérhæfðri lausn.
Serverless fyrir OLTP lausnir
Fyrra dæmið skoðaði OLAP (greiningar) verkefni. Nú skulum við skoða OLTP verkefni.
Við skulum ímynda okkur stigstærð PostgreSQL eða MySQL. Við skulum ala upp venjulegt stýrt tilvik PostgreSQL eða MySQL með lágmarks fjármagni. Þegar tilvikið fær meira álag, munum við tengja viðbótar eftirmyndir sem við munum dreifa hluta af lestrarálaginu. Ef það eru engar beiðnir og ekkert álag slökkvum við á eftirmyndunum. Fyrsta tilvikið er meistarinn og restin eru eftirlíkingar.
Þessi hugmynd er útfærð í gagnagrunni sem heitir Aurora Serverless AWS. Meginreglan er einföld: beiðnir frá utanaðkomandi umsóknum eru samþykktar af umboðsflotanum. Með því að sjá álagið aukast, úthlutar það tölvuauðlindum frá forhituðum lágmarkstilvikum - tengingin er gerð eins fljótt og auðið er. Slökkt tilvik eiga sér stað á sama hátt.
Innan Aurora er hugmyndin um Aurora Capacity Unit, ACU. Þetta er (skilyrt) tilvik (þjónn). Hver sérstakur ACU getur verið meistari eða þræll. Hver Capacity Unit hefur sitt eigið vinnsluminni, örgjörva og lágmarksdisk. Í samræmi við það er einn meistari, restin er eingöngu lesin eftirlíkingar.
Fjöldi þessara Aurora Capacity Units í gangi er stillanleg færibreyta. Lágmarksmagn getur verið eitt eða núll (í þessu tilviki virkar gagnagrunnurinn ekki ef það eru engar beiðnir).
Þegar stöðin fær beiðnir hækkar umboðsflotinn Aurora CapacityUnits, sem eykur afköst kerfisins. Hæfnin til að auka og minnka tilföng gerir kerfinu kleift að "snúa saman" tilföngum: birta sjálfkrafa einstakar ACUs (skipta þeim út fyrir nýjar) og rúlla út allar núverandi uppfærslur á teknu tilföngum.
Aurora Serverless grunnurinn getur skalað lestrarálagið. En skjölin segja þetta ekki beint. Það kann að líða eins og þeir geti lyft fjölmeistara. Það er enginn galdur.
Þessi gagnagrunnur er vel til þess fallinn að forðast að eyða miklum fjárhæðum í kerfi með ófyrirsjáanlegan aðgang. Til dæmis, þegar við búum til MVP eða markaðssetur nafnspjaldasíður, gerum við venjulega ekki ráð fyrir stöðugu álagi. Samkvæmt því, ef það er enginn aðgangur, borgum við ekki fyrir tilvik. Þegar óvænt álag á sér stað, til dæmis eftir ráðstefnu eða auglýsingaherferð, fjöldi fólks heimsækir síðuna og álagið eykst til muna, tekur Aurora Serverless þetta álag sjálfkrafa og tengir fljótt auðlindirnar sem vantar (ACU). Svo líður ráðstefnan, allir gleyma frumgerðinni, netþjónarnir (ACU) verða dimmir og kostnaðurinn fer niður í núll - þægilegt.
Þessi lausn hentar ekki fyrir stöðugt háhleðslu vegna þess að hún mælir ekki skrifhleðsluna. Allar þessar tengingar og aftengingar auðlinda eiga sér stað á svokölluðum „skalapunkti“ - tímapunkti þegar gagnagrunnurinn er ekki studdur af færslu eða tímabundnum töflum. Til dæmis innan viku gæti mælikvarðinn ekki átt sér stað og grunnurinn vinnur á sömu auðlindum og getur einfaldlega ekki stækkað eða dregist saman.
Það er enginn galdur - það er venjulegur PostgreSQL. En ferlið við að bæta við vélum og aftengja þær er að hluta til sjálfvirkt.
Serverless að hönnun
Aurora Serverless er gamall gagnagrunnur endurskrifaður fyrir skýið til að nýta sér nokkra kosti Serverless. Og nú skal ég segja þér frá grunninum, sem upphaflega var skrifaður fyrir skýið, fyrir netþjónalausu nálgunina - Serverless-by-design. Það var strax þróað án þess að gera ráð fyrir að það myndi keyra á líkamlegum netþjónum.
Þessi grunnur heitir Snowflake. Það hefur þrjá lykilkubba.
Hið fyrra er lýsigagnablokk. Þetta er hröð þjónusta í minni sem leysir vandamál með öryggi, lýsigögn, viðskipti og fínstillingu fyrirspurna (sýnt á myndinni til vinstri).
Annar reiturinn er safn sýndartölvuklasa fyrir útreikninga (á myndinni er sett af bláum hringjum).
Þriðja blokkin er gagnageymslukerfi byggt á S3. S3 er víddarlaus hlutgeymsla í AWS, eins og víddarlaus Dropbox fyrir fyrirtæki.
Við skulum sjá hvernig Snowflake virkar, að því gefnu að það sé kalt byrjun. Það er, það er gagnagrunnur, gögnunum er hlaðið inn í hann, það eru engar hlaupandi fyrirspurnir. Í samræmi við það, ef það eru engar beiðnir um gagnagrunninn, þá höfum við hækkað hraðvirka lýsigagnaþjónustu í minni (fyrsta blokk). Og við erum með S3 geymslu þar sem töflugögn eru geymd, skipt í svokallaðar örsneiðar. Til einföldunar: ef taflan inniheldur viðskipti, þá eru örskiptingar dagar viðskiptanna. Hver dagur er sérstakt örskipting, sérstök skrá. Og þegar gagnagrunnurinn starfar í þessum ham borgar þú aðeins fyrir plássið sem gögnin taka. Þar að auki er hlutfallið á hvert sæti mjög lágt (sérstaklega að teknu tilliti til verulegrar þjöppunar). Lýsigagnaþjónustan virkar líka stöðugt, en þú þarft ekki mikið fjármagn til að fínstilla fyrirspurnir og þjónustan getur talist deilihugbúnaður.
Nú skulum við ímynda okkur að notandi hafi komið í gagnagrunninn okkar og sent SQL fyrirspurn. SQL fyrirspurnin er strax send til Lýsigagnaþjónustunnar til vinnslu. Í samræmi við það, við móttöku beiðni, greinir þessi þjónusta beiðnina, tiltæk gögn, notendaheimildir og, ef allt er í lagi, gerir áætlun um afgreiðslu beiðninnar.
Næst byrjar þjónustan á ræsingu tölvuklasans. Tölvuklasi er þyrping netþjóna sem framkvæma útreikninga. Það er að segja, þetta er þyrping sem getur innihaldið 1 server, 2 servera, 4, 8, 16, 32 - eins marga og þú vilt. Þú sendir beiðni og ræsing þessa klasa hefst strax. Það tekur í raun sekúndur.
Næst, eftir að þyrpingin hefur byrjað, byrjar að afrita örskilin sem þarf til að vinna úr beiðni þinni inn í þyrpinguna frá S3. Það er að segja, við skulum ímynda okkur að til að framkvæma SQL fyrirspurn þarftu tvær skiptingar úr einni töflu og eina frá annarri. Í þessu tilviki verða aðeins þrjár nauðsynlegar skiptingarnar afritaðar í þyrpinguna, en ekki allar töflur að öllu leyti. Þess vegna, og einmitt vegna þess að allt er staðsett innan einni gagnaveri og tengt með mjög hröðum rásum, gerist allt flutningsferlið mjög fljótt: á sekúndum, mjög sjaldan á mínútum, nema við séum að tala um voðalegar beiðnir. Í samræmi við það eru örskiptingar afritaðar í tölvuklasann og að því loknu er SQL fyrirspurnin keyrð á þessum tölvuklasa. Niðurstaða þessarar beiðni getur verið ein lína, nokkrar línur eða tafla - þær eru sendar að utan til notandans svo hann geti halað henni niður, birt hana í BI tólinu sínu eða notað það á annan hátt.
Hver SQL fyrirspurn getur ekki aðeins lesið samanlagðar gögn úr áður hlaðnum gögnum, heldur einnig hlaðið/framleitt ný gögn í gagnagrunninum. Það er, það getur verið fyrirspurn sem til dæmis setur nýjar færslur inn í aðra töflu, sem leiðir til þess að ný skipting birtist á tölvuklasanum, sem aftur er sjálfkrafa vistuð í einni S3 geymslu.
Atburðarásin sem lýst er hér að ofan, frá komu notandans til að hækka þyrpinguna, hlaða gögnum, framkvæma fyrirspurnir, fá niðurstöður, er greitt á genginu fyrir mínútur af því að nota hækkaða sýndartölvuklasann, sýndarvöruhús. Gjaldið er mismunandi eftir AWS svæði og klasastærð, en að meðaltali er það nokkrir dollarar á klukkustund. Fjórar vélaþyrping er tvöfalt dýrari en tvær vélaþyrpingar og átta vélaþyrping er enn tvöfalt dýrari. Hægt er að velja um 16, 32 vélar, allt eftir því hversu flóknar beiðnirnar eru. En þú borgar aðeins fyrir þessar mínútur þegar þyrpingin er í raun í gangi, því þegar það eru engar beiðnir, tekur þú af þér hendurnar og eftir 5-10 mínútna bið (stillanleg færibreyta) slokknar hann af sjálfu sér, losaðu um auðlindir og verða ókeypis.
Algjörlega raunhæf atburðarás er þegar þú sendir beiðni, þyrpingin birtist, tiltölulega séð, á einni mínútu, hann telur aðra mínútu, síðan fimm mínútur til að slökkva, og þú endar með því að borga fyrir sjö mínútna rekstur þessa þyrpingar, og ekki í mánuði og ár.
Fyrsta atburðarásin lýsti því að nota Snowflake í einsnotandastillingu. Nú skulum við ímynda okkur að það séu margir notendur, sem er nær raunverulegri atburðarás.
Segjum að við höfum mikið af sérfræðingum og Tableau skýrslum sem stöðugt sprengja gagnagrunninn okkar með miklum fjölda einfaldra SQL greiningarfyrirspurna.
Þar að auki skulum við segja að við höfum frumlega gagnafræðinga sem eru að reyna að gera voðalega hluti með gögnum, starfa með tugum terabæta, greina milljarða og trilljóna gagnalína.
Fyrir tvær tegundir vinnuálags sem lýst er hér að ofan, gerir Snowflake þér kleift að ala upp nokkra sjálfstæða tölvuklasa með mismunandi getu. Þar að auki vinna þessir tölvuklasar sjálfstætt, en með sameiginlegum samkvæmum gögnum.
Fyrir mikinn fjölda léttra fyrirspurna geturðu búið til 2-3 litla klasa, um það bil 2 vélar hver. Þessa hegðun er meðal annars hægt að útfæra með því að nota sjálfvirkar stillingar. Svo þú segir: „Snjókorn, reistu upp lítinn klasa. Ef álagið á það eykst yfir ákveðna færibreytu skaltu hækka svipaða sekúndu, þriðju. Þegar álagið fer að minnka skaltu slökkva á umframmagninu.“ Þannig að það er sama hversu margir sérfræðingar koma og byrja að skoða skýrslur, allir hafa nóg fjármagn.
Á sama tíma, ef greiningaraðilar eru sofandi og enginn horfir á skýrslurnar, gætu klasarnir farið að dimma algjörlega og þú hættir að borga fyrir þær.
Á sama tíma, fyrir miklar fyrirspurnir (frá Data Scientists), geturðu búið til einn mjög stóran þyrping fyrir 32 vélar. Þessi þyrping verður einnig aðeins greidd fyrir þær mínútur og klukkustundir þegar risastór beiðni þín er í gangi þar.
Tækifærið sem lýst er hér að ofan gerir þér kleift að skipta ekki aðeins 2, heldur einnig fleiri tegundum af vinnuálagi í klasa (ETL, eftirlit, skýrslugerð, ...).
Við skulum draga saman Snowflake. Grunnurinn sameinar fallega hugmynd og framkvæmanlega útfærslu. Við hjá ManyChat notum Snowflake til að greina öll gögnin sem við höfum. Við höfum ekki þrjá klasa, eins og í dæminu, heldur frá 5 til 9, af mismunandi stærðum. Við erum með hefðbundnar 16 vélar, 2 vélar og líka ofurlitlar 1 vélar fyrir sum verkefni. Þeir dreifa álaginu með góðum árangri og gera okkur kleift að spara mikið.
Gagnagrunnurinn mælir lestrar- og skriftarálag með góðum árangri. Þetta er gríðarlegur munur og mikil bylting miðað við sömu „Aurora“ sem bar aðeins lestrarálagið. Snowflake gerir þér kleift að stækka ritunarálag þitt með þessum tölvuklösum. Það er, eins og ég nefndi, við notum nokkra klasa í ManyChat, litlir og ofurlitlir klasar eru aðallega notaðir fyrir ETL, til að hlaða gögnum. Og sérfræðingar búa nú þegar á miðlungs klösum, sem eru nákvæmlega ekki fyrir áhrifum af ETL álaginu, svo þeir vinna mjög hratt.
Samkvæmt því hentar gagnagrunnurinn vel fyrir OLAP verkefni. Hins vegar, því miður, á það ekki enn við um OLTP vinnuálag. Í fyrsta lagi er þessi gagnagrunnur dálkalaga, með öllum afleiðingum þess. Í öðru lagi, nálgunin sjálf, þegar fyrir hverja beiðni, ef nauðsyn krefur, þú hækkar tölvuklasa og flæðir hann með gögnum, er því miður ekki enn nógu hröð fyrir OLTP álag. Það er eðlilegt að bíða í sekúndur eftir OLAP verkefnum, en fyrir OLTP verkefni er það óviðunandi; 100 ms væri betra, eða 10 ms væri jafnvel betra.
Samtals
Miðlaralaus gagnagrunnur er mögulegur með því að skipta gagnagrunninum í Stateless og Stateful hluta. Þú gætir hafa tekið eftir því að í öllum ofangreindum dæmum er Stateful hlutinn, tiltölulega séð, að geyma örsneiðar í S3 og Stateless er fínstillingaraðilinn, vinnur með lýsigögn, meðhöndlar öryggisvandamál sem hægt er að vekja upp sem sjálfstæða létta Stateless þjónustu.
Að keyra SQL fyrirspurnir getur líka verið litið á sem léttar þjónustur sem geta skotið upp kollinum í miðlaralausum ham, eins og Snowflake tölvuklasa, hlaðið aðeins niður nauðsynlegum gögnum, framkvæmt fyrirspurnina og „farið út.
Netþjónalausir gagnagrunnar á framleiðslustigi eru nú þegar tiltækir til notkunar, þeir eru að virka. Þessir netþjónalausu gagnagrunnar eru nú þegar tilbúnir til að takast á við OLAP verkefni. Því miður, fyrir OLTP verkefni eru þau notuð... með blæbrigðum, þar sem það eru takmarkanir. Annars vegar er þetta mínus. En á hinn bóginn er þetta tækifæri. Kannski mun einn lesenda finna leið til að gera OLTP gagnagrunn algjörlega miðlaralausan, án takmarkana Aurora.
Ég vona að þér hafi fundist það áhugavert. Serverless er framtíðin :)
Heimild: www.habr.com