Përshëndetje të gjithëve! Quhem Nikolai Golov. Më parë kam punuar në Avito dhe për gjashtë vjet kam drejtuar Data Platform, që do të thotë se kam punuar me të gjitha bazat: analitike (Vertica, ClickHouse), rrjedhëse dhe OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Gjatë kësaj kohe kam mësuar shumë për bazat e të dhënave - nga më të ndryshmet dhe të çuditshmet, dhe për raste të pazakonta të përdorimit të tyre.
Tani punoj në ManyChat. Në thelb, është një start-up - i ri, ambicioz dhe në rritje të shpejtë. Dhe kur sapo fillova në kompaninë, u shfaq pyetja klasike: "Cfarë duhet të zgjedhë një start-up të ri nga tregu i DBMS dhe bazat e të dhënave?".
Në këtë artikull, i cili është i bazuar në fjalimin tim në , do të përgjigjem në këtë pyetje. Versioni në video të fjalimit është i disponueshëm në .
Baza të njohura të të dhënave të vitit 2020
Jemi në vitin 2020, shqyrtova rreth meje dhe pashë tre tipe DB.
Tipi i parë - bazat OLTP klasike: PostgreSQL, SQL Server, Oracle, MySQL. Ato janë shkruar kohë përpara, por përmbajnë ende rëndësi, sepse janë të njohura mirë nga komuniteti i zhvilluesve.
Tipi i dytë - bazat e 'viteve të zero'. Ato përpiqeshin të iknin nga shabllonat klasike përmes heqjes dorë nga SQL, strukturat tradicionale dhe ACID, përmes shtimit të ndarjes së brendshme dhe karakteristika të tjera tërheqëse. Për shembull, kjo është Cassandra, MongoDB, Redis ose Tarantool. Të gjitha këto zgjidhje donin të ofronin diçka krejtësisht të re për tregun dhe zuri pozita të veçanta, sepse u treguan jashtëzakonisht të dobishme në disa detyra. Këto bazat do t'i quaj me termin e përgjithshëm NOSQL.
'Vitet e zero' përfunduan, u mësuam me bazat NOSQL, dhe bota, nga pikëpamja ime, bëri hapin e ardhshëm - në bazat e menaxhuara. Këto baza kanë thelbin e njëjtë si bazat OLTP klasike ose NoSQL të reja. Por ato nuk kanë nevojë për DBA dhe DevOps dhe funksionojnë në hardware të menaxhuar në cloud. Për një zhvillues, kjo është 'thjesht një bazë', që punon diku, dhe si është instaluar në server, kush e ka konfiguruar serverin dhe kush e përditëson atë, askujt nuk i intereson.
Shembuj të tillë të bazave janë:
- AWS RDS - një mbështetje e menaxhuar mbi PostgreSQL/MySQL.
- DynamoDB - analogja AWS e bazës së dhënave të tipit document, ngjan me Redis dhe MongoDB.
- Amazon Redshift - një bazë analitike e menaxhuar.
Në thelb janë bazat e vjetra, por të ngritura në një mjedis të menaxhuar, pa nevojën për të punuar me hardware.
Shënim. Shembujt janë të marrë për mjedisin AWS, por analogët e tyre ekzistojnë gjithashtu në Microsoft Azure, Google Cloud, ose Yandex.Cloud.
Cilët janë të rinjtë për këtë? Në vitin 2020, asgjë nga kjo.
Koncepsioni Serverless
VĂ«rtet njĂ« e re nĂ« tregun e vitit 2020 â janĂ« zgjidhjet pa serverĂ«.
Do të përpiqem të shpjegoj se çfarë do të thotë kjo me shembuj nga një shërbim i zakonshëm ose aplikacion backend.
Për të implementuar një aplikacion backend të zakonshëm, blejmë ose marrim me qira një server, kopjojmë kodin aty, publikojmë një endpoint dhe paguajmë rregullisht për qiranë, elektricitetin dhe shërbimet e qendrës së të dhënave. Kjo është skema standarde.
A mund të bëhet ndryshe? Me shërbimet pa serverë, po.
Cila është magjia e këtij qasja: nuk ka server, as edhe qira për një instance virtuale në re. Për të implementuar një shërbim, kopjojmë kodin (funksionet) në një depo dhe publikojmë një endpoint. Më pas, thjesht paguajmë për çdo thirrje të kësaj funksioni, duke injoruar krejtësisht harduerin ku ekzekutohet.
Do të përpiqem ta ilustroj këtë qasje me pamje.
Implementimi klasik. Ne kemi një shërbim me një ngarkesë të caktuar. Aktivizojmë dy instance: serverë fizikë ose instanca në AWS. Këto instance drejtojnë kërkesat e jashtme që trajtohen aty.
Siç duket nĂ« figurĂ«, serverĂ«t janĂ« tĂ« shfrytĂ«zuar nĂ« mĂ«nyrĂ« tĂ« ndryshme. NjĂ«ri Ă«shtĂ« shfrytĂ«zuar nĂ« 100%, aty ka dy kĂ«rkesa, ndĂ«rsa njĂ« tjetĂ«r vetĂ«m nĂ« 50% â Ă«shtĂ« pjesĂ«risht nĂ« pritje. NĂ«se vijnĂ« jo tre kĂ«rkesa, por 30, atĂ«herĂ« e gjithĂ« sistemi nuk do tĂ« pĂ«rballojĂ« ngarkesĂ«n dhe do tĂ« fillojĂ« tĂ« ngadalĂ«sohet.
Implementimi pa serverĂ«. NĂ« njĂ« ambient pa serverĂ«, ky shĂ«rbim nuk ka as instanca dhe as serverĂ«. Ka njĂ« pool tĂ« caktuar burimesh tĂ« pĂ«rgatitura â kontejnerĂ« tĂ« vegjĂ«l Docker tĂ« pĂ«rgatitur me kodin e funksionit. Sistemi merr kĂ«rkesa tĂ« jashtme dhe pĂ«r secilĂ«n prej tyre, framework-u pa serverĂ« aktivizon njĂ« kontejner tĂ« vogĂ«l me kodin: e trajton kĂ«tĂ« kĂ«rkesĂ« dhe shkatĂ«rron kontejnerin.
NjĂ« kĂ«rkesĂ« â njĂ« kontejner i aktivizuar, 1000 kĂ«rkesa â 1000 kontejnerĂ«. Dhe implementimi nĂ« serverĂ«t fizikĂ« Ă«shtĂ« punĂ« e ofruesit tĂ« shĂ«rbimeve nĂ« re. Kjo Ă«shtĂ« plotĂ«sisht e fshehur nga framework-u pa serverĂ«. NĂ« kĂ«tĂ« koncept, ne paguajmĂ« pĂ«r çdo thirrje. PĂ«r shembull, nĂ«se vjen njĂ« thirrje nĂ« ditĂ« â ne paguajmĂ« pĂ«r njĂ« thirrje, nĂ«se vijnĂ« njĂ« milion nĂ« minutĂ« â paguajmĂ« pĂ«r njĂ« milion. Ose nĂ« sekondĂ«, kjo ndodh gjithashtu.
Koncepcioni i publikimit të funksioneve pa server përkon me një shërbim stateless. Por nëse keni nevojë për një shërbim statefull, atëherë i shtojmë një bazë të dhënash shërbimit. Në këtë rast, kur arrihet puna me state, çdo funksion statefull thjesht shkruan dhe lexon nga baza e të dhënave. Dhe mund të jetë nga çdo lloj base, nga ato tre lloje të përmendura në fillim të artikullit.
Cili Ă«shtĂ« kufizimi i pĂ«rgjithshĂ«m pĂ«r tĂ« gjitha kĂ«to baza? KĂ«to janĂ« shpenzimet pĂ«r njĂ« server tĂ« pĂ«rhershĂ«m nĂ« cloud ose njĂ« server fizik (apo disa servera). Nuk ka rĂ«ndĂ«si nĂ«se pĂ«rdorim njĂ« bazĂ« klasike apo tĂ« menaxhuar, nĂ«se ka DevOps dhe administratorĂ« apo jo, gjithsesi paguajmĂ« 24 orĂ« nĂ« ditĂ« pĂ«r pajisjet, elektricitetin dhe qiranĂ« e qendrĂ«s sĂ« tĂ« dhĂ«nave. NĂ«se kemi njĂ« bazĂ« klasike, paguajmĂ« pĂ«r master dhe slave. NĂ«se Ă«shtĂ« njĂ« bazĂ« e ngarkuar me sharding â paguajmĂ« pĂ«r 10, 20 ose 30 servera, dhe paguajmĂ« vazhdimisht.
Prania e serverave tĂ« rezervuar pĂ«rherĂ« nĂ« strukturĂ«n e shpenzimeve pĂ«rpara perceptohej si njĂ« e keqe e paevitueshme. Baza tĂ« zakonshme kanĂ« edhe vĂ«shtirĂ«si tĂ« tjera, tĂ« tilla si kufizimet e numrit tĂ« lidhjeve, kufizimi i shkallĂ«zimit, konsensusi gjeo-distribuese â kĂ«to mund tĂ« zgjidhen nĂ« disa baza, por jo tĂ« gjitha njĂ«herĂ«sh dhe jo nĂ« mĂ«nyrĂ« tĂ« pĂ«rsosur.
Baza e tĂ« dhĂ«nave pa server â teori
Pyetja e vitit 2020: a mund të bëjmë një bazë të dhënash gjithashtu pa server? Të gjithë kanë dëgjuar për backend pa server... le të provojmë ta bëjmë gjithashtu bazën e të dhënave pa server.
Kjo duket e çuditshme, sepse një bazë e të dhënave është një shërbim statefull, që nuk është shumë i përshtatshëm për infrastrukturën pa server. Për më tepër, gjithashtu, state-i në bazën e të dhënave është shumë i madh: gigabajtë, terabajtë, dhe në bazat analitike madje edhe petabajtë. Nuk është aq e lehtë ta ngritni atë në kontejnerë të lehtë Docker.
Nga ana tjetĂ«r, pothuajse tĂ« gjitha bazat moderne â janĂ« njĂ« sasi e madhe logjike dhe komponentĂ«sh: transaksionet, ruajtja e integritetit, procedurat, varĂ«sitĂ« rrelacionale dhe shumĂ« logjikĂ«. NjĂ« pjesĂ« e madhe e logjikĂ«s sĂ« bazĂ«s sĂ« tĂ« dhĂ«nave kĂ«rkon njĂ« state tĂ« vogĂ«l. GigabajtĂ« dhe terabajtĂ« pĂ«rdoren drejtpĂ«rdrejt vetĂ«m nga njĂ« pjesĂ« e vogĂ«l e logjikĂ«s sĂ« bazĂ«s sĂ« tĂ« dhĂ«nave, e lidhur me ekzekutimin e menjĂ«hershĂ«m tĂ« pyetjeve.
Prandaj, ideja është: nëse një pjesë e logjikës lejon ekzekutimin stateless, pse të mos e ndajmë bazën në pjesë Stateful dhe Stateless.
Serverless për zgjidhjet OLAP
Le të shikojmë se si mund të duket ndarja e bazës së të dhënave në pjesë Stateful dhe Stateless në shembuj praktikë.
Për shembull, ne kemi një bazë të dhënash analitike: të dhënat e jashtme (cilindri i kuq në të majtë), procesi ETL që ngarkon të dhënat në bazë dhe analisti që dërgon kërkesat SQL në bazë. Kjo është një skemë klasike e funksionimit të magazinës së të dhënave.
Në këtë skemë, në një kuptim, ETL ekzekutohet një herë. Më pas duhet të paguash vazhdimisht për serverët, mbi të cilët punon baza me të dhënat e ngarkuara nga ETL, që të ketë ku të dërgosh kërkesat.
Të marrim parasysh një qasje alternative, të realizuar në bazën AWS Athena Serverless. Këtu nuk ka asnjë harduer të caktuar vazhdimisht, mbi të cilin ruhen të dhënat e ngarkuara. Në vend të kësaj:
- Përdoruesi dërgon një kërkesë SQL në Athena. Optimizuesi i Athena analizon kërkesën SQL dhe kërkon në depozitat e metadatos (Metadata) të dhënat specifike të nevojshme për përmbushjen e kërkesës.
- Optimizuesi, mbi bazën e të dhënave të grumbulluara, nxjerr të dhënat e nevojshme nga burimet e jashtme në një depozitë të përkohshme (baza e të dhënave temporale).
- Në depozitën e përkohshme ekzekutohet kërkesa SQL nga përdoruesi dhe rezultati i kthehet përdoruesit.
- Depozita e përkohshme pastron, burimet lirohen.
NĂ« kĂ«tĂ« arkitekturĂ«, ne paguajmĂ« vetĂ«m pĂ«r procesin e ekzekutimit tĂ« kĂ«rkesĂ«s. Nuk ka kĂ«rkesa â nuk ka shpenzime.
Kjo është një qasje funksionale dhe realizohet jo vetëm në Athena Serverless, por edhe në Redshift Spectrum (në AWS).
NĂ« shembujt e Athena shihet se baza e tĂ« dhĂ«nave Serverless funksionon me kĂ«rkesa reale me dhjetĂ«ra dhe qindra Terabajt tĂ« dhĂ«nash. PĂ«r qindra Terabajt do tĂ« nevojiteshin qindra serverĂ«, por ne nuk kemi nevojĂ« tĂ« paguajmĂ« pĂ«r ta â ne paguajmĂ« pĂ«r kĂ«rkesat. ShpejtĂ«sia e çdo kĂ«rkese Ă«shtĂ« (shumĂ«) e ulĂ«t nĂ« krahasim me bazat e dhĂ«nash analitike tĂ« specializuara si Vertica, por pĂ«r kĂ«tĂ« arsye nuk paguajmĂ« pĂ«r periudhat e qĂ«ndrimit.
Një bazë e tillë e të dhënave është e përshtatshme për kërkesa analitike ad-hoc të ralla. Për shembull, kur ne spontanisht vendosim të verifikojmë një hipotezë mbi një volum të madh të të dhënash. Për këto raste Athena është ideale. Për kërkesat e rregullta, një sistem i tillë bëhet i shtrenjtë. Në këtë rast ruani të dhënat në ndonjë zgjidhje të specializuar.
Serverless për zgjidhjet OLTP
Në shembullin e mëparshëm u diskutuan detyrat OLAP (analitike). Tani do të shqyrtojmë detyrat OLTP.
Të imagjinoni një PostgreSQL ose MySQL në shkallëzueshme. Le të ngremë një instancë të menaxhuar të zakonshme PostgreSQL ose MySQL me burime minimale. Kur instanca të përballet me një ngarkesë më të madhe, ne do të lidhim replika të tjera, mbi të cilat do të shpërndajmë një pjesë të ngarkesës lexuese. Nëse nuk ka kërkesash dhe ngarkesash - çaktivizojmë replikat. Instanca e parë është master, ndërsa të tjerat janë replika.
Kjo ide Ă«shtĂ« realizuar nĂ« njĂ« bazĂ« tĂ« quajtur Aurora Serverless AWS. Parimi Ă«shtĂ« i thjeshtĂ«: kĂ«rkesat nga aplikacionet e jashtme pranohen nga flota proxy. Duke parĂ« rritjen e ngarkesĂ«s, ai alokon burime llogaritĂ«se nga instancat minimale tĂ« ngrira paraprakisht - lidhja realizohet sa mĂ« shpejt tĂ« jetĂ« e mundur. Ăaktivizimi i instancave ndodh po ashtu.
Brenda Aurora-s ekziston koncepti i NjĂ«sisĂ« sĂ« Kapacitetit Aurora, ACU. Kjo Ă«shtĂ« (nĂ« mĂ«nyrĂ« tĂ« kushtezuar) - njĂ« instancĂ« (server). Ădo ACU konkret mund tĂ« jetĂ« master ose slave. Ădo NjĂ«si Kapaciteti ka memorjen e saj tĂ« pĂ«rkohshme, procesorin dhe njĂ« disk minimal. Prandaj, njĂ« master, ndĂ«rsa tjerat janĂ« replika vetĂ«m pĂ«r lexim.
Numri i këtyre Njësive të Kapacitetit Aurora në funksion është një parameter i konfigurable. Numri minimal mund të jetë një ose zero (në këtë rast, baza nuk funksionon nëse nuk ka kërkesa).
Kur baza merr kërkesa, flota proxy ngre Njësitë e Kapacitetit Aurora, duke rritur burimet e sistemit. Mundësia për të rritur dhe ulur burimet lejon sistemit të "llogarisë" burimet: automatikisht të tërheqë ACU të veçanta (në vend të tyre të reja) dhe të aplikojë të gjitha përditësimet aktuale mbi burimet e tërhequra.
Baza Aurora Serverless mund të shkallëzojë ngarkesën lexuese. Por në dokumentacion nuk thuhet drejtpërdrejt për këtë. Mund të krijohet ndjenja se ata mund të ngrejnë multi-master. Nuk ka ndonjë magji këtu.
Kjo bazë është shumë e përshtatshme për të shmangur shpenzimet e mëdha për sisteme me qasje të paqartë. Për shembull, kur krijojmë një MVP ose faqeshëngjyrash marketingu, zakonisht nuk presim një ngarkesë të qëndrueshme. Prandaj, në rast mos qasje, ne nuk paguajmë për instancat. Kur papritmas shfaqet ngarkesa, për shembull pas një konference ose fushate reklamimi, turmat e njerëzve hyjnë në faqe dhe ngarkesa rritet ndjeshëm; Aurora Serverless automatikisht pranon këtë ngarkesë dhe lidh shpejt burimet që mungojnë (ACU). Më pas, konferenca kalon, të gjithë e harrojnë prototipin, serverat (ACU) fikën dhe shpenzimet bien në zero - e përshtatshme.
Ky zgjidhje nuk është e përshtatshme për ngarkesë të lartë të qëndrueshme, sepse ajo nuk di të shkallëzojë ngarkesën e shkrimit. Të gjitha këto lidhje dhe çlodhje burimesh ndodhin në momentin e ashtuquajtur 'scale point' - momenti kur baza nuk mbahet nga transaksionet, as nga tabelat përkohshme. Për shembull, gjatë një jave mund të mos ndodhë scale point dhe baza punon me të njëjtat burime dhe thjesht nuk mund të zgjerë apo të ngushtohet.
Nuk ka magji - ky është PostgreSQL i zakonshëm. Por procesi i shtimit dhe çlodhjes të makinave është pjesërisht automatizuar.
Serverless by design
Aurora Serverless është një bazë e vjetër, e shkruar për në cloud, për të përdorur avantazhet specifike të Serverless. Tani do të flas për një bazë që është projektuar që nga fillimi për në cloud, me qasjen serverless - Serverless-by-design. Ajo është zhvilluar menjëherë pa supozuar se do të funksiononte në serverë fizikë.
Kjo bazë quhet Snowflake. Ajo ka tre blloqe kryesore.
I pari - është blloku i metadatos. Ky është një shërbim i shpejtë në-memory, që zgjidh çështje sigurie, metadatash, transaksionesh dhe optimizimit të kërkesave (në ilustrimin nga e majta).
Blloku i dytë - është një numër i madh i klasterëve virtualë përllogaritës për llogaritjet (në ilustrimin - një grup topash blu).
Blloku i tretë - është sistemi i ruajtjes së të dhënave mbi bazën S3. S3 është një ruajtje objektesh e pandarë në AWS, diçka si një Dropbox i pandarë për biznes.
Le tĂ« shohim se si funksionon Snowflake, duke supozuar njĂ« fillim tĂ« ftohtĂ«. KĂ«shtu qĂ« kemi bazĂ«n, tĂ« dhĂ«nat janĂ« ngarkuar nĂ« tĂ«, por nuk ka kĂ«rkesa tĂ« ekzekutueshme. Prandaj, nĂ«se nuk ka kĂ«rkesa pĂ«r bazĂ«n, ne kemi ngritur njĂ« shĂ«rbim Metadata me shpejtĂ«si tĂ« lartĂ« nĂ« memorie (bloku i parĂ«). Dhe kemi njĂ« depo S3, ku ruhen tĂ« dhĂ«nat e tabelave, tĂ« ndara nĂ« atĂ« qĂ« quhet mikro-partita. Thjesht: nĂ«se tabela pĂ«rmban transaksione, mikro-partita janĂ« ditĂ«t e transaksioneve. Ădo ditĂ« Ă«shtĂ« njĂ« mikro-partitĂ« e veçantĂ«, njĂ« skedar i veçantĂ«. Dhe kur baza punon nĂ« kĂ«tĂ« mod, ju paguani vetĂ«m pĂ«r hapĂ«sirĂ«n e zĂ«nĂ« nga tĂ« dhĂ«nat. Ămimi pĂ«r hapĂ«sirĂ«n Ă«shtĂ« shumĂ« i ulĂ«t (veçanĂ«risht nĂ« marrĂ«veshje me kompresimin e konsiderueshĂ«m). ShĂ«rbimi i metadatave gjithashtu punon vazhdimisht, por pĂ«r optimizimin e kĂ«rkesave nuk kĂ«rkon shumĂ« burime dhe shĂ«rbimi mund tĂ« konsiderohet kushtimisht falas.
Tani imagjinoni se një përdorues i është afruar bazës sonë dhe ka dërguar një kërkesë SQL. Kërkesa SQL menjëherë procedohet në shërbimin Metadata. Pra, pasi merr kërkesën, ky shërbim analizon kërkesën, të dhënat e disponueshme, autorizimet e përdoruesit dhe, nëse gjithçka është në rregull, përgatit një plan për përpunimin e kërkesës.
MĂ« pas, shĂ«rbimi iniciaton aktivizimin e grupit tĂ« llogaritjes. Grupi i llogaritjes Ă«shtĂ« njĂ« grup serverĂ«sh qĂ« kryejnĂ« llogaritjet. KĂ«shtu qĂ« ky grup mund tĂ« pĂ«rmbajĂ« 1 server, 2 serverĂ«, 4, 8, 16, 32 â sa tĂ« dĂ«shironi. Ju dĂ«rgoni kĂ«rkesĂ«n dhe menjĂ«herĂ« fillon aktivizimi i kĂ«tij grupi. Kjo vĂ«rtet merr disa sekonda.
MĂ« pas, pasi klasteri Ă«shtĂ« nisur, mikro-particionet e nevojshme pĂ«r trajtimin e kĂ«rkesĂ«s suaj fillojnĂ« tĂ« kopjohen nga S3 nĂ« klaster. Kjo do tĂ« thotĂ« qĂ«, le tĂ« supozojmĂ«, pĂ«r tĂ« ekzekutuar njĂ« kĂ«rkesĂ« SQL, nevojiten dy partiçione nga njĂ« tabelĂ« dhe njĂ« nga tjetra. NĂ« kĂ«tĂ« rast, nĂ« klaster do tĂ« kopjohen vetĂ«m tre partiçione tĂ« nevojshme, dhe jo tĂ« gjitha tabelat. Pikerisht pĂ«r kĂ«tĂ« arsye dhe pĂ«r shkak se gjithçka ndodhet brenda njĂ« qendre tĂ« dhĂ«nash dhe Ă«shtĂ« e lidhur me kanale shumĂ« tĂ« shpejta, tĂ«rĂ« procesi i transferimit ndodh shumĂ« shpejt: brenda sekondash, shumĂ« rrallĂ« â brenda minutash, nĂ«se nuk bĂ«het fjalĂ« pĂ«r ndonjĂ« kĂ«rkesĂ« monstruoze. PĂ«r rrjedhojĂ«, mikro-particionet kopjohen nĂ« klasterin llogaritĂ«s dhe, pas pĂ«rfundimit, nĂ« kĂ«tĂ« klaster ekzekutohet kĂ«rkesa SQL. Rezultati i kĂ«saj kĂ«rkese mund tĂ« jetĂ« njĂ« rresht, disa rreshta ose njĂ« tabelĂ« â ato dĂ«rgohen jashtĂ« pĂ«r pĂ«rdoruesin, nĂ« mĂ«nyrĂ« qĂ« ai tĂ« mund t'i nxjerrĂ«, t'i shfaqĂ« nĂ« mjetin e BI, ose tĂ« pĂ«rdorĂ« ndonjĂ« mĂ«nyrĂ« tjetĂ«r.
Ădo kĂ«rkesĂ« SQL nuk mund vetĂ«m tĂ« llogarisĂ« agregat nga tĂ« dhĂ«nat e ngarkuara mĂ« parĂ«, por gjithashtu tĂ« ngarkojĂ«/krijojĂ« tĂ« dhĂ«na tĂ« reja nĂ« bazĂ«. Kjo do tĂ« thotĂ« qĂ« mund tĂ« jetĂ« njĂ« kĂ«rkesĂ« qĂ«, pĂ«r shembull, realizon njĂ« insertim nĂ« njĂ« tabelĂ« tjetĂ«r tĂ« shĂ«nimeve tĂ« reja, e cila çon nĂ« shfaqjen e njĂ« partie tĂ« re nĂ« klasterin llogaritĂ«s, e cila, nga ana e saj, automatikisht ruhet nĂ« depozitĂ«n unike S3.
Skenari i përshkruar më sipër, nga ardhja e përdoruesit deri në ngritjes e klasterit, ngarkimi i të dhënave, ekzekutimi i kërkesave, marrja e rezultateve, paguhet sipas tarifës për minutat e përdorimit të klasterit të ngritur virtual, warehouse virtual. Tarifa varion në varësi të zonës AWS dhe madhësisë së klasterit, por, mesatarisht, është disa dollarë në orë. Klasteri me katër makina është dy herë më i shtrenjtë se ai me dy makina, dhe ai me tetë makina është edhe dy herë më i shtrenjtë. Janë të disponueshme variante nga 16, 32 makina, varësisht nga kompleksiteti i kërkesave. Por ju paguani vetëm për minutat kur klasteri është realisht në punë, sepse, kur nuk ka kërkesa, si të thuash, hiqni duar nga tastiera, dhe pas 5-10 minutash pritjeje (parametri i rregullueshëm), ai vetë do të fiket, do të çlirojë burimet dhe do të bëhet falas.
Një skenar absolutisht realist është ai ku ju dërgoni një kërkesë, klasteri shfaqet, mundësisht, për një minutë, dhe për një minutë tjetër ai llogaritet, më pas pesë minuta për të fikur, dhe në fund paguani për shtatë minuta funksionimi të këtij klasteri, dhe jo për muaj dhe vite.
Skenari i parë përshkruante përdorimin e Snowflake në një version për një përdorues. Tani le të imagjinojmë se ka shumë përdorues, që është më afër skenarit real.
Supozoni se kemi shumë analistë dhe raporte Tableau që vazhdimisht bombardojnë bazën tonë me shumë SQL-llogari analitike të thjeshta.
Përveç kësaj, le të supozojmë se kemi DSC (Shkencëtarë të Dhënash) shpikës që përpiqen të bëjnë gjëra të frikshme me të dhënat, duke operuar me dhjetëra Terabajt, analizuar miliarda e triliona rreshtash të dhënash.
Për dy llojet e ngarkesave të përshkruara më sipër, Snowflake lejon ngritjen e disa klasterësh të pavarur të llojeve të ndryshme të fuqisë. Këta klasterë të llogaritjes punojnë pavarësisht, por me të dhëna të përbashkëta të koherente.
Për një sasi të madhe kërkesash të lehta, mund të ngrini 2-3 klasterë të vegjël, me një përmasë, mundësisht, 2 makina secila. Ky veprim është i realizueshëm, gjithashtu, me anë të konfigurimeve automatike. Pra, ju thoni: "Snowflake, ngrit një klaster të vogël. Nëse ngarkesa rritet më shumë se një parametër të caktuar, ngrit një të dytë, të tretë të ngjashëm. Kur ngarkesa të fillojë të bjerë - fikni të tepërtit." Të siguroheni që, pavarësisht nga sa analistë vijnë dhe fillojnë të shikojnë raportet, të gjithë të kenë burime të mjaftueshme.
Në të njëjtën kohë, nëse analistët flenë, dhe raportet nuk shikohen nga askush - klasterët mund të fikën plotësisht dhe ju ndaloni pagesën për ta.
Në të njëjtën kohë, për kërkesa të rënda (nga DSC), mund të ngrini një klaster shumë të madh me një numër të supozuar prej 32 makinash. Ky klaster gjithashtu do të paguhet vetëm për minutat dhe orët kur atje funksionon kërkesa juaj gjigande.
Kjo mundësi e përshkruar më sipër lejon ndarjen sipas klasterëve jo vetëm dy, por edhe më shumë lloje ngarkesash (ETL, monitorim, materializim raporte, ...).
Të bëjmë një përmbledhje për Snowflake. Database kombinon një ide të bukur dhe një implementim funksional. Në ManyChat ne përdorim Snowflake për analitikën e të dhënave që kemi. Ne kemi më shumë se tre grupe, siç është shembulli, nga 5 në 9, me madhësi të ndryshme. Kemi grupe me 16 makinave, 2 makinash, dhe kemi edhe super-të vogla me 1 makinë për disa detyra. Ato shpërndajnë ngarkesën me sukses dhe na lejojnë të kursejmë shumë.
Database me sukses shkallëzon ngarkesën lexuese dhe shkruese. Ky është një ndryshim i Madh dhe një hap i madh përpara krahasuar me "Aurora", e cila trajtonte vetëm ngarkesën lexuese. Snowflake lejon që këto grupe kompjuterike të shkallëzojnë edhe ngarkesën shkruese. Pra, siç përmenda, ne në ManyChat përdorim disa grupe, grupe të vogla dhe super të vogla përdoren kryesisht për ETL, për ngarkimin e të dhënave. Dhe analistët punojnë në grupe mesatare, të cilat nuk preken nga ngarkesa ETL, prandaj punojnë shumë shpejt.
Meqenëse, database është e përshtatshme për detyra OLAP. Ndërkohë, me keqardhje, për ngarkesat OLTP nuk është ende e aplikueshme. Së pari, kjo bazë është kolonuese, me të gjitha pasojat që dalin nga kjo. Së dyti, vetë qasja, kur për çdo kërkesë rritni një grup kompjuterik sipas nevojës dhe e derdhni atë me të dhëna, për fat të keq, për ngarkesat OLTP ende nuk është e mjaftueshme e shpejtë. Sekondat e pritjes për detyrat OLAP janë normale, por për detyrat OLTP - është e papranueshme, do të ishte më mirë 100 ms, dhe akoma më mirë - 10 ms.
PĂ«rfundimi
Database pa server është e mundur përmes ndarjes së bazës së të dhënave në pjesë Stateless dhe Stateful. Ju ndoshta keni vënë re se në të gjitha shembujt e dhënë, pjesa Stateful - është, në terma të qartë, ruajtja e microparticioneve në S3, ndërsa Stateless - është optimizuesi, puna me metadat, trajtimi i pyetjeve të sigurisë, të cilat mund të ngrihen si shërbime të lehta dhe të pavarura Stateless.
Ekzekutimi i kërkesave SQL gjithashtu mund të perceptohet si shërbime me një gjendje të lehtë, të cilat mund të shfaqen në modalitet pa server, si grupet kompjuterike të Snowflake, duke shkarkuar vetëm të dhënat e nevojshme, duke ekzekutuar kërkesën dhe "dukur".
Baza pa serverless e nivelit prodhues është tashmë e disponueshme për t'u përdorur, ata po punojnë. Këto baza serverless janë gati të përballojnë detyrat OLAP. Fatkeqësisht, për detyrat OLTP ato aplikohen⊠me nuanca, sepse ka kufizime. Nga njëra anë, kjo është një disavantazh. Por, nga ana tjetër, kjo është një mundësi. Ndoshta ndonjë prej lexuesve do të gjejë një mënyrë për ta bërë një bazë OLTP plotësisht serverless, pa kufizime Aurora.
Shpresoj qĂ« ju ka interesuar. PĂ«r tĂ« ardhmen Serverless đ
Burimi: habr.com
