PĂ«rshĂ«ndetje tĂ« gjithĂ«ve! Emri im Ă«shtĂ« Golov Nikolai. MĂ« parĂ« kam punuar nĂ« Avito dhe pĂ«r gjashtĂ« vjet kam udhĂ«hequr Data Platform, qĂ« do tĂ« thotĂ« se kam pasur tĂ« bĂ«j me tĂ« gjitha bazat e tĂ« dhĂ«nave: analitike (Vertica, ClickHouse), tĂ« rrjedhĂ«s dhe OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). GjatĂ« kĂ«saj kohe kam mĂ«suar shumĂ« pĂ«r bazat e tĂ« dhĂ«nave â tĂ« ndryshme dhe tĂ« pazakonta, si dhe pĂ«r rastet e pazakonta tĂ« pĂ«rdorimit tĂ« tyre.
Tani punoj nĂ« ManyChat. NĂ« thelb, ky Ă«shtĂ« njĂ« start-up â i ri, ambicioz dhe me ritme tĂ« shpejta rritjeje. Dhe kur sapo hyra nĂ« kompaninĂ«, u shfaq njĂ« pyetje klasike: "ĂfarĂ« duhet tĂ« marr njĂ« start-up tĂ« ri nga tregu i SGBD-ve dhe bazave tĂ« tĂ« dhĂ«nave?".
Në këtë artikull, të bazuar në paraqitjen time në , do të përgjigjem në këtë pyetje. Versioni video i paraqitjes është i disponueshëm në .
Baza të njohura të dhënash të vitit 2020
Jemi në vitin 2020, shikova përreth dhe pashë tre lloje bazash të dhënash.
Lloji i parĂ« â bazat klasike OLTP: PostgreSQL, SQL Server, Oracle, MySQL. Ato janĂ« shkruar shumĂ« kohĂ« mĂ« parĂ«, por ende janĂ« relevante sepse janĂ« tĂ« njohura mirĂ« pĂ«r komunitetin e zhvilluesve.
Lloji i dytĂ« â bazat nga vitet e "zero". Ata po pĂ«rpiqeshin tĂ« largohej nga modelet klasike duke hequr dorĂ« nga SQL, strukturat tradicionale dhe ACID, pĂ«rmes shtimit tĂ« sharding tĂ« integruar dhe karakteristikave tĂ« tjera tĂ«rheqĂ«se. NĂ« kĂ«tĂ« mĂ«nyrĂ«, janĂ« Cassandra, MongoDB, Redis ose Tarantool. TĂ« gjitha kĂ«to zgjidhje kĂ«rkonin tĂ« ofronin diçka thelbĂ«sore tĂ« re nĂ« treg dhe zinin vendin e tyre, pasi u treguan jashtĂ«zakonisht tĂ« pĂ«rshtatshme pĂ«r disa detyra. KĂ«to baza do t'i quaja me termin e gjerĂ« NOSQL.
Isha nĂ« pĂ«rfundim tĂ« dekadĂ«s sĂ« parĂ«, dhe me bazat NOSQL ishim mĂ«suar; dhe bota, sipas mendimit tim, bĂ«ri hapin tjetĂ«r â nĂ« drejtimin e bazave tĂ« menaxhuara. KĂ«to baza kanĂ« njĂ« kernel tĂ« njĂ«jtĂ« si bazat klasike OLTP ose NoSQL tĂ« reja. Por ato nuk kanĂ« nevojĂ« pĂ«r DBA dhe DevOps dhe operojnĂ« nĂ« harduer tĂ« menaxhuar nĂ« cloud. PĂ«r zhvilluesin, kjo Ă«shtĂ« 'thjesht njĂ« bazĂ«', e cila funksionon diku, dhe mĂ«nyra se si Ă«shtĂ« instaluar nĂ« server, kush e konfiguroi serverin dhe kush e pĂ«rditĂ«son, nuk i intereson askujt.
Shembuj të tillë bazash:
- AWS RDS â mbĂ«shtetje e menaxhuar mbi PostgreSQL/MySQL.
- DynamoDB â njĂ« alternativĂ« AWS e bazave tĂ« tipit document, ngjan me Redis dhe MongoDB.
- Amazon Redshift â njĂ« bazĂ« analitike e menaxhuar.
Në thelb, këto janë baza të vjetra, por të ngritura në një mjedis të menaxhuar, pa nevojën për të punuar me harduer.
Vërejtje. Shembujt janë marrë për mjedisin AWS, por ekzistojnë edhe analoge në Microsoft Azure, Google Cloud, ose Yandex.Cloud.
ĂfarĂ« ka tĂ« re? NĂ« vitin 2020 nuk ka asgjĂ« tĂ« re.
Koncepti Serverless
Ajo që është vërtet e re në treg në vitin 2020 janë zgjidhjet serverless ose pa server.
Do të përpiqem të shpjegoj çfarë do të thotë kjo me një shembull të një shërbimi të zakonshëm ose aplikacioni backend.
Për të vendosur një aplikacion të zakonshëm backend, blejmë ose marrim me qira një server, kopjojmë kodin përsipër, publikojmë endpoint-in për të jashtmen dhe paguajmë rregullisht për qiranë, energjinë elektrike dhe shërbimet e qendrës së të dhënave. Kjo është skema standarde.
A ka ndonjë mënyrë tjetër? Me shërbimet serverless ka.
Cila është thelbi i këtij qasjes: nuk ka server, as madje një qira të instance virtuale në cloud. Për të vendosur një shërbim, kopjojmë kodin (funksionet) në depo dhe publikojmë endpoint-in për të jashtmen. Pastaj thjesht paguajmë për çdo thirrje të kësaj funksioni, duke e injoruar krejtësisht harduerin ku kjo ekzekutohet.
Do të përpiqem të ilustroj këtë qasje me figura.
Deploy klasik. Ne kemi një shërbim me një ngarkesë të caktuar. Që të dy instancat: serverët fizikë ose instancat në AWS. Këto instanca marrin kërkesa të jashtme, të cilat përpunohen atje.
Siç shihet nĂ« figurĂ«, serverĂ«t janĂ« pĂ«rdorur nĂ« mĂ«nyrĂ« tĂ« ndryshme. NjĂ«ra Ă«shtĂ« pĂ«rdorur 100%, ka dy kĂ«rkesa, ndĂ«rsa tjetra vetĂ«m 50% â pjesĂ«risht pushim. NĂ«se vijnĂ« jo tri kĂ«rkesa, por 30, atĂ«herĂ« e gjithĂ« sistemi nuk do tĂ« jetĂ« nĂ« gjendje tĂ« pĂ«rballojĂ« ngarkesĂ«n dhe do tĂ« fillojĂ« tĂ« ngadalĂ«sohet.
Konsolidimi pa server. NĂ« njĂ« ambient pa server, njĂ« shĂ«rbim i tillĂ« nuk ka instanca dhe serverĂ«. Ka njĂ« pusht tĂ« caktuar burimesh tĂ« pĂ«rgatitura â enĂ« tĂ« vogla Docker tĂ« pĂ«rgatitura me kodin e funksionit tĂ« shpĂ«rndarĂ«. Sistemi merr kĂ«rkesat e jashtme dhe pĂ«r secilĂ«n prej tyre, korniza pa server ngre njĂ« enĂ« tĂ« vogĂ«l me kodin: pĂ«rpunon saktĂ«sisht kĂ«tĂ« kĂ«rkesĂ« dhe vret enĂ«n.
NjĂ« kĂ«rkesĂ« â njĂ« kontejner i ngritur, 1000 kĂ«rkesa â 1000 kontejnerĂ«. Dhe pĂ«rdorimi i serverĂ«ve fizikĂ« â kjo Ă«shtĂ« punĂ« e ofruesve tĂ« cloud. Ajo Ă«shtĂ« plotĂ«sisht e fshehur nga skema pa server. NĂ« kĂ«tĂ« koncept, ne paguajmĂ« pĂ«r çdo thirrje. PĂ«r shembull, erdhi njĂ« thirrje nĂ« ditĂ« â paguajmĂ« pĂ«r njĂ« thirrje, erdhi njĂ« milion nĂ« minutĂ« â paguajmĂ« pĂ«r njĂ« milion. Ose nĂ« sekondĂ«, kjo ndodh gjithashtu.
Koncepti i publikimit të funksionit pa server është i përshtatshëm për një shërbim stateless. Por nëse ju nevojitet një shërbim statefull, atëherë i shtojmë një bazë të dhënash shërbimit. Në këtë rast, kur arrijmë në punën me state, secila funksion statefull thjesht shkruan dhe lexon nga baza e të dhënave. Dhe kjo nga një bazë të dhënash të cilën mund ta përfshijmë nga ndonjë nga tre llojet e përshkruara në fillim të artikullit.
Cili është kufizimi i përgjithshëm i të gjitha këtyre bazave? Këto janë shpenzimet për serverin cloud ose harduerin e përdorur vazhdimisht (ose disa servera). Nuk ka rëndësi nëse përdorim një bazë klasike apo të menaxhuar, nëse kemi DevOps dhe administratorë apo jo, prapë paguajmë 24/7 për harduerin, energjinë elektrike dhe qiranë e qendrës së të dhënave. Nëse kemi një bazë klasike, paguajmë për master dhe slave. Nëse kemi një bazë të sharduar me ngarkesë të lartë - paguajmë për 10, 20 ose 30 servera dhe paguajmë vazhdimisht.
Prania e serverëve të rezervuar vazhdimisht në strukturën e shpenzimeve më parë perceptohej si një e keqe e pashmangshme. Bazat normale kanë edhe vështirësi të tjera, si kufizimet në numrin e lidhjeve, kufizimi i shkallëzimit, konsensusi gjeo-distribues - ato mund të zgjidhen në disa bazat të caktuara, por jo të gjitha njëherësh dhe jo në mënyrë perfekte.
Baza e të dhënave pa server - teoria
Pyetja e vitit 2020: a mund të bëhet një bazë të dhënash gjithashtu pa server? Të gjithë e kanë dëgjuar për backend-in pa server... po le të provojmë ta bëjmë një bazë të dhënash pa server?
Kjo tinguj si të çuditshme, sepse baza e të dhënave është një shërbim statefull, i papërshtatshëm për infrastrukturën serverless. Ndërkohë, edhe stoku në bazën e të dhënave është shumë i madh: gigabajtë, terabajtë, dhe në bazat analitike madje petabajtë. Nuk është aq e lehtë ta ngrish atë në kontejnerë të lehtë Docker.
Nga ana tjetër, praktikisht të gjitha bazat moderne përmbajnë një numër të madh logjikash dhe komponentësh: transaksione, ruajtje integriteti, procedura, varësi relacionale dhe shumë logjikë. Një pjese të madhe të logjikës së bazës i nevojitet një state i vogël. Gigabajtë dhe terabajtë përdoren direkt vetëm nga një pjesë e vogël e logjikës së bazës, e lidhur me ekzekutimin e menjëhershëm të pyetjeve.
Prandaj, ideja është: nëse një pjesë e logjikës lejon një ekzekutim stateless, pse të mos ndajmë bazën në pjesë Stateful dhe Stateless.
Serverless për zgjidhje OLAP
Le të shohim se si mund të duket ndarja e bazës së të dhënave në pjesë Stateful dhe Stateless me shembuj praktik.
Për shembull, kemi një bazë të dhënash analitike: të dhënat e jashtme (cilindri i kuq majtas), procesi ETL që ngarkon të dhënat në bazë, dhe analisti që dërgon pyetje SQL në bazë. Kjo është skema klasike e punës së një depo të dhënash.
Në këtë skemë, një herë kryhet ETL. Pastaj, duhet të paguani vazhdimisht për serverët ku ruhet baza me të dhënat e ngarkuara nga ETL, për të pasur diçka për të dërguar pyetje.
Le të shqyrtojmë një qasje alternative, të zbatuar në bazën AWS Athena Serverless. Këtu nuk ka hardware të dedikuar për të ruajtur të dhënat e ngarkuara. Në vend të kësaj:
- Përdoruesi dërgon një pyetje SQL në Athena. Optimizuesi i Athena analizon pyetjen SQL dhe kërkon në depozitën e metadata (Metadata) të dhënat e caktuara të nevojshme për të kryer pyetjen.
- Optimizuesi, mbi bazën e të dhënave të mbledhura, ngarkon të dhënat e nevojshme nga burimet e jashtme në një depo të përkohshme (një databazë të përkohshme).
- Në depozitën e përkohshme kryhet pyetja SQL nga përdoruesi, rezultati i kthehet përdoruesit.
- Depozita e përkohshme pastrohet, burimet lirohen.
NĂ« kĂ«tĂ« arkitekturĂ«, ne paguajmĂ« vetĂ«m pĂ«r procesin e ekzekutimit tĂ« pyetjes. Nuk ka pyetje â nuk ka shpenzime.
Ky është një qasje funksionale, e cila zbatohet jo vetëm në Athena Serverless, por edhe në Redshift Spectrum (në AWS).
NĂ« shembullin e Athena, duket se databaza Serverless funksionon me kĂ«rkesa reale me dhjetĂ«ra dhe qindra terabajt tĂ« dhĂ«nash. PĂ«r qindra terabajt do tĂ« nevojiten qindra serverĂ«, por ne nuk duhet tĂ« paguajmĂ« pĂ«r ta â paguajmĂ« vetĂ«m pĂ«r kĂ«rkesat. ShpejtĂ«sia e çdo kĂ«rkese Ă«shtĂ« (shumĂ«) e ulĂ«t nĂ« krahasim me databazat analitike tĂ« specializuara si Vertica, por nuk paguajmĂ« pĂ«r periudhat e papunĂ«sisĂ«.
Kjo databazë është e aplikueshme për kërkesat analitike ad-hoc të rralla. Për shembull, kur ne vendosim të kontrollojmë një hipotezë mbi një sasi të madhe të dhënash. Për këto raste, Athena është ideale. Për kërkesat e rregullta, një sistem i tillë bëhet i kushtueshëm. 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 shqyrtuan detyra OLAP (analitike). Tani le të shqyrtojmë detyra OLTP.
Le tĂ« pĂ«rshkruajmĂ« njĂ« PostgreSQL ose MySQL nĂ« shkallĂ«. Le tĂ« ngremĂ« njĂ« instancĂ« tĂ« menaxhuar PostgreSQL ose MySQL me burime minimale. Kur instanca tĂ« ketĂ« njĂ« ngarkesĂ« mĂ« tĂ« madhe, do tĂ« lidhim replikat shtesĂ«, ku do tĂ« shpĂ«rndajmĂ« njĂ« pjesĂ« tĂ« ngarkesĂ«s lexuese. NĂ«se nuk ka kĂ«rkesa dhe ngarkesĂ« â do tĂ« çaktivizojmĂ« replikat. Instanca e parĂ« Ă«shtĂ« master, ndĂ«rsa tĂ« tjerat janĂ« replika.
Kjo ide Ă«shtĂ« e realizuar nĂ« bazĂ«n e tĂ« dhĂ«nave tĂ« quajtur Aurora Serverless AWS. Parimi Ă«shtĂ« i thjeshtĂ«: kĂ«rkesat nga aplikacionet e jashtme pranohen nga flota e proxy. Duke parĂ« rritjen e ngarkesĂ«s, ai ndan burime llogaritĂ«se nga instancat minimale tĂ« pĂ«rgatitura paraprakisht â lidhja realizohet sa mĂ« shpejt tĂ« jetĂ« e mundur. Ăaktivizimi i instancave ndodh gjithashtu nĂ« atĂ« mĂ«nyrĂ«.
Brenda Aurora ka konceptin e NjĂ«sisĂ« sĂ« Kapacitetit Aurora, ACU. Kjo Ă«shtĂ« (nĂ« njĂ« kuptim) â njĂ« instancĂ« (server). Ădo ACU konkret mund tĂ« jetĂ« master ose slave. Ădo NjĂ«si Kapaciteti ka memorien e tij operuese, procesorin dhe diskun minimal. PĂ«r rrjedhojĂ«, njĂ« master, tĂ« tjerat janĂ« replika vetĂ«m pĂ«r lexim.
Numri i këtyre Njësive të Kapacitetit Aurora në punë është një parametr i konfiguruar. Numri minimal mund të jetë një ose zero (në këtë rast, baza nuk punon nëse nuk ka kërkesa).
Kur baza merr kërkesa, flota proxy aktivizon Njësitë e Kapacitetit Aurora, duke rritur burimet e sistemit. Mundësia për të rritur dhe zvogëluar burimet lejon sistemin të "gjonglojë" burimet: të dërgojë automatikisht Njësitë e veçanta ACU (duke i zëvendësuar ato me të reja) dhe të aplikojë të gjitha përditësimet e aktualizuara në burimet e dërguara.
Baza Aurora Serverless mund të skalojë ngarkesën lexuese. Por në dokumentacion kjo nuk thuhet qartë. Mund të krijohet iluzioni se ata mund të aktivizojnë multi-master. Nuk ka asnjë magji në këtë.
Kjo bazĂ« Ă«shtĂ« mjaft e pĂ«rshtatshme pĂ«r tĂ« mos shpenzuar shumĂ« para pĂ«r sisteme me akses tĂ« paparashikuar. PĂ«r shembull, kur krijojmĂ« MVP ose faqe marketingu, zakonisht nuk presim ngarkesĂ« tĂ« qĂ«ndrueshme. Prandaj, nĂ« mungesĂ« akses, ne nuk paguajmĂ« pĂ«r instancat. Kur papritur ndodh ngarkesa, pĂ«r shembull, pas njĂ« konference ose fushate reklamimi, turma e njerĂ«zve hyn nĂ« faqen dhe ngarkesa rritet ndjeshĂ«m, Aurora Serverless automatikisht e pranon kĂ«tĂ« ngarkesĂ« dhe lidhet shpejt me burimet e nevojshme (ACU). MĂ« pas, konferenca kalon, tĂ« gjithĂ« e harrojnĂ« prototipin, serverĂ«t (ACU) fikĂ«n, dhe shpenzimet bien nĂ« zero â shumĂ« e pĂ«rshtatshme.
Ky zgjidhje nuk Ă«shtĂ« e pĂ«rshtatshme pĂ«r ngarkesa tĂ« larta dhe tĂ« qĂ«ndrueshme, sepse nuk din tĂ« shkallĂ«zojĂ« ngarkesĂ«n e shkrimit. TĂ« gjitha kĂ«to lidhje dhe ç lidhje burimesh ndodhin nĂ« momentin e ashtuquajtur 'scale point' â momenti kur databaza nuk mbahet nga njĂ« transaksion, nuk mbahen tabela tĂ« pĂ«rkohshme. PĂ«r shembull, gjatĂ« njĂ« jave scale point mund tĂ« mos ndodhi, dhe databaza punon me tĂ« njĂ«jtat burime dhe thjesht nuk mund tĂ« vazhdojĂ« as tĂ« zgjerohĂ«t, as tĂ« tĂ«rheqĂ«.
Nuk ka magji â ky Ă«shtĂ« njĂ« PostgreSQL i zakonshĂ«m. Por procesi i shtimit tĂ« makinave dhe çaktivizimi Ă«shtĂ« pjesĂ«risht i automatizuar.
Serverless me dizajn
Aurora Serverless Ă«shtĂ« njĂ« bazĂ« e vjetĂ«r, e riparĂ« pĂ«r re, pĂ«r tĂ« pĂ«rdorur avantazhet e veçanta Serverless. Tani do tĂ« flas pĂ«r bazĂ«n qĂ« nga fillimi Ă«shtĂ« shkruar pĂ«r re, pĂ«r qasjen serverless â Serverless-by-design. Ajo Ă«shtĂ« zhvilluar menjĂ«herĂ« pa supozimin se do tĂ« funksionojĂ« nĂ« serverĂ« fizikĂ«.
Kjo bazë quhet Snowflake. Ajo ka tre blloqe kryesore.
E para â Ă«shtĂ« blloku i metadatave. Kjo Ă«shtĂ« njĂ« shĂ«rbim i shpejtĂ« in-memory, qĂ« zgjidh çështjet me sigurinĂ«, metadatĂ«n, transaksionet, optimizimin e pyetjeve (nĂ« ilustrimin nĂ« tĂ« majtĂ«).
Blloku i dytĂ« â Ă«shtĂ« njĂ« shumĂ«llojshmĂ«ri klasteresh virtuale pĂ«r llogaritje (nĂ« ilustrim â njĂ« grup rrethesh blu).
Blloku i tretĂ« â Ă«shtĂ« sistemi i ruajtjes sĂ« tĂ« dhĂ«nave mbi bazĂ«n S3. S3 Ă«shtĂ« njĂ« magazinĂ« objektesh pa kufi nĂ« AWS, diçka si njĂ« Dropbox pa kufij pĂ«r biznesin.
Le tĂ« shohim se si funksionon Snowflake, duke supozuar njĂ« fillim tĂ« ftohtĂ«. Pra, baza ekziston, tĂ« dhĂ«nat janĂ« ngarkuar nĂ« tĂ«, nuk ka kĂ«rkesash aktive. KĂ«shtu qĂ«, nĂ«se nuk ka kĂ«rkesa pĂ«r bazĂ«n, ne kemi ngritur njĂ« shĂ«rbim tĂ« shpejtĂ« Metadata nĂ« memorie (blloku i parĂ«). Dhe kemi njĂ« depo S3, ku ndodhen tĂ« dhĂ«nat e tabelave, tĂ« ndara nĂ« ato qĂ« quhen mikroparti. PĂ«r thjeshtĂ«si: nĂ«se tabela pĂ«rmban transaksione, mikroparti janĂ« ditĂ«t e transaksioneve. Ădo ditĂ« Ă«shtĂ« njĂ« mikroparti e veçantĂ«, njĂ« skedar i veçantĂ«. Dhe kur baza punon nĂ« kĂ«tĂ« mĂ«nyrĂ«, ju paguani vetĂ«m pĂ«r hapĂ«sirĂ«n qĂ« zĂ«nĂ« tĂ« dhĂ«nat. PĂ«r mĂ« tepĂ«r, tarifa pĂ«r hapĂ«sirĂ«n Ă«shtĂ« shumĂ« e ulĂ«t (sidomos duke marrĂ« parasysh kompresimin e konsiderueshĂ«m). ShĂ«rbimi i metadatas gjithashtu funksionon vazhdimisht, por pĂ«r optimizimin e kĂ«rkesave nuk nevojiten shumĂ« burime, dhe shĂ«rbimi mund tĂ« konsiderohet zhvillimsa-burim tĂ« kushtit tĂ« lirĂ«.
Tani imagjinoni që një përdorues ka ardhur në bazën tonë dhe ka hedhur një kërkesë SQL. Kërkesa SQL menjëherë dërgohet për përpunim në shërbimin Metadata. Kështu, pasi merr kërkesën, ky shërbim analizon kërkesën, të dhënat e disponueshme, dhe autorizimet e përdoruesit dhe, nëse gjithçka shkon mirë, përgatit një plan për përpunimin e kërkesës.
MĂ« pas, shĂ«rbimi fillon aktivizimin e klasterit tĂ« llogaritjeve. Klasteri i llogaritjeve Ă«shtĂ« njĂ« klaster serverash qĂ« kryejnĂ« llogaritje. Kjo do tĂ« thotĂ« se mund tĂ« pĂ«rmbajĂ« 1 server, 2 servera, 4, 8, 16, 32 â sa tĂ« doni. Ju dĂ«rgoni njĂ« kĂ«rkesĂ« dhe menjĂ«herĂ« fillohet aktivizimi i kĂ«tij klasteri. Realisht, kjo zgjat disa sekonda.
Pas kĂ«saj, pasi klasteri ka nisur, mikro-particionet qĂ« nevojiten pĂ«r tĂ« pĂ«rpunuar kĂ«rkesĂ«n tuaj fillojnĂ« tĂ« kopjohen nga S3 nĂ« klaster. DomethĂ«nĂ«, le tĂ« supozojmĂ« se pĂ«r tĂ« ekzekutuar njĂ« SQL kĂ«rkesĂ«, nevojiten dy partiçione nga njĂ« tabelĂ« dhe njĂ« nga tjetra. NĂ« kĂ«tĂ« rast, vetĂ«m tre partiçione tĂ« nevojshme do tĂ« kopjohen nĂ« klaster, dhe jo tĂ« gjitha tabelat nĂ« tĂ«rĂ«si. PikĂ«risht 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, gjithĂ« procesi i transferimit ndodhet shumĂ« shpejt: pĂ«r sekonda, rrallĂ« herĂ« â pĂ«r minuta, nĂ«se bĂ«het fjalĂ« pĂ«r kĂ«rkesa tĂ« jashtĂ«zakonshme. PĂ«rputhshĂ«m, mikro-particionet kopjohen nĂ« klasterin e llogaritjes, dhe, pas pĂ«rfundimit, kĂ«rkesa SQL ekzekutohet nĂ« kĂ«tĂ« klaster. Rezultati i kĂ«saj kĂ«rkese mund tĂ« jetĂ« njĂ« rresht, disa rreshta ose njĂ« tabelĂ« â ato dĂ«rgohen jashtĂ« pĂ«rdoruesit, nĂ« mĂ«nyrĂ« qĂ« ai ta eksportojĂ«, ta shfaqĂ« nĂ« mjetin e tij BI, ose ta pĂ«rdorĂ« ndryshe.
Ădo kĂ«rkesĂ« SQL mund tĂ« jo vetĂ«m tĂ« lidhĂ« agregatĂ«t nga tĂ« dhĂ«nat e ngarkuara mĂ« parĂ«, por gjithashtu tĂ« ngarkojĂ«/formojĂ« tĂ« dhĂ«na tĂ« reja nĂ« bazĂ«. Kjo do tĂ« thotĂ« se kjo mund tĂ« jetĂ« njĂ« kĂ«rkesĂ« qĂ«, pĂ«r shembull, kryen inserimin e shĂ«nimeve tĂ« reja nĂ« njĂ« tabelĂ« tjetĂ«r, e cila çon nĂ« krijimin e njĂ« ndarje tĂ« re nĂ« klasĂ«n kompjuterike, qĂ«, nga ana e saj, ruhet automatikisht nĂ« depozitat e vetme S3.
Skenari i përshkruar më sipër, nga ardhja e përdoruesit deri te ngritja e klashtërëve, ngarkimi i të dhënave, ekzekutimi i kërkesave, marrja e rezultateve, këtë e paguani sipas tarifës për minutat e përdorimit të klashtërës virtuale të llogaritur, warehouse virtual. Tarifa variolon në varësi të zonës AWS dhe madhësisë së klashtërës, por, në mesatare, është disa dollarë në orë. Një klashtër me katër makina është dyfish më e shtrenjtë se një me dy makina, ndërsa një me tetë makina është dyfish më e shtrenjtë se ajo me katër. Disponohen opsione nga 16, 32 makina, në varësi të kompleksitetit të kërkesave. Por paguani vetëm për ato minuta kur klashtëria është në punë, sepse kur s'ka kërkesa, ju siç bëni heqjen dorë, dhe pas 5-10 minutash pritjeje (parametër i përshtatshëm) ai automatikisht do të ndalet, do të lirojë burimet dhe do të bëhet falas.
ĂshtĂ« krejtĂ«sisht e mundur skenari, ku ju dĂ«rgoni njĂ« kĂ«rkesĂ«, klashtĂ«ria shfaqet, po tĂ« themi, pĂ«r njĂ« minutĂ«, njĂ« minutĂ« tjetĂ«r ajo llogarit, mĂ« pas pesĂ« minuta pĂ«r fikje, dhe nĂ« fund paguani vetĂ«m pĂ«r shtatĂ« minuta tĂ« punĂ«s sĂ« kĂ«saj klashtre, e jo pĂ«r muaj e vite.
Skenari i parë përshkroi përdorimin e Snowflake në një variant për një përdorues. Tani le të imagjinojmë se ka shumë përdorues, që është më afër një skenari real.
Le të supozojmë se kemi shumë analistë dhe raporte Tableau, të cilët vazhdimisht bombardojnë bazën tonë me një sasi të madhe kërkesh analitike SQL të thjeshta.
Përveç kësaj, le të supozojmë se kemi Data Scientists të zellshëm, që përpiqen të bëjnë gjëra monstruoze me të dhënat, të operojnë me dhjetëra Terabajt, analizohet miliarda dhe triliona rreshta të dhënash.
Për llojet e ngarkesave të përshkruara më sipër, Snowflake lejon ngritjen e disa klasterëve të llogaritjes të pavarur me fuqi të ndryshme. Dhe këta klasterë llogaritës punojnë në mënyrë të pavarur, por me të dhëna të përbashkëta të harmonizuara.
Për një numër të madh kërkesash të lehta, mund të krijoni 2-3 klastera të vegjël, secili me përmasat, për ngarkesa të përafërta, nga 2 makina. Ky funksionim është i realizueshëm, përfshirë edhe përmes konfigurimeve automatik. Kështu, thoni: "Snowflake, ngrit një klaster të vogël. Nëse ngarkesa mbi të kalon një parametër të caktuar, ngrit një të dytë, të tretë. Kur ngarkesa fillon të bie, ndalo të tepërta." Kështu, pavarësisht nëse sa analistë vijnë dhe fillojnë të shqyrtojnë raportet, të gjithë kanë mjaft burime.
Në të njëjtën kohë, nëse analistët flenë dhe askush nuk po sheh raportet, klasterat mund të fikën plotësisht, dhe kështu ndaloni pagesën për to.
Për kërkesa të rënda (nga Data Scientists), mund të krijoni një klaster shumë të madh me përmasat e përafërta 32 makina. Ky klaster gjithashtu do të paguhet vetëm për ato minuta dhe orë kur aty funksionon kërkesa juaj gjigande.
MundĂ«sia e pĂ«rshkruar mĂ« sipĂ«r lejon ndarjen midis klasterave jo vetĂ«m pĂ«r 2, por edhe pĂ«r mĂ« shumĂ« lloje ngarkesash (ETL, monitorim, materializimi i raporteve,âŠ).
Le të bëjmë një përmbledhje të Snowflake. Baza kombinon një ide të bukur me një realizim funksional. Në ManyChat ne përdorim Snowflake për analizimin e të gjitha të dhënave të disponueshme. Ne kemi nga 5 deri në 9 klasterë të ndryshëm në vend të tre, siç është në shembull. Kemi klasterë me 16 makina, me 2 makina, dhe madje edhe super-të vogla me 1 makinë për disa detyra. Ata shpërndajnë ngarkesën me sukses dhe na lejojnë të kursejmë shumë.
Baza e Snowflake e shkallëzon me sukses ngarkesën lexuese dhe shkruese. Ky është një ndryshim i madh dhe një përparim i madh në krahasim me "Aurorën", e cila përballonte vetëm ngarkesën lexuese. Snowflake lejon të shkallëzohet edhe ngarkesa shkruese me këto klasterë llogaritës. Pra, siç e përmenda, ne në ManyChat përdorim disa klasterë; klasterët e vegjël dhe super-të vegjël përdoren kryesisht për ETL, për ngarkimin e të dhënave. Ndërsa analistët punojnë në klasterët mesatarë, të cilët nuk preken nga ngarkesa ETL, prandaj punojnë shumë shpejt.
KĂ«shtu, baza Ă«shtĂ« e pĂ«rshtatur mirĂ« pĂ«r detyrat OLAP. MegjithatĂ«, pĂ«r ngarkesat OLTP, ajo ende nuk Ă«shtĂ« e aplikueshme. SĂ« pari, kjo bazĂ« Ă«shtĂ« kolonale, me tĂ« gjitha pasojat qĂ« vijnĂ« nga kjo. SĂ« dyti, vetĂ« qasja, kur pĂ«r çdo kĂ«rkesĂ« ngatĂ«rroni njĂ« kluster llogaritĂ«s dhe e mbushni atĂ« me tĂ« dhĂ«na, fatkeqĂ«sisht, pĂ«r ngarkesat OLTP nuk Ă«shtĂ« ende mjaft e shpejtĂ«. Disa sekonda pritjeje pĂ«r detyrat OLAP janĂ« tĂ« pranuara, ndryshe pĂ«r detyrat OLTP â Ă«shtĂ« e papranueshme, do tĂ« ishte mĂ« mirĂ« 100 ms, dhe akoma mĂ« mirĂ« â 10 ms.
PĂ«rfundimi
Baza e të dhënave pa server është e mundur përmes ndarjes së bazës në pjesë Stateless dhe Stateful. Ju, sigurisht, keni vënë re se në të gjitha shembujt e paraqitur, pjesa Stateful është, në njëfarë mënyre, ruajtja e mikro-particioneve në S3, ndërsa Stateful është optimizuesi, punimi me metadatat, përpunimi i çështjeve të sigurisë, të cilat mund të ngrihen si shërbime të lehta Stateless të pavarura.
Kryerja e kërkesave SQL gjithashtu mund të perceptohet si shërbime me një gjendje të lehtë, të cilat mund të ngrihen në modalitetin pa server, si klasteret llogaritus Snowflake, për të shkarkuar vetëm të dhënat që nevojiten, për të kryer kërkesën dhe "të shuajnë".
Baza serverless të nivelit të prodhimit janë tani të disponueshme për përdorim dhe funksionojnë. Këto baza serverless janë tashmë të gatshme për t'u përballur me detyra OLAP. Megjithatë, për detyrat OLTP ato përdoren⊠me disa nuanca, pasi ka kufizime. Nga njëra anë, kjo është një mangësi. Por, nga ana tjetër, kjo është një mundësi. Ndoshta ndonjë nga lexuesit do të gjejë një mënyrë për ta bërë bazën OLTP plotësisht serverless, pa kufizime Aurora.
Shpresoj se ka qenĂ« interesante pĂ«r ju. PĂ«r njĂ« tĂ« ardhme serverless đ
Burimi: habr.com
