Sveiki visiem! Mani sauc Golovs Nikolajs. IepriekÅ” strÄdÄju Avito un seÅ”us gadus vadÄ«ju datu platformu, tas ir, strÄdÄju pie visÄm datu bÄzÄm: analÄ«tiskajÄm (Vertica, ClickHouse), straumÄÅ”anas un OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Å ajÄ laikÄ es nodarbojos ar ļoti daudzÄm datu bÄzÄm ā ļoti dažÄdÄm un neparastÄm, un ar nestandarta to izmantoÅ”anas gadÄ«jumiem.
PaÅ”laik strÄdÄju vietnÄ ManyChat. PÄc bÅ«tÄ«bas tas ir startup ā jauns, ambiciozs un strauji augoÅ”s. Un, kad es pirmo reizi pievienojos uzÅÄmumam, radÄs klasisks jautÄjums: "Ko jaunam starta uzÅÄmumam tagad vajadzÄtu Åemt no DBVS un datu bÄzu tirgus?"
Å ajÄ rakstÄ, pamatojoties uz manu ziÅojumu plkst , Es atbildÄÅ”u uz Å”o jautÄjumu. ZiÅojuma video versija ir pieejama vietnÄ .
PlaÅ”i pazÄ«stamÄs datu bÄzes 2020
Ir 2020. gads, es paskatÄ«jos apkÄrt un ieraudzÄ«ju trÄ«s veidu datu bÄzes.
Pirmais veids - klasiskÄs OLTP datu bÄzes: PostgreSQL, SQL Server, Oracle, MySQL. Tie tika uzrakstÄ«ti jau sen, taÄu joprojÄm ir aktuÄli, jo izstrÄdÄtÄju kopienai tie ir tik pazÄ«stami.
Otrais veids ir bÄzes no "nulles". ViÅi mÄÄ£inÄja attÄlinÄties no klasiskajiem modeļiem, atsakoties no SQL, tradicionÄlajÄm struktÅ«rÄm un ACID, pievienojot iebÅ«vÄtu sadalÄ«Å”anu un citas pievilcÄ«gas funkcijas. PiemÄram, tas ir Cassandra, MongoDB, Redis vai Tarantool. Visi Å”ie risinÄjumi vÄlÄjÄs piedÄvÄt tirgum kaut ko principiÄli jaunu un ieÅÄma savu niÅ”u, jo izrÄdÄ«jÄs ÄrkÄrtÄ«gi Ärti noteiktu uzdevumu veikÅ”anai. Å Ä«s datu bÄzes apzÄ«mÄÅ”u ar jumta terminu NOSQL.
āNullesā ir beiguÅ”Äs, mÄs pieradÄm pie NOSQL datu bÄzÄm, un pasaule, no mana viedokļa, spÄra nÄkamo soli - lai pÄrvaldÄ«tÄs datu bÄzes. Å Ä«m datu bÄzÄm ir tÄds pats kodols kÄ klasiskajÄm OLTP datu bÄzÄm vai jaunajÄm NoSQL datu bÄzÄm. Bet tiem nav nepiecieÅ”ama DBA un DevOps, un tie darbojas ar pÄrvaldÄ«tu aparatÅ«ru mÄkoÅos. IzstrÄdÄtÄjam tÄ ir ātikai bÄzeā, kas kaut kur darbojas, taÄu nevienam neinteresÄ, kÄ tÄ ir instalÄta serverÄ«, kas konfigurÄja serveri un kas to atjaunina.
Å Ädu datu bÄzu piemÄri:
- AWS RDS ir pÄrvaldÄ«ts PostgreSQL/MySQL iesaiÅojums.
- DynamoDB ir AWS analogs dokumentiem balstÄ«tai datubÄzei, lÄ«dzÄ«ga Redis un MongoDB.
- Amazon Redshift ir pÄrvaldÄ«ta analÄ«tiskÄ datu bÄze.
TÄs pamatÄ ir vecas datu bÄzes, bet izveidotas pÄrvaldÄ«tÄ vidÄ, bez nepiecieÅ”amÄ«bas strÄdÄt ar aparatÅ«ru.
PiezÄ«me. PiemÄri ir Åemti par AWS vidi, taÄu to analogi pastÄv arÄ« Microsoft Azure, Google Cloud vai Yandex.Cloud.
Kas jauns par Å”o? 2020. gadÄ nekas no tÄ.
Koncepcija bez servera
Tas, kas patieÅ”Äm jauns tirgÅ« 2020. gadÄ, ir risinÄjumi bez servera vai bez servera.
MÄÄ£inÄÅ”u paskaidrot, ko tas nozÄ«mÄ, izmantojot parastÄ pakalpojuma vai aizmugurprogrammas piemÄru.
Lai izvietotu parastu aizmugurprogrammu, mÄs iegÄdÄjamies vai nomÄjam serveri, iekopÄjam tajÄ kodu, publicÄjam galapunktu ÄrpusÄ un regulÄri maksÄjam par Ä«ri, elektrÄ«bu un datu centra pakalpojumiem. Å Ä« ir standarta shÄma.
Vai ir kÄds cits veids? Izmantojot pakalpojumus bez serveriem, jÅ«s varat.
Kas ir Ŕīs pieejas uzmanÄ«bas centrÄ: nav servera, nav pat virtuÄlas instances nomas mÄkonÄ«. Lai izvietotu pakalpojumu, kopÄjiet kodu (funkcijas) repozitorijÄ un publicÄjiet to galapunktÄ. Tad mÄs vienkÄrÅ”i maksÄjam par katru Ŕīs funkcijas izsaukumu, pilnÄ«bÄ ignorÄjot aparatÅ«ru, kurÄ tÄ tiek izpildÄ«ta.
MÄÄ£inÄÅ”u ilustrÄt Å”o pieeju ar attÄliem.
KlasiskÄ izvietoÅ”ana. Mums ir serviss ar noteiktu slodzi. MÄs izvirzÄm divus gadÄ«jumus: fiziskos serverus vai gadÄ«jumus AWS. ÄrÄjie pieprasÄ«jumi tiek nosÅ«tÄ«ti uz Ŕīm instancÄm un apstrÄdÄti.
KÄ redzams bildÄ, serveri netiek izmesti vienÄdi. Viens ir 100% izmantots, ir divi pieprasÄ«jumi, un viens ir tikai 50% - daļÄji dÄ«kstÄvÄ. Ja pienÄk nevis trÄ«s pieprasÄ«jumi, bet 30, tad visa sistÄma nespÄs tikt galÄ ar slodzi un sÄks palÄninÄties.
IzvietoÅ”ana bez serveriem. Bez servera vidÄ Å”Ädam pakalpojumam nav gadÄ«jumu vai serveru. Ir noteikts apsildÄmo resursu kopums - mazi sagatavoti Docker konteineri ar izvietotu funkciju kodu. SistÄma saÅem ÄrÄjos pieprasÄ«jumus, un katram no tiem bezservera ietvars izceļ nelielu konteineru ar kodu: apstrÄdÄ Å”o konkrÄto pieprasÄ«jumu un nogalina konteineru.
Viens pieprasÄ«jums - viens konteiners pacelts, 1000 pieprasÄ«jumu - 1000 konteineri. Un izvietoÅ”ana aparatÅ«ras serveros jau ir mÄkoÅpakalpojumu sniedzÄja darbs. To pilnÄ«bÄ paslÄpj bezserveru sistÄma. Å ajÄ koncepcijÄ mÄs maksÄjam par katru zvanu. PiemÄram, dienÄ atnÄca viens zvans ā maksÄjÄm par vienu zvanu, miljons atnÄca minÅ«tÄ ā maksÄjÄm par miljonu. Vai arÄ« tas notiek sekundÄ.
Bezvalsts funkcijas publicÄÅ”anas koncepcija ir piemÄrota bezvalsts pakalpojumam. Un, ja jums ir nepiecieÅ”ams (Å”tata) statusfull pakalpojums, mÄs pakalpojumam pievienojam datu bÄzi. Å ajÄ gadÄ«jumÄ, kad runa ir par darbu ar stÄvokli, katra statusa pilnÄ funkcija vienkÄrÅ”i raksta un nolasa no datu bÄzes. TurklÄt no jebkura no trÄ«s raksta sÄkumÄ aprakstÄ«to veidu datu bÄzes.
KÄds ir visu Å”o datu bÄzu kopÄjais ierobežojums? TÄs ir pastÄvÄ«gi izmantota mÄkoÅa vai aparatÅ«ras servera (vai vairÄku serveru) izmaksas. NeatkarÄ«gi no tÄ, vai mÄs izmantojam klasisku vai pÄrvaldÄ«tu datu bÄzi, vai mums ir Devops un administrators vai nav, mÄs joprojÄm maksÄjam par aparatÅ«ru, elektrÄ«bu un datu centra nomu 24 stundas diennaktÄ«. Ja mums ir klasiska bÄze, mÄs maksÄjam par saimnieku un vergu. Ja tÄ ir ļoti noslogota sadalÄ«ta datu bÄze, mÄs maksÄjam par 7, 10 vai 20 serveriem, un mÄs maksÄjam pastÄvÄ«gi.
PastÄvÄ«gi rezervÄtu serveru klÄtbÅ«tne izmaksu struktÅ«rÄ iepriekÅ” tika uztverta kÄ nepiecieÅ”ams ļaunums. TradicionÄlajÄm datu bÄzÄm ir arÄ« citas grÅ«tÄ«bas, piemÄram, savienojumu skaita ierobežojumi, mÄrogoÅ”anas ierobežojumi, Ä£eogrÄfiski sadalÄ«ta vienprÄtÄ«ba - tos var kaut kÄ atrisinÄt noteiktÄs datubÄzÄs, bet ne visas uzreiz un ne ideÄli.
Bez serveru datubÄze - teorija
2020. gada jautÄjums: vai ir iespÄjams datubÄzi padarÄ«t arÄ« bez servera? Visi ir dzirdÄjuÅ”i par bezserveru aizmuguri... mÄÄ£inÄsim padarÄ«t datubÄzi bez servera?
Tas izklausÄs dÄ«vaini, jo datu bÄze ir pilnvÄrtÄ«gs pakalpojums, kas nav Ä«paÅ”i piemÄrots infrastruktÅ«rai bez serveriem. TajÄ paÅ”Ä laikÄ datu bÄzes stÄvoklis ir ļoti liels: gigabaiti, terabaiti un analÄ«tiskajÄs datu bÄzÄs pat petabaiti. To nav tik vienkÄrÅ”i pacelt vieglos Docker konteineros.
No otras puses, gandrÄ«z visÄs mÅ«sdienu datubÄzÄs ir milzÄ«gs daudzums loÄ£ikas un komponentu: transakcijas, integritÄtes koordinÄcija, procedÅ«ras, relÄciju atkarÄ«bas un daudz loÄ£ikas. Diezgan lielai datubÄzes loÄ£ikai pietiek ar nelielu stÄvokli. Gigabaitus un terabaitus tieÅ”i izmanto tikai neliela daļa no datu bÄzes loÄ£ikas, kas iesaistÄ«ta tieÅ”Ä vaicÄjumu izpildÄ.
AttiecÄ«gi ideja ir Å”Äda: ja daļa loÄ£ikas pieļauj bezpavalstniecÄ«bas izpildi, kÄpÄc gan nesadalÄ«t bÄzi Stateful un BezvalstniecÄ«bas daļÄs.
Bez servera OLAP risinÄjumiem
ApskatÄ«sim, kÄ varÄtu izskatÄ«ties datu bÄzes sadalÄ«Å”ana daļÄs ar statusu un bezvalsts, izmantojot praktiskus piemÄrus.
PiemÄram, mums ir analÄ«tiska datu bÄze: ÄrÄjie dati (sarkanais cilindrs kreisajÄ pusÄ), ETL process, kas ielÄdÄ datus datu bÄzÄ, un analÄ«tiÄ·is, kas nosÅ«ta datu bÄzei SQL vaicÄjumus. Å Ä« ir klasiska datu noliktavas darbÄ«bas shÄma.
Å ajÄ shÄmÄ ETL nosacÄ«ti tiek veikts vienu reizi. Tad pastÄvÄ«gi jÄmaksÄ par serveriem, kuros darbojas datubÄze ar ETL aizpildÄ«tiem datiem, lai bÅ«tu uz ko nosÅ«tÄ«t vaicÄjumus.
ApskatÄ«sim alternatÄ«vu pieeju, kas ieviesta AWS Athena Serverless. Nav pastÄvÄ«gi paredzÄtas aparatÅ«ras, kurÄ tiek glabÄti lejupielÄdÄtie dati. TÄ vietÄ:
- LietotÄjs iesniedz SQL vaicÄjumu Athena. Athena optimizÄtÄjs analizÄ SQL vaicÄjumu un metadatu krÄtuvÄ (Metadati) meklÄ konkrÄtus datus, kas nepiecieÅ”ami vaicÄjuma izpildei.
- OptimizÄtÄjs, pamatojoties uz savÄktajiem datiem, lejupielÄdÄ nepiecieÅ”amos datus no ÄrÄjiem avotiem pagaidu krÄtuvÄ (pagaidu datu bÄzÄ).
- LietotÄja SQL vaicÄjums tiek izpildÄ«ts pagaidu krÄtuvÄ, un rezultÄts tiek atgriezts lietotÄjam.
- Pagaidu krÄtuve ir notÄ«rÄ«ta un resursi tiek atbrÄ«voti.
Å ajÄ arhitektÅ«rÄ mÄs maksÄjam tikai par pieprasÄ«juma izpildes procesu. Nav pieprasÄ«jumu - nav izmaksu.
Šī ir darba pieeja un tiek ieviesta ne tikai Athena Serverless, bet arī Redshift Spectrum (AWS).
Athena piemÄrs parÄda, ka datu bÄze bez serveriem darbojas reÄlos vaicÄjumos ar desmitiem un simtiem terabaitu datu. Simtiem terabaitu prasÄ«s simtiem serveru, taÄu mums par tiem nav jÄmaksÄ ā mÄs maksÄjam par pieprasÄ«jumiem. Katra pieprasÄ«juma Ätrums ir (ļoti) zems salÄ«dzinÄjumÄ ar specializÄtÄm analÄ«tiskÄm datu bÄzÄm, piemÄram, Vertica, taÄu mÄs nemaksÄjam par dÄ«kstÄves periodiem.
Å Äda datu bÄze ir piemÄrota retiem analÄ«tiskiem ad-hoc vaicÄjumiem. PiemÄram, kad mÄs spontÄni nolemjam pÄrbaudÄ«t hipotÄzi par kÄdu milzÄ«gu datu apjomu. AtÄna ir lieliski piemÄrota Å”iem gadÄ«jumiem. RegulÄriem pieprasÄ«jumiem Å”Äda sistÄma ir dÄrga. Å ajÄ gadÄ«jumÄ saglabÄjiet datus keÅ”atmiÅÄ kÄdÄ specializÄtÄ risinÄjumÄ.
Bez servera OLTP risinÄjumiem
IepriekÅ”ÄjÄ piemÄrÄ tika aplÅ«koti OLAP (analÄ«tiskie) uzdevumi. Tagad apskatÄ«sim OLTP uzdevumus.
IedomÄsimies mÄrogojamu PostgreSQL vai MySQL. Izveidosim parasto pÄrvaldÄ«to instanci PostgreSQL vai MySQL ar minimÄliem resursiem. Kad instance saÅems lielÄku slodzi, pievienosim papildu replikas, kurÄm sadalÄ«sim daļu no lasÄ«Å”anas slodzes. Ja nav pieprasÄ«jumu vai ielÄdes, mÄs izslÄdzam kopijas. PirmÄ instance ir galvenais, bet pÄrÄjÄs ir kopijas.
Å Ä« ideja tiek Ä«stenota datu bÄzÄ ar nosaukumu Aurora Serverless AWS. Princips ir vienkÄrÅ”s: pieprasÄ«jumus no ÄrÄjÄm lietojumprogrammÄm pieÅem starpniekserveru flote. Redzot slodzes pieaugumu, tas pieŔķir skaitļoÅ”anas resursus no iepriekÅ” uzsildÄ«tÄm minimÄlajÄm instancÄm - savienojums tiek izveidots pÄc iespÄjas ÄtrÄk. GadÄ«jumu atspÄjoÅ”ana notiek tÄdÄ paÅ”Ä veidÄ.
AurorÄ ir Aurora kapacitÄtes vienÄ«bas, ACU, koncepcija. Tas ir (nosacÄ«ti) gadÄ«jums (serveris). Katrs konkrÄtais ACU var bÅ«t galvenais vai palÄ«gs. Katrai ietilpÄ«bas vienÄ«bai ir sava RAM, procesors un minimÄlais disks. AttiecÄ«gi viens ir meistars, pÄrÄjÄs ir tikai lasÄmas kopijas.
Å o Aurora jaudas vienÄ«bu skaits ir konfigurÄjams parametrs. MinimÄlais daudzums var bÅ«t viens vai nulle (Å”ajÄ gadÄ«jumÄ datu bÄze nedarbojas, ja nav pieprasÄ«jumu).
Kad bÄze saÅem pieprasÄ«jumus, starpniekservera flote palielina Aurora CapacityUnits, palielinot sistÄmas veiktspÄjas resursus. IespÄja palielinÄt un samazinÄt resursus ļauj sistÄmai āžonglÄtā ar resursiem: automÄtiski parÄdÄ«t atseviŔķus ACU (aizstÄt tos ar jauniem) un izvÄrst visus paÅ”reizÄjos izÅemto resursu atjauninÄjumus.
Aurora Serverless bÄze var mÄrogot lasÄ«Å”anas slodzi. Bet dokumentÄcijÄ tas tieÅ”i nav teikts. Var Ŕķist, ka viÅi var pacelt multi-masteri. Nav nekÄdas maÄ£ijas.
Å Ä« datu bÄze ir labi piemÄrota, lai izvairÄ«tos no milzÄ«gu naudas lÄ«dzekļu tÄrÄÅ”anas sistÄmÄm ar neparedzamu piekļuvi. PiemÄram, veidojot MVP vai mÄrketinga vizÄ«tkarÅ”u vietnes, mÄs parasti negaidÄm stabilu slodzi. AttiecÄ«gi, ja nav piekļuves, mÄs par gadÄ«jumiem nemaksÄjam. Kad notiek negaidÄ«ta slodze, piemÄram, pÄc konferences vai reklÄmas kampaÅas, vietni apmeklÄ cilvÄku pūļi un slodze dramatiski palielinÄs, Aurora Serverless automÄtiski uzÅem Å”o slodzi un Ätri savieno trÅ«kstoÅ”os resursus (ACU). Tad konference paiet, visi aizmirst par prototipu, serveri (ACU) kļūst tumÅ”i, un izmaksas nokrÄ«tas lÄ«dz nullei - Ärti.
Å is risinÄjums nav piemÄrots stabilai lielai slodzei, jo tas nesamazina rakstÄ«Å”anas slodzi. Visi Å”ie resursu savienojumi un atvienojumi notiek tÄ sauktajÄ āmÄroga punktÄā - brÄ«dÄ«, kad datu bÄzi neatbalsta transakcija vai pagaidu tabulas. PiemÄram, nedÄļas laikÄ skalas punkts var nenotikt, un bÄze darbojas ar tiem paÅ”iem resursiem un vienkÄrÅ”i nevar paplaÅ”inÄties vai sarukt.
Nav nekÄdas maÄ£ijas ā tÄ ir parasta PostgreSQL. Bet maŔīnu pievienoÅ”anas un atvienoÅ”anas process ir daļÄji automatizÄts.
Bez servera pÄc dizaina
Aurora Serverless ir veca datu bÄze, kas pÄrrakstÄ«ta mÄkonim, lai izmantotu dažas no Serverless priekÅ”rocÄ«bÄm. Un tagad es jums pastÄstÄ«Å”u par bÄzi, kas sÄkotnÄji tika rakstÄ«ta mÄkonim, bezserveru pieejai - Serverless-by-design. Tas tika nekavÄjoties izstrÄdÄts bez pieÅÄmuma, ka tas darbosies uz fiziskajiem serveriem.
Å o bÄzi sauc par Snowflake. Tam ir trÄ«s atslÄgu bloki.
Pirmais ir metadatu bloks. Å is ir Ätrs atmiÅÄ saglabÄts pakalpojums, kas atrisina problÄmas ar droŔību, metadatiem, darÄ«jumiem un vaicÄjumu optimizÄciju (parÄdÄ«ts attÄlÄ pa kreisi).
Otrais bloks ir virtuÄlo skaitļoÅ”anas klasteru kopums aprÄÄ·iniem (attÄlÄ ir zilu apļu komplekts).
TreÅ”ais bloks ir datu uzglabÄÅ”anas sistÄma, kuras pamatÄ ir S3. S3 ir bezdimensiju objektu krÄtuve AWS, lÄ«dzÄ«gi kÄ bezizmÄra Dropbox biznesam.
ApskatÄ«sim, kÄ darbojas Snowflake, pieÅemot aukstu palaiÅ”anu. Tas nozÄ«mÄ, ka ir datu bÄze, tajÄ tiek ielÄdÄti dati, nedarbojas vaicÄjumi. AttiecÄ«gi, ja datu bÄzei nav pieprasÄ«jumu, tad esam pacÄluÅ”i Ätro atmiÅÄ esoÅ”o metadatu pakalpojumu (pirmais bloks). Un mums ir S3 krÄtuve, kurÄ tiek glabÄti tabulu dati, kas sadalÄ«ti tÄ sauktajÄs mikrosadaļÄs. VienkÄrŔības labad: ja tabulÄ ir transakcijas, tad mikropartÄ«cijas ir darÄ«jumu dienas. Katra diena ir atseviŔķs mikrosadalÄ«jums, atseviŔķs fails. Un, kad datubÄze darbojas Å”ajÄ režīmÄ, jÅ«s maksÄjat tikai par vietu, ko aizÅem dati. TurklÄt likme uz vienu sÄdekli ir ļoti zema (jo Ä«paÅ”i Åemot vÄrÄ ievÄrojamo kompresiju). ArÄ« metadatu pakalpojums darbojas pastÄvÄ«gi, taÄu jums nav nepiecieÅ”ams daudz resursu, lai optimizÄtu vaicÄjumus, un pakalpojumu var uzskatÄ«t par koplietoÅ”anas programmatÅ«ru.
Tagad iedomÄsimies, ka lietotÄjs ieradÄs mÅ«su datubÄzÄ un nosÅ«tÄ«ja SQL vaicÄjumu. SQL vaicÄjums nekavÄjoties tiek nosÅ«tÄ«ts Metadatu pakalpojumam apstrÄdei. AttiecÄ«gi, saÅemot pieprasÄ«jumu, Å”is pakalpojums analizÄ pieprasÄ«jumu, pieejamos datus, lietotÄju atļaujas un, ja viss ir kÄrtÄ«bÄ, sastÄda pieprasÄ«juma apstrÄdes plÄnu.
PÄc tam pakalpojums sÄk skaitļoÅ”anas klastera palaiÅ”anu. SkaitļoÅ”anas klasteris ir serveru kopa, kas veic aprÄÄ·inus. Tas ir, tas ir klasteris, kurÄ var bÅ«t 1 serveris, 2 serveri, 4, 8, 16, 32 ā tik daudz, cik vÄlaties. JÅ«s iesniedzat pieprasÄ«jumu, un Ŕī klastera palaiÅ”ana nekavÄjoties sÄkas. Tas tieÅ”Äm aizÅem sekundes.
PÄc tam, kad klasteris ir palaists, jÅ«su pieprasÄ«juma apstrÄdei nepiecieÅ”amie mikrosadaļas tiek kopÄtas klasterÄ« no S3. Tas ir, iedomÄsimies, ka, lai izpildÄ«tu SQL vaicÄjumu, ir nepiecieÅ”ami divi nodalÄ«jumi no vienas tabulas un viens no otrÄs. Å ajÄ gadÄ«jumÄ klasterÄ« tiks kopÄti tikai trÄ«s nepiecieÅ”amie nodalÄ«jumi, nevis visas tabulas. TieÅ”i tÄpÄc, un tieÅ”i tÄpÄc, ka viss atrodas vienÄ datu centrÄ un ir savienots ar ļoti Ätriem kanÄliem, viss pÄrsÅ«tÄ«Å”anas process notiek ļoti Ätri: sekundÄs, ļoti reti minÅ«tÄs, ja vien mÄs nerunÄjam par kÄdiem zvÄrÄ«giem pieprasÄ«jumiem. AttiecÄ«gi mikrosadaļas tiek kopÄtas skaitļoÅ”anas klasterÄ«, un pÄc pabeigÅ”anas Å”ajÄ skaitļoÅ”anas klasterÄ« tiek izpildÄ«ts SQL vaicÄjums. Å Ä« pieprasÄ«juma rezultÄts var bÅ«t viena rindiÅa, vairÄkas rindiÅas vai tabula ā tÄs tiek nosÅ«tÄ«tas lietotÄjam ÄrÄji, lai viÅÅ” to varÄtu lejupielÄdÄt, parÄdÄ«t savÄ BI rÄ«kÄ vai izmantot kÄdÄ citÄ veidÄ.
Katrs SQL vaicÄjums var ne tikai nolasÄ«t apkopojumus no iepriekÅ” ielÄdÄtiem datiem, bet arÄ« ielÄdÄt/Ä£enerÄt jaunus datus datu bÄzÄ. Tas ir, tas var bÅ«t vaicÄjums, kas, piemÄram, ievieto jaunus ierakstus citÄ tabulÄ, kÄ rezultÄtÄ skaitļoÅ”anas klasterÄ« parÄdÄs jauns nodalÄ«jums, kas, savukÄrt, tiek automÄtiski saglabÄts vienÄ S3 krÄtuvÄ.
IepriekÅ” aprakstÄ«tais scenÄrijs no lietotÄja ieraÅ”anÄs lÄ«dz klastera celÅ”anai, datu ielÄdei, vaicÄjumu izpildei, rezultÄtu iegÅ«Å”anai tiek apmaksÄts pÄc likmes par paceltÄ virtuÄlÄ skaitļoÅ”anas klastera, virtuÄlÄs noliktavas izmantoÅ”anas minÅ«tÄm. Likme mainÄs atkarÄ«bÄ no AWS zonas un klastera lieluma, bet vidÄji tas ir daži dolÄri stundÄ. Äetru maŔīnu kopa ir divreiz dÄrgÄka nekÄ divu maŔīnu kopa, un astoÅu maŔīnu kopa joprojÄm ir divreiz dÄrgÄka. AtkarÄ«bÄ no pieprasÄ«jumu sarežģītÄ«bas ir pieejamas 16, 32 iekÄrtas. Bet jÅ«s maksÄjat tikai par tÄm minÅ«tÄm, kad klasteris faktiski darbojas, jo, kad nav pieprasÄ«jumu, jÅ«s kaut kÄ noÅemat rokas, un pÄc 5-10 minÅ«Å”u gaidÄ«Å”anas (konfigurÄjams parametrs) tas pats nodzisÄ«s, atbrÄ«vojiet resursus un kļūstiet brÄ«vi.
PilnÄ«gi reÄlistisks scenÄrijs ir tÄds, ka, nosÅ«tot pieprasÄ«jumu, klasteris uznirst, nosacÄ«ti runÄjot, minÅ«tes laikÄ, tiek skaitÄ«ta vÄl viena minÅ«te, pÄc tam piecas minÅ«tes, lai izslÄgtu, un galu galÄ jÅ«s maksÄjat par septiÅÄm Ŕī klastera darbÄ«bas minÅ«tÄm, un ne mÄneÅ”iem un gadiem.
Pirmais scenÄrijs, kas aprakstÄ«ts, izmantojot Snowflake viena lietotÄja iestatÄ«jumÄ. Tagad iedomÄsimies, ka ir daudz lietotÄju, kas ir tuvÄk reÄlajam scenÄrijam.
PieÅemsim, ka mums ir daudz analÄ«tiÄ·u un Tableau ziÅojumu, kas pastÄvÄ«gi bombardÄ mÅ«su datubÄzi ar lielu skaitu vienkÄrÅ”u analÄ«tisko SQL vaicÄjumu.
TurklÄt, pieÅemsim, ka mums ir izgudrojoÅ”i datu zinÄtnieki, kuri mÄÄ£ina ar datiem izdarÄ«t zvÄrÄ«gas lietas, darbojas ar desmitiem terabaitu, analizÄ miljardus un triljonus datu rindu.
Diviem iepriekÅ” aprakstÄ«tajiem darba slodzes veidiem Snowflake ļauj izveidot vairÄkas neatkarÄ«gas dažÄdas jaudas skaitļoÅ”anas kopas. TurklÄt Ŕīs skaitļoÅ”anas kopas darbojas neatkarÄ«gi, bet ar kopÄ«giem konsekventiem datiem.
Lielam skaitam vieglu vaicÄjumu varat izveidot 2ā3 mazus kopas, katrÄ aptuveni 2 maŔīnas. Å o darbÄ«bu cita starpÄ var Ä«stenot, izmantojot automÄtiskos iestatÄ«jumus. TÄtad jÅ«s sakÄt: "SniegpÄrsliÅa, paceliet mazu puduri. Ja slodze uz to palielinÄs virs noteikta parametra, paceliet lÄ«dzÄ«gu otro, treÅ”o. Kad slodze sÄk kristies, nodzÄsiet lieko. Lai arÄ« cik analÄ«tiÄ·u atnÄktu un sÄktu skatÄ«t atskaites, visiem pietiek resursu.
TajÄ paÅ”Ä laikÄ, ja analÄ«tiÄ·i guļ un neviens neskatÄs pÄrskatus, kopas var pilnÄ«bÄ aptumÅ”ot, un jÅ«s pÄrtraucat par tiem maksÄt.
TajÄ paÅ”Ä laikÄ smagiem vaicÄjumiem (no Data Scientists) varat izveidot vienu ļoti lielu kopu 32 iekÄrtÄm. ArÄ« Å”is klasteris tiks apmaksÄts tikai par tÄm minÅ«tÄm un stundÄm, kad tur darbojas jÅ«su milzu pieprasÄ«jums.
IepriekÅ” aprakstÄ«tÄ iespÄja ļauj sadalÄ«t ne tikai 2, bet arÄ« vairÄku veidu darba slodzi klasteros (ETL, monitorings, atskaites materializÄcija,...).
Apkoposim Snowflake. BÄze apvieno skaistu ideju un praktisku realizÄciju. VietnÄ ManyChat mÄs izmantojam Snowflake, lai analizÄtu visus mÅ«su rÄ«cÄ«bÄ esoÅ”os datus. Mums nav trÄ«s kopu, kÄ tas ir piemÄrÄ, bet gan no 5 lÄ«dz 9, dažÄda izmÄra. Dažiem uzdevumiem mums ir parastÄs 16, 2 un arÄ« ļoti mazas 1 maŔīnas. ViÅi veiksmÄ«gi sadala slodzi un ļauj mums daudz ietaupÄ«t.
Datu bÄze veiksmÄ«gi mÄrogo lasÄ«Å”anas un rakstÄ«Å”anas slodzi. TÄ ir milzÄ«ga atŔķirÄ«ba un milzÄ«gs izrÄviens salÄ«dzinÄjumÄ ar to paÅ”u āAuroraā, kas nesa tikai lasÄ«Å”anas slodzi. Snowflake ļauj palielinÄt rakstÄ«Å”anas slodzi, izmantojot Ŕīs skaitļoÅ”anas klasterus. Tas ir, kÄ jau minÄju, ManyChat mÄs izmantojam vairÄkus klasterus, mazie un Ä«paÅ”i mazie klasteri galvenokÄrt tiek izmantoti ETL, datu ielÄdei. Un analÄ«tiÄ·i jau dzÄ«vo uz vidÄjiem klasteriem, kurus ETL slodze absolÅ«ti neietekmÄ, tÄpÄc viÅi strÄdÄ Ä¼oti Ätri.
AttiecÄ«gi datu bÄze ir labi piemÄrota OLAP uzdevumiem. TomÄr diemžÄl tas vÄl nav piemÄrojams OLTP darba slodzÄm. PirmkÄrt, Ŕī datu bÄze ir kolonnveida ar visÄm no tÄ izrietoÅ”ajÄm sekÄm. OtrkÄrt, pati pieeja, kad katram pieprasÄ«jumam, ja nepiecieÅ”ams, izceļ skaitļoÅ”anas klasteri un pÄrpludina to ar datiem, diemžÄl vÄl nav pietiekami Ätra OLTP ielÄdei. Sekunžu gaidÄ«Å”ana OLAP uzdevumiem ir normÄla parÄdÄ«ba, bet OLTP uzdevumiem tas ir nepieÅemami; 100 ms bÅ«tu labÄk vai 10 ms bÅ«tu vÄl labÄk.
Kopsavilkums
DatubÄze bez servera ir iespÄjama, sadalot datu bÄzi bezvalstniecÄ«bas un statusa daļÄs. JÅ«s, iespÄjams, pamanÄ«jÄt, ka visos iepriekÅ” minÄtajos piemÄros Stateful daļa, nosacÄ«ti runÄjot, ir mikrosadalÄ«jumu glabÄÅ”ana S3, un Stateless ir optimizÄtÄjs, kas strÄdÄ ar metadatiem, risina droŔības problÄmas, kuras var izvirzÄ«t kÄ neatkarÄ«gus vieglus bezvalstnieku pakalpojumus.
SQL vaicÄjumu izpildi var uztvert arÄ« kÄ vieglÄ stÄvokļa pakalpojumus, kas var parÄdÄ«ties bezservera režīmÄ, piemÄram, Snowflake skaitļoÅ”anas klasteri, lejupielÄdÄt tikai nepiecieÅ”amos datus, izpildÄ«t vaicÄjumu un āizietā.
Bezserveru ražoÅ”anas lÄ«meÅa datu bÄzes jau ir pieejamas lietoÅ”anai, tÄs strÄdÄ. Å Ä«s datu bÄzes bez serveriem jau ir gatavas OLAP uzdevumu veikÅ”anai. DiemžÄl OLTP uzdevumiem tie tiek izmantoti... ar niansÄm, jo āāir ierobežojumi. No vienas puses, tas ir mÄ«nuss. Bet, no otras puses, Ŕī ir iespÄja. IespÄjams, kÄds no lasÄ«tÄjiem atradÄ«s veidu, kÄ padarÄ«t OLTP datubÄzi pilnÄ«gi bez servera, bez Aurora ierobežojumiem.
Ceru, ka jums tas likÄs interesanti. Bez servera ir nÄkotne :)
Avots: www.habr.com