Pershendetje te gjitheve! Emri im është Golov Nikolay. Më parë, kam punuar në Avito dhe kam menaxhuar platformën e të dhënave për gjashtë vjet, domethënë kam punuar në të gjitha bazat e të dhënave: analitike (Vertica, ClickHouse), streaming dhe OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Gjatë kësaj kohe, unë u mora me një numër të madh bazash të dhënash - shumë të ndryshme dhe të pazakonta, dhe me raste jo standarde të përdorimit të tyre.
Aktualisht jam duke punuar në ManyChat. Në thelb, ky është një startup - i ri, ambicioz dhe me rritje të shpejtë. Dhe kur u bashkua për herë të parë me kompaninë, lindi një pyetje klasike: "Çfarë duhet të marrë një startup i ri tani nga tregu i DBMS dhe bazës së të dhënave?"
Në këtë artikull, bazuar në raportin tim në , Unë do t'i përgjigjem kësaj pyetjeje. Një version video i raportit është në dispozicion në .
Bazat e të dhënave të njohura 2020
Është viti 2020, shikova përreth dhe pashë tre lloje të bazave të të dhënave.
Lloji i parë - bazat e të dhënave klasike OLTP: PostgreSQL, SQL Server, Oracle, MySQL. Ato janë shkruar shumë kohë më parë, por janë ende të rëndësishme sepse janë kaq të njohura për komunitetin e zhvilluesve.
Lloji i dytë është bazat nga "zero". Ata u përpoqën të largoheshin nga modelet klasike duke braktisur SQL, strukturat tradicionale dhe ACID, duke shtuar ndarjen e integruar dhe veçori të tjera tërheqëse. Për shembull, kjo është Cassandra, MongoDB, Redis ose Tarantool. Të gjitha këto zgjidhje donin t'i ofronin tregut diçka thelbësisht të re dhe zunë vendin e tyre, sepse ato doli të ishin jashtëzakonisht të përshtatshme për detyra të caktuara. Unë do t'i shënoj këto baza të dhënash me termin ombrellë NOSQL.
"Zotat" kanë mbaruar, ne u mësuam me bazat e të dhënave NOSQL dhe bota, nga këndvështrimi im, hodhi hapin tjetër - të bazat e të dhënave të menaxhuara. Këto baza të të dhënave kanë të njëjtin bërthamë si bazat e të dhënave klasike OLTP ose ato të reja NoSQL. Por ata nuk kanë nevojë për DBA dhe DevOps dhe funksionojnë në pajisje të menaxhuara në retë. Për një zhvillues, kjo është "thjesht një bazë" që funksionon diku, por askujt nuk i intereson se si është instaluar në server, kush e konfiguroi serverin dhe kush e përditëson atë.
Shembuj të bazave të të dhënave të tilla:
- AWS RDS është një mbështjellës i menaxhuar për PostgreSQL/MySQL.
- DynamoDB është një analog AWS i një baze të dhënash të bazuar në dokumente, i ngjashëm me Redis dhe MongoDB.
- Amazon Redshift është një bazë të dhënash analitike e menaxhuar.
Këto janë në thelb baza të të dhënave të vjetra, por të ngritura në një mjedis të menaxhuar, pa nevojën për të punuar me harduer.
Shënim. Shembujt janë marrë për mjedisin AWS, por analogët e tyre ekzistojnë gjithashtu në Microsoft Azure, Google Cloud ose Yandex.Cloud.
Çfarë ka të re për këtë? Në vitin 2020, asnjë nga këto.
Koncepti pa server
Ajo që është vërtet e re në treg në vitin 2020 janë zgjidhjet pa server ose pa server.
Do të përpiqem të shpjegoj se çfarë do të thotë kjo duke përdorur shembullin e një shërbimi të rregullt ose aplikacioni mbështetës.
Për të vendosur një aplikacion të rregullt backend, ne blejmë ose marrim me qira një server, kopjojmë kodin në të, publikojmë pikën përfundimtare jashtë dhe paguajmë rregullisht 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ërbime pa server ju mundeni.
Cili është fokusi i kësaj qasjeje: nuk ka server, nuk ka as marrjen me qira të një shembulli virtual në cloud. Për të vendosur shërbimin, kopjoni kodin (funksionet) në depo dhe publikojeni atë në pikën përfundimtare. Pastaj ne thjesht paguajmë për çdo thirrje në këtë funksion, duke injoruar plotësisht harduerin ku ai ekzekutohet.
Do të përpiqem ta ilustroj këtë qasje me foto.
Vendosja klasike. Ne kemi një shërbim me një ngarkesë të caktuar. Ne ngremë dy raste: serverë fizikë ose shembuj në AWS. Kërkesat e jashtme dërgohen në këto instanca dhe përpunohen atje.
Siç mund ta shihni në foto, serverët nuk janë asgjësuar në mënyrë të barabartë. Njëra është 100% e shfrytëzuar, ka dy kërkesa dhe njëra është vetëm 50% - pjesërisht e papunë. Nëse nuk vijnë tre kërkesa, por 30, atëherë i gjithë sistemi nuk do të jetë në gjendje të përballojë ngarkesën dhe do të fillojë të ngadalësohet.
Vendosja pa server. Në një mjedis pa server, një shërbim i tillë nuk ka shembuj ose serverë. Ekziston një grup i caktuar burimesh të nxehta - kontejnerë të vegjël Docker të përgatitur me kod funksioni të vendosur. Sistemi merr kërkesa të jashtme dhe për secilën prej tyre korniza pa server ngre një kontejner të vogël me kod: ai përpunon këtë kërkesë të veçantë dhe e vret kontejnerin.
Një kërkesë - një kontejner i ngritur, 1000 kërkesa - 1000 kontejnerë. Dhe vendosja në serverët e harduerit është tashmë punë e ofruesit të cloud. Ai është plotësisht i fshehur nga korniza pa server. Në këtë koncept ne paguajmë për çdo telefonatë. Për shembull, një telefonatë vinte në ditë - ne paguanim për një telefonatë, një milion erdhën në minutë - ne paguanim për një milion. Ose në një sekondë ndodh edhe kjo.
Koncepti i publikimit të një funksioni pa server është i përshtatshëm për një shërbim pa shtetësi. Dhe nëse keni nevojë për një shërbim (shtetëror) të plotë shtetëror, atëherë ne shtojmë një bazë të dhënash në shërbim. Në këtë rast, kur bëhet fjalë për punën me gjendjen, çdo funksion statefull thjesht shkruan dhe lexon nga baza e të dhënave. Për më tepër, nga një bazë të dhënash e ndonjë prej tre llojeve të përshkruara në fillim të artikullit.
Cili është kufizimi i përbashkët i të gjitha këtyre bazave të të dhënave? Këto janë kostot e një serveri cloud ose hardueri të përdorur vazhdimisht (ose disa serverëve). Nuk ka rëndësi nëse përdorim një bazë të dhënash klasike apo të menaxhuar, nëse kemi Devops dhe një administrator apo jo, ne ende paguajmë për pajisjen, energjinë elektrike dhe marrjen me qira të qendrës së të dhënave 24/7. Nëse kemi një bazë klasike, ne paguajmë për zot dhe skllav. Nëse është një bazë të dhënash e ndarë shumë e ngarkuar, ne paguajmë për 10, 20 ose 30 serverë dhe paguajmë vazhdimisht.
Prania e serverëve të rezervuar përgjithmonë në strukturën e kostos është perceptuar më parë si një e keqe e domosdoshme. Bazat e të dhënave konvencionale kanë gjithashtu vështirësi të tjera, si kufizimet në numrin e lidhjeve, kufizimet e shkallëzimit, konsensusi i shpërndarë gjeografik - ato mund të zgjidhen disi në baza të caktuara të të dhënave, por jo të gjitha menjëherë dhe jo në mënyrë ideale.
Baza e të dhënave pa server - teori
Pyetja e vitit 2020: a është e mundur të bëhet edhe një bazë e të dhënave pa server? Të gjithë kanë dëgjuar për backend-in pa server... le të përpiqemi ta bëjmë bazën e të dhënave pa server?
Kjo tingëllon e çuditshme, sepse baza e të dhënave është një shërbim shtetëror, jo shumë i përshtatshëm për infrastrukturën pa server. Në të njëjtën kohë, gjendja e bazës së të dhënave është shumë e madhe: gigabajt, terabajt, dhe në bazat e të dhënave analitike edhe petabajt. Nuk është aq e lehtë për ta ngritur atë në kontejnerë të lehtë Docker.
Nga ana tjetër, pothuajse të gjitha bazat e të dhënave moderne përmbajnë një sasi të madhe logjike dhe komponentësh: transaksione, koordinim të integritetit, procedura, varësi relacionale dhe shumë logjikë. Për mjaft logjikë të bazës së të dhënave, mjafton një gjendje e vogël. Gigabajt dhe Terabajt përdoren drejtpërdrejt nga vetëm një pjesë e vogël e logjikës së bazës së të dhënave të përfshira në ekzekutimin e drejtpërdrejtë të pyetjeve.
Prandaj, ideja është: nëse një pjesë e logjikës lejon ekzekutimin pa shtetësi, pse të mos e ndajmë bazën në pjesë të shtetësisë dhe pa shtetësi.
Pa server për zgjidhjet OLAP
Le të shohim se si mund të duket prerja e një baze të dhënash në pjesë të shtetësisë dhe pa shtetësi duke përdorur shembuj praktikë.
Për shembull, ne kemi një bazë të dhënash analitike: të dhëna të jashtme (cilindri i kuq në të majtë), një proces ETL që ngarkon të dhënat në bazën e të dhënave dhe një analist që dërgon pyetje SQL në bazën e të dhënave. Kjo është një skemë klasike e funksionimit të depove të të dhënave.
Në këtë skemë, ETL kryhet me kusht një herë. Atëherë duhet të paguani vazhdimisht për serverët në të cilët funksionon baza e të dhënave me të dhëna të mbushura me ETL, në mënyrë që të ketë diçka për të dërguar pyetje.
Le të shohim një qasje alternative të zbatuar në AWS Athena Serverless. Nuk ka asnjë pajisje të dedikuar përgjithmonë në të cilën ruhen të dhënat e shkarkuara. Në vend të kësaj:
- Përdoruesi dërgon një pyetje SQL tek Athena. Optimizuesi Athena analizon pyetjen SQL dhe kërkon në dyqanin e meta të dhënave (Metadata) për të dhënat specifike të nevojshme për të ekzekutuar pyetjen.
- Optimizuesi, bazuar në të dhënat e mbledhura, shkarkon të dhënat e nevojshme nga burime të jashtme në ruajtje të përkohshme (baza e të dhënave e përkohshme).
- Një pyetje SQL nga përdoruesi ekzekutohet në ruajtje të përkohshme dhe rezultati i kthehet përdoruesit.
- Ruajtja e përkohshme pastrohet dhe burimet lirohen.
Në këtë arkitekturë, ne paguajmë vetëm për procesin e ekzekutimit të kërkesës. Asnjë kërkesë - pa kosto.
Kjo është një qasje pune dhe zbatohet jo vetëm në Athena Serverless, por edhe në Redshift Spectrum (në AWS).
Shembulli Athena tregon se baza e të dhënave pa server funksionon në pyetje reale me dhjetëra e qindra Terabajt të dhëna. Qindra Terabajt do të kërkojnë qindra serverë, por ne nuk duhet 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 të dhënave të specializuara analitike si Vertica, por ne nuk paguajmë për periudhat joproduktive.
Një bazë e tillë e të dhënave është e zbatueshme për pyetje të rralla analitike ad-hoc. Për shembull, kur vendosim spontanisht të testojmë një hipotezë mbi një sasi gjigande të dhënash. Athena është perfekte për këto raste. Për kërkesa të rregullta, një sistem i tillë është i shtrenjtë. Në këtë rast, ruajini të dhënat në cache në ndonjë zgjidhje të specializuar.
Pa server për zgjidhjet OLTP
Shembulli i mëparshëm shikonte detyrat OLAP (analitike). Tani le të shohim detyrat OLTP.
Le të imagjinojmë PostgreSQL ose MySQL të shkallëzuar. Le të krijojmë një shembull të rregullt të menaxhuar PostgreSQL ose MySQL me burime minimale. Kur shembulli merr më shumë ngarkesë, ne do të lidhim kopje shtesë në të cilat do të shpërndajmë një pjesë të ngarkesës së leximit. Nëse nuk ka kërkesa ose ngarkesë, ne i fikim kopjet. Shkalla e parë është master, dhe pjesa tjetër janë kopje.
Kjo ide zbatohet në një bazë të dhënash 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 shpërndan burime llogaritëse nga rastet minimale të ngrohura paraprakisht - lidhja bëhet sa më shpejt që të jetë e mundur. Rastet e çaktivizimit ndodhin në të njëjtën mënyrë.
Brenda Aurora ekziston koncepti i Njësisë së Kapacitetit Aurora, ACU. Ky është (me kusht) një shembull (server). Çdo ACU specifike mund të jetë një master ose një skllav. Çdo njësi kapaciteti ka RAM-in e vet, procesorin dhe diskun minimal. Prandaj, njëri është mjeshtër, pjesa tjetër lexohet vetëm kopje.
Numri i këtyre njësive të kapacitetit Aurora që funksionojnë është një parametër i konfigurueshëm. Sasia minimale mund të jetë një ose zero (në këtë rast, baza e të dhënave nuk funksionon nëse nuk ka kërkesa).
Kur baza merr kërkesa, flota proxy rrit Aurora Capacity Units, duke rritur burimet e performancës së sistemit. Aftësia për të rritur dhe ulur burimet i lejon sistemit të "mashtroj" burimet: shfaq automatikisht ACU-të individuale (duke i zëvendësuar ato me të reja) dhe nxjerr të gjitha përditësimet aktuale në burimet e tërhequra.
Baza pa server Aurora mund të shkallëzojë ngarkesën e leximit. Por dokumentacioni nuk e thotë këtë drejtpërdrejt. Mund të duket sikur mund të ngrenë një multi-mjeshtër. Nuk ka magji.
Kjo bazë të dhënash është e përshtatshme për të shmangur shpenzimin e shumave të mëdha parash në sisteme me akses të paparashikueshëm. Për shembull, kur krijojmë faqe MVP ose marketing të kartave të biznesit, zakonisht nuk presim një ngarkesë të qëndrueshme. Prandaj, nëse nuk ka akses, ne nuk paguajmë për shembuj. Kur ndodh një ngarkesë e papritur, për shembull pas një konference ose fushate reklamuese, turma njerëzish vizitojnë sajtin dhe ngarkesa rritet në mënyrë dramatike, Aurora Serverless e merr automatikisht këtë ngarkesë dhe lidh shpejt burimet që mungojnë (ACU). Pastaj konferenca kalon, të gjithë harrojnë prototipin, serverët (ACU) errësohen dhe kostot bien në zero - i përshtatshëm.
Kjo zgjidhje nuk është e përshtatshme për ngarkim të qëndrueshëm sepse nuk e zvogëlon ngarkesën e shkrimit. Të gjitha këto lidhje dhe shkëputje të burimeve ndodhin në të ashtuquajturën "pika e shkallës" - një pikë në kohë kur baza e të dhënave nuk mbështetet nga një transaksion ose tabela të përkohshme. Për shembull, brenda një jave pika e shkallës mund të mos ndodhë, dhe baza punon në të njëjtat burime dhe thjesht nuk mund të zgjerohet ose tkurret.
Nuk ka magji - është PostgreSQL i rregullt. Por procesi i shtimit të makinerive dhe i shkëputjes së tyre është pjesërisht i automatizuar.
Pa server sipas dizajnit
Aurora Serverless është një bazë të dhënash e vjetër e rishkruar për cloud për të përfituar nga disa nga përfitimet e Serverless. Dhe tani do t'ju tregoj për bazën, e cila fillimisht ishte shkruar për cloud, për qasjen pa server - Server-nga-design. Ai u zhvillua menjëherë pa supozimin se do të funksiononte në serverë fizikë.
Kjo bazë quhet Snowflake. Ka tre blloqe kyçe.
E para është një bllok metadata. Ky është një shërbim i shpejtë në memorie që zgjidh problemet me sigurinë, metadatat, transaksionet dhe optimizimin e pyetjeve (treguar në ilustrimin në të majtë).
Blloku i dytë është një grup grupesh kompjuterike virtuale për llogaritjet (në ilustrim ka një grup rrathësh blu).
Blloku i tretë është një sistem i ruajtjes së të dhënave të bazuar në S3. S3 është ruajtje e objekteve pa dimensione në AWS, si Dropbox pa dimensione për biznes.
Le të shohim se si funksionon Snowflake, duke supozuar një fillim të ftohtë. Kjo do të thotë, ekziston një bazë të dhënash, të dhënat ngarkohen në të, nuk ka pyetje të ekzekutimit. Prandaj, nëse nuk ka kërkesa për bazën e të dhënave, atëherë ne kemi ngritur shërbimin e shpejtë të Metadata në memorie (blloku i parë). Dhe ne kemi ruajtjen S3, ku ruhen të dhënat e tabelës, të ndara në të ashtuquajturat mikrondarje. Për thjeshtësi: nëse tabela përmban transaksione, atëherë mikrondarjet janë ditët e transaksioneve. Çdo ditë është një mikrondarje e veçantë, një skedar i veçantë. Dhe kur baza e të dhënave funksionon në këtë mënyrë, ju paguani vetëm për hapësirën e zënë nga të dhënat. Për më tepër, norma për vend është shumë e ulët (sidomos duke marrë parasysh ngjeshjen e konsiderueshme). Shërbimi i meta të dhënave gjithashtu funksionon vazhdimisht, por nuk ju nevojiten shumë burime për të optimizuar pyetjet dhe shërbimi mund të konsiderohet shareware.
Tani le të imagjinojmë që një përdorues erdhi në bazën tonë të të dhënave dhe dërgoi një pyetje SQL. Pyetja SQL dërgohet menjëherë në shërbimin Metadata për përpunim. Prandaj, me marrjen e një kërkese, ky shërbim analizon kërkesën, të dhënat e disponueshme, lejet e përdoruesit dhe, nëse gjithçka është mirë, harton një plan për përpunimin e kërkesës.
Më pas, shërbimi fillon nisjen e grupit kompjuterik. Një grup kompjuterik është një grup serverësh që kryejnë llogaritjet. Kjo do të thotë, ky është një grup që mund të përmbajë 1 server, 2 serverë, 4, 8, 16, 32 - aq sa dëshironi. Ju hedhni një kërkesë dhe nisja e këtij grupi fillon menjëherë. Duhen vërtet sekonda.
Më pas, pasi grupi të ketë filluar, mikrondarjet e nevojshme për të përpunuar kërkesën tuaj fillojnë të kopjohen në grup nga S3. Kjo do të thotë, le të imagjinojmë që për të ekzekutuar një pyetje SQL ju nevojiten dy ndarje nga një tabelë dhe një nga e dyta. Në këtë rast, vetëm tre ndarjet e nevojshme do të kopjohen në grup, dhe jo të gjitha tabelat tërësisht. Kjo është arsyeja pse, dhe pikërisht sepse gjithçka ndodhet brenda një qendre të dhënash dhe lidhet me kanale shumë të shpejta, i gjithë procesi i transferimit ndodh shumë shpejt: në sekonda, shumë rrallë në minuta, përveç nëse flasim për disa kërkesa monstruoze. Në përputhje me rrethanat, mikroparticionet kopjohen në grupin informatikë dhe, pas përfundimit, pyetja SQL ekzekutohet në këtë grup kompjuterik. Rezultati i kësaj kërkese mund të jetë një rresht, disa rreshta ose një tabelë - ato i dërgohen nga jashtë përdoruesit në mënyrë që ai ta shkarkojë atë, ta shfaqë në veglën e tij BI ose ta përdorë atë në ndonjë mënyrë tjetër.
Çdo pyetje SQL jo vetëm që mund të lexojë agregatet nga të dhënat e ngarkuara më parë, por edhe të ngarkojë/gjenerojë të dhëna të reja në bazën e të dhënave. Kjo do të thotë, mund të jetë një pyetje që, për shembull, fut të dhëna të reja në një tabelë tjetër, gjë që çon në shfaqjen e një ndarje të re në grupin informatikë, e cila, nga ana tjetër, ruhet automatikisht në një ruajtje të vetme S3.
Skenari i përshkruar më sipër, nga ardhja e përdoruesit deri te ngritja e grupit, ngarkimi i të dhënave, ekzekutimi i pyetjeve, marrja e rezultateve, paguhet me tarifën e minutave të përdorimit të grupit të llogaritur virtual të ngritur, magazinë virtuale. Shkalla ndryshon në varësi të zonës AWS dhe madhësisë së grupit, por mesatarisht është disa dollarë në orë. Një grup prej katër makinerish është dy herë më i shtrenjtë se një grup prej dy makinerish, dhe një grup prej tetë makinash është ende dy herë më i shtrenjtë. Opsionet e 16, 32 makinave janë në dispozicion, në varësi të kompleksitetit të kërkesave. Por ju paguani vetëm për ato minuta kur grupi po funksionon në të vërtetë, sepse kur nuk ka kërkesa, disi i hiqni duart dhe pas 5-10 minutash pritje (një parametër i konfigurueshëm) do të fiket vetë. lironi burimet dhe bëhuni të lirë.
Një skenar plotësisht realist është kur dërgoni një kërkesë, grupi shfaqet, relativisht, në një minutë, ai numëron një minutë tjetër, pastaj pesë minuta për t'u mbyllur, dhe përfundoni duke paguar për shtatë minuta funksionim të këtij grupi, dhe jo për muaj e vite.
Skenari i parë përshkruhet duke përdorur Snowflake në një mjedis me një përdorues. Tani le të imagjinojmë se ka shumë përdorues, gjë që është më afër skenarit real.
Le të themi se kemi shumë analistë dhe raporte Tableau që bombardojnë vazhdimisht bazën tonë të të dhënave me një numër të madh pyetjesh të thjeshta analitike SQL.
Për më tepër, le të themi se kemi shkencëtarë shpikës të të dhënave që po përpiqen të bëjnë gjëra monstruoze me të dhëna, të operojnë me dhjetëra Terabajt, të analizojnë miliarda e triliona rreshta të dhënash.
Për dy llojet e ngarkesës së punës të përshkruar më sipër, Snowflake ju lejon të krijoni disa grupime të pavarura kompjuterike me kapacitete të ndryshme. Për më tepër, këto grupime kompjuterike punojnë në mënyrë të pavarur, por me të dhëna të përbashkëta të qëndrueshme.
Për një numër të madh pyetjesh të lehta, mund të ngrini 2-3 grupe të vogla, afërsisht 2 makina secila. Kjo sjellje mund të zbatohet, ndër të tjera, duke përdorur cilësimet automatike. Kështu që ju thoni, “Flakë bore, ngri një grup të vogël. Nëse ngarkesa në të rritet mbi një parametër të caktuar, ngrini një të dytë, të tretë të ngjashëm. Kur ngarkesa fillon të ulet, shuajeni tepricën.” Kështu që sado analistë të vijnë dhe të fillojnë të shikojnë raportet, të gjithë kanë burime të mjaftueshme.
Në të njëjtën kohë, nëse analistët janë në gjumë dhe askush nuk i shikon raportet, grupet mund të errësohen plotësisht dhe ju të ndaloni së paguari për to.
Në të njëjtën kohë, për pyetje të rënda (nga Data Scientists), mund të ngrini një grup shumë të madh për 32 makina. Ky grup do të paguhet gjithashtu vetëm për ato minuta dhe orë kur kërkesa juaj gjigante po ekzekutohet atje.
Mundësia e përshkruar më sipër ju lejon të ndani jo vetëm 2, por edhe më shumë lloje të ngarkesës së punës në grupe (ETL, monitorim, materializim raporti,...).
Le të përmbledhim Snowflake. Baza kombinon një ide të bukur dhe një zbatim të zbatueshëm. Në ManyChat, ne përdorim Snowflake për të analizuar të gjitha të dhënat që kemi. Nuk kemi tre grupime, si në shembull, por nga 5 në 9, me madhësi të ndryshme. Kemi 16 makina konvencionale, 2 makineri dhe gjithashtu super të vogla me 1 makineri për disa detyra. Ata shpërndajnë me sukses ngarkesën dhe na lejojnë të kursejmë shumë.
Baza e të dhënave shkallëzon me sukses ngarkesën e leximit dhe shkrimit. Ky është një ndryshim i madh dhe një përparim i madh në krahasim me të njëjtën "Aurora", e cila mbante vetëm ngarkesën e leximit. Snowflake ju lejon të shkallëzoni ngarkesën tuaj të punës me shkrim me këto grupime kompjuterike. Kjo do të thotë, siç e përmenda, ne përdorim disa grupime në ManyChat, grupet e vogla dhe super të vogla përdoren kryesisht për ETL, për ngarkimin e të dhënave. Dhe analistët tashmë jetojnë në grupime të mesme, të cilat absolutisht nuk ndikohen nga ngarkesa ETL, kështu që ata punojnë shumë shpejt.
Prandaj, baza e të dhënave është e përshtatshme për detyrat OLAP. Megjithatë, për fat të keq, nuk është ende i zbatueshëm për ngarkesat e punës OLTP. Së pari, kjo bazë të dhënash është kolone, me të gjitha pasojat që pasojnë. Së dyti, vetë qasja, kur për secilën kërkesë, nëse është e nevojshme, ngrini një grup kompjuterik dhe e mbushni me të dhëna, për fat të keq, nuk është ende mjaft e shpejtë për ngarkesat OLTP. Pritja e sekondave për detyrat OLAP është normale, por për detyrat OLTP është e papranueshme; 100 ms do të ishte më mirë, ose 10 ms do të ishte edhe më mirë.
Total
Një bazë të dhënash pa server është e mundur duke e ndarë bazën e të dhënave në pjesë pa shtetësi dhe shtete. Ju mund të keni vënë re se në të gjithë shembujt e mësipërm, pjesa Stateful ruan mikro-particionet në S3 dhe pa shtetësi është optimizuesi, duke punuar me metadata, duke trajtuar çështje sigurie që mund të ngrihen si shërbime të pavarura të lehta pa shtetësi.
Ekzekutimi i pyetjeve SQL mund të perceptohet gjithashtu si shërbime të gjendjes së lehtë që mund të shfaqen në modalitetin pa server, si grupet kompjuterike Snowflake, të shkarkojnë vetëm të dhënat e nevojshme, të ekzekutojnë pyetjen dhe të "dalin".
Bazat e të dhënave të nivelit të prodhimit pa server janë tashmë të disponueshme për përdorim, ato janë duke punuar. Këto baza të dhënash pa server janë tashmë gati për të trajtuar detyrat OLAP. Fatkeqësisht, për detyrat OLTP ato përdoren... me nuanca, pasi ka kufizime. Nga njëra anë, ky është një minus. Por, nga ana tjetër, kjo është një mundësi. Ndoshta një nga lexuesit do të gjejë një mënyrë për ta bërë një bazë të dhënash OLTP plotësisht pa server, pa kufizimet e Aurora.
Shpresoj ta keni gjetur interesante. Pa server është e ardhmja :)
Burimi: www.habr.com