Sveiki visi! Mano vardas Golovas Nikolajus. Anksčiau dirbau Avito ir šešerius metus vadovavau duomenų platformai, tai yra dirbau su visomis duomenų bazėmis: analitinėmis (Vertica, ClickHouse), srautinėmis ir OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Per tą laiką susidūriau su daugybe duomenų bazių – labai skirtingų ir neįprastų bei su nestandartiniais jų naudojimo atvejais.
Šiuo metu dirbu ManyChat. Iš esmės tai yra startuolis – naujas, ambicingas ir sparčiai augantis. Kai pirmą kartą prisijungiau prie įmonės, iškilo klasikinis klausimas: „Ko jaunas startuolis dabar turėtų pasiimti iš DBVS ir duomenų bazių rinkos?
Šiame straipsnyje, remiantis mano ataskaita adresu , atsakysiu į šį klausimą. Ataskaitos vaizdo įrašą galite rasti adresu .
Plačiai žinomos duomenų bazės 2020 m
Dabar 2020 m., aš apsidairiau ir pamačiau trijų tipų duomenų bazes.
Pirmasis tipas - klasikinės OLTP duomenų bazės: PostgreSQL, SQL serveris, Oracle, MySQL. Jie buvo parašyti seniai, bet vis dar aktualūs, nes taip gerai žinomi kūrėjų bendruomenei.
Antrasis tipas - bazės nuo "nulio". Jie bandė atsiriboti nuo klasikinių modelių, atsisakydami SQL, tradicinių struktūrų ir ACID, pridėdami įmontuotą skaidymą ir kitas patrauklias funkcijas. Pavyzdžiui, tai yra Cassandra, MongoDB, Redis arba Tarantool. Visi šie sprendimai norėjo pasiūlyti rinkai kažką iš esmės naujo ir užėmė savo nišą, nes pasirodė itin patogūs atlikti tam tikras užduotis. Šias duomenų bazes pažymėsiu skėčiu NOSQL.
„Nulis“ baigėsi, mes pripratome prie NOSQL duomenų bazių ir pasaulis, mano požiūriu, žengė kitą žingsnį - valdomos duomenų bazės. Šios duomenų bazės turi tą patį branduolį kaip ir klasikinės OLTP duomenų bazės arba naujos NoSQL. Tačiau jiems nereikia DBA ir DevOps ir jie veikia su valdoma aparatūra debesyse. Kūrėjui tai „tik bazė“, kuri kažkur veikia, bet niekam neįdomu, kaip ji įdiegta serveryje, kas sukonfigūravo serverį ir kas jį atnaujina.
Tokių duomenų bazių pavyzdžiai:
- AWS RDS yra valdomas PostgreSQL / MySQL paketas.
- DynamoDB yra dokumentais pagrįstos duomenų bazės AWS analogas, panašus į Redis ir MongoDB.
- „Amazon Redshift“ yra valdoma analitinė duomenų bazė.
Iš esmės tai yra senos duomenų bazės, tačiau sukurtos valdomoje aplinkoje, nereikia dirbti su technine įranga.
Pastaba. Pavyzdžiai paimti AWS aplinkai, tačiau jų analogų yra ir Microsoft Azure, Google Cloud arba Yandex.Cloud.
Kas čia naujo? 2020 m. nieko iš to.
Koncepcija be serverio
2020 m. rinkoje tikrai naujiena yra sprendimai be serverių arba be serverių.
Pabandysiu paaiškinti, ką tai reiškia, naudodamas įprastos paslaugos arba užpakalinės programos pavyzdį.
Norėdami įdiegti įprastą užpakalinę programą, perkame arba nuomojame serverį, nukopijuojame kodą į jį, paskelbiame galutinį tašką išorėje ir reguliariai mokame už nuomą, elektrą ir duomenų centro paslaugas. Tai yra standartinė schema.
Ar yra koks nors kitas būdas? Naudodami paslaugas be serverio galite.
Kas yra šio požiūrio akcentas: nėra serverio, net nėra nuomojamas virtualus egzempliorius debesyje. Norėdami įdiegti paslaugą, nukopijuokite kodą (funkcijas) į saugyklą ir paskelbkite jį galutiniame taške. Tada mes tiesiog mokame už kiekvieną šios funkcijos iškvietimą, visiškai nekreipdami dėmesio į aparatinę įrangą, kurioje ji vykdoma.
Šį požiūrį pabandysiu iliustruoti nuotraukomis.
Klasikinis diegimas. Turime paslaugą su tam tikra apkrova. Mes iškeliame du atvejus: fizinius serverius arba egzempliorius AWS. Išorinės užklausos siunčiamos į šias instancijas ir ten apdorojamos.
Kaip matote paveikslėlyje, serveriai nėra vienodai šalinami. Vienas yra 100% panaudotas, yra dvi užklausos, o viena yra tik 50% - iš dalies neaktyvi. Jei gausite ne tris užklausas, o 30, visa sistema negalės susidoroti su apkrova ir pradės lėtėti.
Diegimas be serverio. Aplinkoje be serverio tokia paslauga neturi egzempliorių ar serverių. Yra tam tikras šildomų resursų telkinys – nedideli paruošti Docker konteineriai su dislokuotu funkcijos kodu. Sistema gauna išorines užklausas ir kiekvienai iš jų be serverio sistema iškelia mažą konteinerį su kodu: apdoroja šią konkrečią užklausą ir užmuša konteinerį.
Vienas prašymas – vienas konteineris pakeltas, 1000 prašymų – 1000 konteinerių. O diegimas aparatinės įrangos serveriuose jau yra debesų paslaugų teikėjo darbas. Tai visiškai paslėpta be serverio sistemos. Pagal šią koncepciją mokame už kiekvieną skambutį. Pavyzdžiui, per dieną ateidavo vienas skambutis – mokėdavome už vieną skambutį, milijonas ateidavo per minutę – mokėdavome už milijoną. Arba per sekundę tai taip pat atsitinka.
Be serverio funkcijos paskelbimo koncepcija tinka paslaugai be būsenos. O jei jums reikia (valstybės) būsenos pilnos paslaugos, tada prie paslaugos pridedame duomenų bazę. Šiuo atveju, kai reikia dirbti su būsena, kiekviena būsenos funkcija tiesiog rašo ir nuskaito iš duomenų bazės. Be to, iš bet kurios iš trijų straipsnio pradžioje aprašytų tipų duomenų bazės.
Koks yra bendras visų šių duomenų bazių apribojimas? Tai nuolat naudojamo debesies ar techninės įrangos serverio (arba kelių serverių) išlaidos. Nesvarbu, ar naudojame klasikinę, ar valdomą duomenų bazę, ar turime Devops ir administratorių, ar ne, vis tiek mokame už techninę įrangą, elektrą ir duomenų centro nuomą 24 valandas per parą, 7 dienas per savaitę. Jei turime klasikinę bazę, mokame už šeimininką ir vergą. Jei tai labai apkrauta susmulkinta duomenų bazė, mokame už 10, 20 ar 30 serverių ir mokame nuolat.
Nuolat rezervuotų serverių buvimas sąnaudų struktūroje anksčiau buvo suvokiamas kaip būtinas blogis. Įprastos duomenų bazės turi ir kitų sunkumų, tokių kaip jungčių skaičiaus apribojimai, mastelio apribojimai, geografiškai paskirstytas konsensusas – juos galima kažkaip išspręsti tam tikrose duomenų bazėse, bet ne visas iš karto ir ne idealiai.
Duomenų bazė be serverio – teorija
2020 m. klausimas: ar įmanoma padaryti duomenų bazę be serverio? Visi girdėjo apie backend be serverio... pabandykime padaryti duomenų bazę be serverio?
Tai skamba keistai, nes duomenų bazė yra būsenos pilna paslauga, nelabai tinkama infrastruktūrai be serverio. Tuo pačiu metu duomenų bazės būsena yra labai didelė: gigabaitai, terabaitai, o analitinėse duomenų bazėse net petabaitai. Ne taip paprasta jį kelti lengvuose Docker konteineriuose.
Kita vertus, beveik visose šiuolaikinėse duomenų bazėse yra daug logikos ir komponentų: operacijos, vientisumo koordinavimas, procedūros, reliacinės priklausomybės ir daug logikos. Gana daug duomenų bazės logikos pakanka mažos būsenos. Gigabaitus ir terabaitus tiesiogiai naudoja tik nedidelė duomenų bazės logikos dalis, tiesiogiai vykdanti užklausas.
Atitinkamai, idėja yra tokia: jei dalis logikos leidžia vykdyti be pilietybės, kodėl gi nepadalijus bazės į valstybinę ir be pilietybės dalis.
Be serverio OLAP sprendimams
Pažiūrėkime, kaip gali atrodyti duomenų bazės supjaustymas į būseną ir be būsenos dalis, naudodamiesi praktiniais pavyzdžiais.
Pavyzdžiui, turime analitinę duomenų bazę: išoriniai duomenys (raudonas cilindras kairėje), ETL procesas, kuris įkelia duomenis į duomenų bazę, ir analitikas, siunčiantis į duomenų bazę SQL užklausas. Tai klasikinė duomenų saugyklos veikimo schema.
Šioje schemoje ETL sąlygiškai atliekamas vieną kartą. Tada reikia nuolat mokėti už serverius, kuriuose veikia duomenų bazė su ETL užpildytais duomenimis, kad būtų į ką siųsti užklausas.
Pažvelkime į alternatyvų metodą, įgyvendintą AWS Athena Serverless. Nėra nuolatinės specialios aparatinės įrangos, kurioje būtų saugomi atsisiųsti duomenys. Vietoj to:
- Vartotojas pateikia SQL užklausą Athena. Athena optimizavimo priemonė analizuoja SQL užklausą ir metaduomenų saugykloje (Metaduomenys) ieško konkrečių duomenų, reikalingų užklausai vykdyti.
- Optimizatorius, remdamasis surinktais duomenimis, parsiunčia reikiamus duomenis iš išorinių šaltinių į laikinąją saugyklą (laikinąją duomenų bazę).
- Vartotojo SQL užklausa vykdoma laikinojoje saugykloje, o rezultatas grąžinamas vartotojui.
- Laikina saugykla išvaloma ir ištekliai atleidžiami.
Šioje architektūroje mokame tik už užklausos vykdymo procesą. Jokių prašymų – jokių išlaidų.
Tai yra darbinis metodas ir įgyvendinamas ne tik „Athena Serverless“, bet ir „Redshift Spectrum“ (AWS).
Athena pavyzdys rodo, kad duomenų bazė be serverio veikia realiomis užklausomis su dešimtimis ir šimtais terabaitų duomenų. Šimtams terabaitų prireiks šimtų serverių, tačiau už juos mokėti nereikia – mokame už užklausas. Kiekvienos užklausos greitis yra (labai) mažas, palyginti su specializuotomis analitinėmis duomenų bazėmis, tokiomis kaip Vertica, tačiau mes nemokame už prastovos laikotarpius.
Tokia duomenų bazė tinka retoms analitinėms ad-hoc užklausoms. Pavyzdžiui, kai spontaniškai nusprendžiame patikrinti hipotezę dėl milžiniško duomenų kiekio. Atėnė puikiai tinka šiems atvejams. Įprastoms užklausoms tokia sistema yra brangi. Tokiu atveju saugokite duomenis tam tikru specializuotu sprendimu.
Be serverio OLTP sprendimams
Ankstesniame pavyzdyje buvo nagrinėjamos OLAP (analitinės) užduotys. Dabar pažvelkime į OLTP užduotis.
Įsivaizduokime keičiamo dydžio PostgreSQL arba MySQL. Pakelkime įprastą valdomą PostgreSQL arba MySQL egzempliorių su minimaliais ištekliais. Kai egzempliorius gaus daugiau apkrovos, prijungsime papildomas kopijas, kurioms paskirstysime dalį skaitymo krūvio. Jei nėra užklausų ar įkėlimo, kopijas išjungiame. Pirmasis pavyzdys yra pagrindinis, o kiti yra kopijos.
Ši idėja įgyvendinta duomenų bazėje, pavadintoje „Aurora Serverless AWS“. Principas paprastas: užklausas iš išorinių programų priima įgaliotasis parkas. Matydamas didėjančią apkrovą, jis paskirsto skaičiavimo išteklius iš iš anksto pašildytų minimalių egzempliorių – ryšys užmezgamas kuo greičiau. Išjungimo atvejai vyksta taip pat.
„Aurora“ yra „Aurora Capacity Unit“, ACU, koncepcija. Tai (sąlygiškai) egzempliorius (serveris). Kiekvienas konkretus ACU gali būti pagrindinis arba vergas. Kiekvienas talpos blokas turi savo RAM, procesorių ir minimalų diską. Atitinkamai, vienas yra meistras, o kiti yra tik skaitomos kopijos.
Šių veikiančių Aurora talpos vienetų skaičius yra konfigūruojamas parametras. Minimalus kiekis gali būti vienas arba nulis (šiuo atveju duomenų bazė neveikia, jei nėra užklausų).
Kai bazė gauna užklausas, tarpinio serverio parkas padidina Aurora CapacityUnits, padidindamas sistemos našumo išteklius. Galimybė didinti ir mažinti išteklius leidžia sistemai „žongliruoti“ ištekliais: automatiškai rodyti atskirus ACU (pakeičiant juos naujais) ir įdiegti visus dabartinius pašalintų išteklių atnaujinimus.
„Aurora Serverless“ bazė gali padidinti skaitymo apkrovą. Tačiau dokumentuose tai tiesiogiai nepasakoma. Gali atrodyti, kad jie gali pakelti daugiapakopį. Jokios magijos nėra.
Ši duomenų bazė puikiai tinka norint neišleisti didelių pinigų sumų sistemoms su nenuspėjama prieiga. Pavyzdžiui, kurdami MVP ar rinkodaros vizitinių kortelių svetaines, dažniausiai nesitikime stabilios apkrovos. Atitinkamai, jei nėra prieigos, mes nemokame už atvejus. Atsiradus netikėtai apkrovai, pavyzdžiui, po konferencijos ar reklaminės kampanijos, svetainėje apsilanko minios žmonių ir apkrova smarkiai išauga, Aurora Serverless automatiškai paima šią apkrovą ir greitai sujungia trūkstamus resursus (ACU). Tada konferencija praeina, visi pamiršta apie prototipą, serveriai (ACU) užtemsta, o išlaidos nukrenta iki nulio – patogu.
Šis sprendimas netinka stabiliai didelei apkrovai, nes nekeičia rašymo apkrovos. Visi šie išteklių prijungimai ir atjungimai įvyksta vadinamajame „mastelio taške“ – momente, kai duomenų bazės nepalaiko operacija ar laikinos lentelės. Pavyzdžiui, per savaitę mastelio taškas gali neįvykti, o bazė dirba su tais pačiais ištekliais ir tiesiog negali plėstis ar susitraukti.
Nėra jokios magijos – tai įprasta PostgreSQL. Tačiau mašinų pridėjimo ir atjungimo procesas yra iš dalies automatizuotas.
Pagal dizainą be serverio
„Aurora Serverless“ yra sena duomenų bazė, perrašyta debesiui, kad būtų galima pasinaudoti kai kuriais „Serverless“ pranašumais. O dabar papasakosiu apie bazę, kuri iš pradžių buvo skirta debesiui, be serverio metodui – be serverio pagal dizainą. Jis buvo iš karto sukurtas be prielaidos, kad jis veiks fiziniuose serveriuose.
Ši bazė vadinama Snowflake. Jame yra trys raktų blokai.
Pirmasis yra metaduomenų blokas. Tai sparti atmintyje esanti paslauga, sprendžianti saugumo, metaduomenų, operacijų ir užklausų optimizavimo problemas (parodyta iliustracijoje kairėje).
Antrasis blokas yra virtualių skaičiavimo grupių rinkinys skaičiavimams (iliustracijoje yra mėlynų apskritimų rinkinys).
Trečiasis blokas yra duomenų saugojimo sistema, pagrįsta S3. S3 yra bematė objektų saugykla AWS, panaši į bematį „Dropbox“ verslui.
Pažiūrėkime, kaip veikia „Snaigė“, darant prielaidą, kad startas šaltas. Tai yra, yra duomenų bazė, į ją įkeliami duomenys, nėra vykdomų užklausų. Atitinkamai, jei duomenų bazėje nėra užklausų, mes iškėlėme greitą atmintyje esančią metaduomenų paslaugą (pirmasis blokas). Ir mes turime S3 saugyklą, kurioje saugomi lentelės duomenys, suskirstyti į vadinamuosius mikroskyrius. Paprastumo dėlei: jei lentelėje yra operacijos, tada mikroskirstymai yra operacijų dienos. Kiekviena diena yra atskiras mikroskirstymas, atskiras failas. O kai duomenų bazė veikia šiuo režimu, mokate tik už duomenų užimamą vietą. Be to, kaina vienai sėdynei yra labai maža (ypač atsižvelgiant į didelį suspaudimą). Metaduomenų paslauga taip pat veikia nuolat, tačiau jums nereikia daug išteklių optimizuoti užklausas, o paslauga gali būti laikoma bendro naudojimo programine įranga.
Dabar įsivaizduokime, kad vartotojas atėjo į mūsų duomenų bazę ir išsiuntė SQL užklausą. SQL užklausa nedelsiant siunčiama apdoroti metaduomenų tarnybai. Atitinkamai, ši paslauga, gavusi užklausą, išanalizuoja užklausą, turimus duomenis, vartotojo teises ir, jei viskas gerai, parengia užklausos apdorojimo planą.
Tada paslauga inicijuoja skaičiavimo klasterio paleidimą. Skaičiavimo klasteris yra serverių, kurie atlieka skaičiavimus, grupė. Tai yra, tai yra klasteris, kuriame gali būti 1 serveris, 2 serveriai, 4, 8, 16, 32 - tiek, kiek norite. Pateikiate užklausą ir iš karto prasideda šio klasterio paleidimas. Tai tikrai trunka kelias sekundes.
Tada, pradėjus veikti klasteriui, mikroskirstymai, reikalingi jūsų užklausai apdoroti, pradedami kopijuoti į klasterį iš S3. Tai yra, įsivaizduokime, kad norint vykdyti SQL užklausą, reikia dviejų skaidinių iš vienos lentelės ir vieno iš antrosios. Tokiu atveju į klasterį bus nukopijuoti tik trys būtini skaidiniai, o ne visos lentelės. Štai kodėl ir būtent todėl, kad viskas yra viename duomenų centre ir sujungta labai greitais kanalais, visas perdavimo procesas vyksta labai greitai: per kelias sekundes, labai retai per minutes, nebent kalbame apie kažkokius siaubingus prašymus. Atitinkamai, mikroskirstymai nukopijuojami į skaičiavimo klasterį, o užbaigus SQL užklausa vykdoma šiame skaičiavimo klasteryje. Šios užklausos rezultatas gali būti viena eilutė, kelios eilutės arba lentelė – jos išoriškai siunčiamos vartotojui, kad jis galėtų ją atsisiųsti, parodyti savo BI įrankyje ar kaip nors kitaip panaudoti.
Kiekviena SQL užklausa gali ne tik nuskaityti agregatus iš anksčiau įkeltų duomenų, bet ir įkelti/generuoti naujus duomenis duomenų bazėje. Tai yra, tai gali būti užklausa, kuri, pavyzdžiui, įterpia naujus įrašus į kitą lentelę, o tai lemia naujo skaidinio atsiradimą skaičiavimo klasteryje, kuris, savo ruožtu, automatiškai išsaugomas vienoje S3 saugykloje.
Aukščiau aprašytas scenarijus, nuo vartotojo atėjimo iki klasterio pakėlimo, duomenų įkėlimo, užklausų vykdymo, rezultatų gavimo, apmokamas pagal tarifą už naudojimosi iškeltu virtualiu skaičiavimo klasteriu, virtualiu sandėliu minutes. Kaina skiriasi priklausomai nuo AWS zonos ir klasterio dydžio, tačiau vidutiniškai tai yra keli doleriai per valandą. Keturių mašinų grupė yra dvigubai brangesnė nei dviejų mašinų grupė, o aštuonių mašinų grupė vis dar yra dvigubai brangesnė. Galimi 16, 32 aparatų variantai, atsižvelgiant į užklausų sudėtingumą. Bet mokate tik už tas minutes, kai iš tikrųjų veikia klasteris, nes kai nėra užklausų, tarsi nuimate rankas ir po 5-10 minučių laukimo (konfigūruojamas parametras) jis išsijungs savaime, atlaisvinkite išteklius ir tapkite laisvi.
Visiškai realus scenarijus yra toks: kai siunčiate užklausą, klasteris pasirodo, santykinai tariant, per minutę, skaičiuojama dar viena minutė, tada penkios minutės išsijungia, ir jūs mokate už septynias šio klasterio veikimo minutes ir ne mėnesius ir metus.
Pirmasis scenarijus, aprašytas naudojant „Snowflake“ vienam vartotojui. Dabar įsivaizduokime, kad yra daug vartotojų, o tai yra arčiau tikrojo scenarijaus.
Tarkime, kad turime daug analitikų ir „Tableau“ ataskaitų, kurios nuolat bombarduoja mūsų duomenų bazę daugybe paprastų analitinių SQL užklausų.
Be to, tarkime, kad turime išradingų duomenų mokslininkų, kurie su duomenimis bando daryti siaubingus dalykus, operuoja su dešimtimis terabaitų, analizuoja milijardus ir trilijonus duomenų eilučių.
Dviejų tipų darbo krūviams, aprašytiems aukščiau, „Snowflake“ leidžia sukurti keletą nepriklausomų skirtingos talpos skaičiavimo grupių. Be to, šie skaičiavimo klasteriai veikia nepriklausomai, bet su bendrais nuosekliais duomenimis.
Jei norite pateikti daug lengvų užklausų, galite sukurti 2–3 mažas grupes, kurių kiekvienoje yra maždaug po 2 įrenginius. Šis elgesys gali būti įgyvendintas, be kita ko, naudojant automatinius nustatymus. Taigi jūs sakote: „Snaigė, kelk mažą spiečius. Jei jo apkrova padidėja virš tam tikro parametro, pakelkite panašų antrą, trečią. Kai apkrova pradeda mažėti, užgesinkite perteklių. Kad ir kiek analitikų ateitų ir pradėtų žiūrėti ataskaitas, visi turi pakankamai resursų.
Tuo pačiu metu, jei analitikai miega ir niekas nežiūri į ataskaitas, klasteriai gali visiškai užtemti ir jūs nustosite už juos mokėti.
Tuo pačiu metu, jei norite pateikti daug užklausų (iš „Data Scientists“), galite sukurti vieną labai didelę grupę 32 įrenginiams. Šis klasteris taip pat bus mokamas tik už tas minutes ir valandas, kai ten vykdoma didžiulė jūsų užklausa.
Aukščiau aprašyta galimybė leidžia suskirstyti ne tik 2, bet ir daugiau tipų darbo krūvius į grupes (ETL, monitoringas, ataskaitų materializavimas,...).
Apibendrinkime Snaigę. Bazė sujungia gražią idėją ir veiksmingą įgyvendinimą. „ManyChat“ mes naudojame „Snowflake“ visiems turimiems duomenims analizuoti. Turime ne tris klasterius, kaip pavyzdyje, o nuo 5 iki 9 skirtingų dydžių. Kai kurioms užduotims atlikti turime įprastų 16 mašinų, 2 mašinų ir ypač mažų 1 mašinų. Jie sėkmingai paskirsto krūvį ir leidžia daug sutaupyti.
Duomenų bazė sėkmingai padidina skaitymo ir rašymo apkrovą. Tai didžiulis skirtumas ir didžiulis proveržis, lyginant su ta pačia „Aurora“, kuri nešė tik skaitymo krūvį. „Snowflake“ leidžia padidinti rašymo darbo krūvį naudojant šias skaičiavimo grupes. Tai yra, kaip minėjau, „ManyChat“ naudojame keletą klasterių, maži ir ypač maži klasteriai daugiausia naudojami ETL, duomenims įkelti. O analitikai jau gyvena ant vidutinių klasterių, kurių ETL apkrova visiškai neveikia, todėl dirba labai greitai.
Atitinkamai, duomenų bazė puikiai tinka OLAP užduotims atlikti. Tačiau, deja, jis dar netaikomas OLTP darbo krūviams. Pirma, ši duomenų bazė yra stulpelinė su visomis iš to išplaukiančiomis pasekmėmis. Antra, pats požiūris, kai kiekvienai užklausai, jei reikia, iškeliate skaičiavimo klasterį ir užliejate jį duomenimis, deja, dar nėra pakankamai greitas OLTP įkėlimams. Laukti sekundžių OLAP užduočių yra normalu, tačiau OLTP užduočių atveju tai nepriimtina; 100 ms būtų geriau arba 10 ms būtų dar geriau.
Visas
Duomenų bazė be serverio galima padalijus duomenų bazę į bevalstybės ir būsenos dalis. Galbūt pastebėjote, kad visuose aukščiau pateiktuose pavyzdžiuose „Stateful“ dalis yra santykinai kalbant apie mikro skaidinių saugojimą S3, o „Stateless“ yra optimizavimo priemonė, dirbanti su metaduomenimis, sprendžianti saugos problemas, kurios gali būti iškeltos kaip nepriklausomos lengvas be statuso paslaugos.
SQL užklausų vykdymas taip pat gali būti suvokiamas kaip lengvosios būsenos paslaugos, kurios gali pasirodyti be serverio režimu, pvz., „Snowflake“ skaičiavimo klasteriai, atsisiųsti tik reikiamus duomenis, vykdyti užklausą ir „išeiti“.
Be serverio gamybos lygio duomenų bazės jau yra prieinamos naudojimui, jos veikia. Šios duomenų bazės be serverių jau paruoštos OLAP užduotims atlikti. Deja, OLTP užduotims jie naudojami... su niuansais, nes yra apribojimų. Viena vertus, tai yra minusas. Tačiau, kita vertus, tai yra galimybė. Galbūt vienas iš skaitytojų ras būdą, kaip OLTP duomenų bazę padaryti visiškai be serverio, be Aurora apribojimų.
Tikiuosi, kad jums tai buvo įdomu. Be serverio yra ateitis :)
Šaltinis: www.habr.com