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
