Hej alla! Jag heter Nikolai Golov. Tidigare arbetade jag pĂ„ Avito och ledde Data Platform i sex Ă„r, vilket innebar att jag hanterade alla databaser: analytiska (Vertica, ClickHouse), strömmande och OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Under denna tid har jag kommit i kontakt med en stor mĂ€ngd databaser â av olika och ovanliga slag, och med icke-standardiserade anvĂ€ndningsfall.
Just nu arbetar jag pĂ„ ManyChat. Det Ă€r i grunden en startup â ny, ambitiös och snabbt vĂ€xande. Och nĂ€r jag precis började pĂ„ företaget, uppstod den klassiska frĂ„gan: "Vad bör en ung startup vĂ€lja frĂ„n marknaden för DBMS och databaser just nu?".
I den hÀr artikeln, baserad pÄ mitt föredrag pÄ , svarar jag pÄ den frÄgan. Videoversionen av föredraget finns tillgÀnglig pÄ .
VÀlkÀnda databaser 2020
Det Àr Är 2020, jag sÄg mig omkring och sÄg tre typer av databaser.
Den första typen â klassiska OLTP-databaser: PostgreSQL, SQL Server, Oracle, MySQL. De skapades för lĂ€nge sedan, men Ă€r fortfarande aktuella eftersom de Ă€r vĂ€lkĂ€nda för utvecklarsamhĂ€llet.
Den andra typen â databaser frĂ„n "nollorna".De försökte avvika frĂ„n klassiska mönster genom att avstĂ„ frĂ„n SQL, traditionella strukturer och ACID, genom att lĂ€gga till inbyggd sharding och andra attraktiva funktioner. Exempel pĂ„ detta Ă€r Cassandra, MongoDB, Redis eller Tarantool. Alla dessa lösningar ville erbjuda marknaden nĂ„got helt nytt och fann sin nisch, eftersom de visade sig vara extremt bekvĂ€ma för vissa uppgifter. Jag kommer att beteckna dessa databaser med den övergripande termen NOSQL.
"Nollorna" Ă€r över, mĂ€nniskor har vant sig vid NOSQL-databaser, och vĂ€rlden, enligt min uppfattning, har gjort ett nĂ€sta steg â mot managed databaser.Dessa databaser har samma kĂ€rna som klassiska OLTP-databaser eller nya NoSQL. Men de har inget behov av DBA och DevOps och de körs pĂ„ hanterad hĂ„rdvara i molnet. För utvecklaren Ă€r det "bara en databas" som fungerar nĂ„gonstans, och hur den Ă€r installerad pĂ„ servern, vem som har konfigurerat servern och vem som uppdaterar den, berör ingen.
Exempel pÄ sÄdana databaser:
- AWS RDS â en hanterad wrapper över PostgreSQL/MySQL.
- DynamoDB â AWS:s dokumentbaserade databas, liknande Redis och MongoDB.
- Amazon Redshift â en hanterad analytisk databas.
I grunden handlar det om gamla databaser, men i en hanterad miljö, utan behov av att arbeta med hÄrdvara.
Obs. Exemplen Àr tagna för AWS-miljön, men deras motsvarigheter finns ocksÄ i Microsoft Azure, Google Cloud, eller Yandex.Cloud.
Vad Ă€r nytt med detta? Ă
r 2020 Àr inget av detta nytt.
Serverless-konceptet
NÄgot helt nytt pÄ marknaden 2020 var serverless eller serverfria lösningar.
LÄt mig förklara vad det innebÀr med ett exempel pÄ en vanlig tjÀnst eller backend-applikation.
För att lansera en vanlig backend-applikation köper eller hyr vi en server, kopierar koden dit, publicerar en extern endpoint och betalar regelbundet för hyra, elektricitet och datacenter-tjÀnster. Det hÀr Àr standardproceduren.
Finns det nÄgot annat sÀtt? Med serverfria tjÀnster finns det.
Vad Àr knÀckfrÄgan med detta tillvÀgagÄngssÀtt: det finns ingen server, inte ens en hyra av en virtuell instans i molnet. För att lansera tjÀnsten kopierar vi koden (funktionerna) till ett repository och publicerar en extern endpoint. Sedan betalar vi bara för varje anrop av denna funktion, helt ovetande om den hÄrdvara dÀr den körs.
Jag ska försöka illustrera detta tillvÀgagÄngssÀtt med bilder.
Klassisk deploy. Vi har en tjÀnst med viss belastning. Vi startar tvÄ instanser: fysiska servrar eller instanser i AWS. Externa förfrÄgningar riktas till dessa instanser, som hanterar dem.
Som man kan se pĂ„ bilden Ă€r servrarna utnyttjade pĂ„ olika sĂ€tt. En Ă€r utnyttjad till 100%, dĂ€r finns tvĂ„ förfrĂ„gningar, medan en annan bara Ă€r utnyttjad till 50% â den stĂ„r delvis stilla. Om tre förfrĂ„gningar kommer in istĂ€llet för trettio, sĂ„ klarar inte systemet av belastningen och börjar sega.
Serverlös deploy. I en serverlös miljö finns det inga instanser och servrar för en sĂ„dan tjĂ€nst. Det finns en viss pool av uppvĂ€rmda resurser â smĂ„ förberedda Docker-containrar med den distribuerade funktionskoden. Systemet tar emot externa förfrĂ„gningar och för varje av dem startar det serverlösa ramverket en liten container med koden: hanterar just den förfrĂ„gan och dödar containern.
En förfrĂ„gan â en startad container, 1000 förfrĂ„gningar â 1000 containrar. Och utplaceringen av hĂ„rdvaruservrar Ă€r redan cloud-providerns jobb. Det döljs helt av det serverlösa ramverket. I detta koncept betalar vi för varje anrop. Till exempel, om en förfrĂ„gan kommer in per dag â vi betalar för ett anrop, kommer en miljon per minut â vi betalar för en miljon. Eller per sekund, det hĂ€nder ocksĂ„.
Konceptet av publicering av serverlös funktion passar för en stateless tjÀnst. Men om du behöver en stateful tjÀnst, lÀgger vi till en databas till tjÀnsten. I detta fall, nÀr det kommer till att arbeta med state, skriver och lÀser varje stateful funktion bara frÄn databasen. Dessutom frÄn en databas av vilket som helst av de tre typerna som beskrivits i början av artikeln.
Vad Ă€r den gemensamma begrĂ€nsningen för alla dessa databaser? Det handlar om kostnader för den stĂ€ndigt anvĂ€nda moln- eller hĂ„rdvaruservern (eller flera servrar). Oavsett om vi anvĂ€nder en klassisk databas eller en managed, med DevOps och admin eller inte, betalar vi fortfarande 24/7 för hĂ„rdvara, el och datacenterhyra. Om vi har en klassisk databas, betalar vi för master och slave. Om det Ă€r en högbelastad, sharded databas â betalar vi för 10, 20 eller 30 servrar, och vi betalar stĂ€ndigt.
NĂ€rvaron av stĂ€ndigt reserverade servrar i kostnadsstrukturen ansĂ„gs tidigare som en oundviklig ondska. Vanliga databaser har ocksĂ„ andra svĂ„righeter, sĂ„som begrĂ€nsningar pĂ„ antal anslutningar, skalningsbegrĂ€nsningar och geografisk konsensus â dessa kan lösas i vissa databaser, men inte alla pĂ„ en gĂ„ng och inte perfekt.
Serverless databas â teori
FrÄgan för 2020: kan en databas ocksÄ göras serverless? Alla har hört talas om serverless backend... men lÄt oss försöka göra databasen serverless ocksÄ!
Det lÄter konstigt, eftersom en databas Àr en stateful tjÀnst, vilket inte riktigt passar in i en serverless infrastruktur. Samtidigt har databasen en mycket stor state: gigabyte, terabyte och i analytiska databaser till och med petabyte. Det Àr inte sÄ lÀtt att hantera i lÀtta Docker-containrar.
à andra sidan handlar praktiskt taget alla moderna databaser om en stor mÀngd logik och komponenter: transaktioner, integritetsöverensstÀmmelse, procedurer, relationella beroenden och mycket logik. En ganska stor del av databasens logik krÀver en relativt liten state. Gigabyte och terabyte anvÀnds endast av en liten del av databasens logik som Àr kopplad till den direkta utföringen av förfrÄgningar.
DÀrför Àr idén: om en del av logiken tillÄter stateless exekvering, varför inte dela upp databasen i stateful och stateless delar?
Serverless för OLAP-lösningar
LĂ„t oss se hur uppdelningen av databasen i stateful och stateless delar kan se ut i praktiska exempel.
Till exempel har vi en analytisk databas: externa data (röd cylinder till vÀnster), ETL-processen som laddar data till databasen, och en analytiker som skickar SQL-frÄgor till databasen. Detta Àr ett klassiskt mönster för hur ett datalager fungerar.
I detta mönster utförs ETL-funktionen en gÄng. DÀrefter mÄste vi betala för servrarna dÀr databasen med de inlÀsta data körs, sÄ att vi har nÄgot att skicka frÄgor till.
LÄt oss titta pÄ ett alternativt angreppssÀtt som implementeras i AWS Athena Serverless. HÀr finns ingen konstant hÄrdvara som lagrar de inlÀsta data. IstÀllet:
- AnvÀndaren skickar en SQL-frÄga till Athena. Athena-optimeraren analyserar SQL-frÄgan och söker i metadata-lagret specifika data som behövs för att utföra frÄgan.
- Optimeraren, baserat pÄ insamlade data, hÀmtar nödvÀndiga data frÄn externa kÀllor till ett temporÀrt lagringsutrymme (tillfÀllig databas).
- I det temporÀra lagringsutrymmet körs SQL-frÄgan frÄn anvÀndaren, resultaten returneras till anvÀndaren.
- Det temporÀra lagret rensas, resurser frigörs.
I denna arkitektur betalar vi endast för processen att utföra frÄgan. Inga frÄgor - inga kostnader.
Detta Àr en fungerande metod och den implementeras inte bara i Athena Serverless, utan ocksÄ i Redshift Spectrum (i AWS).
Exemplet med Athena visar att Serverless-databaser fungerar med verkliga frÄgor med tiotals och hundratals terabyte data. För hundratals terabyte behövs hundratals servrar, men vi behöver inte betala för dem - vi betalar för frÄgorna. Hastigheten för varje frÄga Àr (mycket) lÄg jÀmfört med specialiserade analytiska databaser som Vertica, men vi betalar inte för stillastÄende tid.
En sÄdan databas Àr tillÀmpbar för sÀllsynta analytiska ad-hoc frÄgor. Till exempel, nÀr vi spontant beslutar att testa en hypotes pÄ ett enormt datamÀngd. För dessa fall Àr Athena perfekt. För regelbundna frÄgor blir ett sÄdant system dyrt. I detta fall, cache data i en specialiserad lösning.
Serverless för OLTP-lösningar
I det föregÄende exemplet diskuterades OLAP-uppgifter (analytiska). Nu ser vi pÄ OLTP-uppgifter.
LÄt oss tÀnka oss en skalbar PostgreSQL eller MySQL. Vi ska starta en vanlig managed instans av PostgreSQL eller MySQL med minimala resurser. NÀr instansen fÄr mer belastning kommer vi att ansluta ytterligare repliker, som vi fördelar en del av lÀsbelastningen pÄ. Om det inte finns nÄgra förfrÄgningar eller belastning stÀnger vi av replikerna. Den första instansen Àr master, medan de övriga Àr repliker.
Denna idĂ© realiseras i en databas som kallas Aurora Serverless AWS. Principen Ă€r enkel: förfrĂ„gningar frĂ„n externa applikationer tas emot av en proxyflotta. NĂ€r den ser en ökning av belastningen tilldelar den berĂ€kningsresurser frĂ„n förvĂ€g uppvĂ€rmda minimala instanser â anslutningen sker sĂ„ snabbt som möjligt. AvstĂ€ngning av instanser sker pĂ„ samma sĂ€tt.
Inom Aurora finns begreppet Aurora Capacity Unit, ACU. Detta Àr (villkorligt) en instans (server). Varje specifik ACU kan vara master eller slave. Varje Capacity Unit har sin egen RAM, processor och minimal disk. Följaktligen Àr en master och de övriga skrivskyddade repliker.
Antalet aktiva Aurora Capacity Units Àr en konfigurerbar parameter. Det minimiantal som kan sÀttas Àr ett eller noll (i sÄ fall fungerar inte databasen om det inte finns nÄgra förfrÄgningar).
NÀr databasen fÄr förfrÄgningar startar proxyflottan Aurora Capacity Units och ökar systemets prestandaresurser. Möjligheten att öka och minska resurser gör att systemet kan "jonglera" med resurser: automatiskt ta ut vissa ACU (ersÀtta dem med nya) och tillÀmpa alla aktuella uppdateringar pÄ de uttagna resurserna.
Aurora Serverless-databasen kan skala lÀsbelastningen. Men detta nÀmns inte uttryckligen i dokumentationen. Det kan bli en kÀnsla av att de kan skapa en multi-master. Det finns dock inget magiskt med det.
Denna databas Àr vÀl lÀmpad för att undvika att spendera stora pengar pÄ system med oförutsÀgbart tillgÄng. Till exempel, nÀr vi skapar MVP eller marknadsföringssajter, förvÀntar vi oss vanligtvis inte en stabil belastning. DÀrför, vid brist pÄ tillgÄng, betalar vi inget för instanser. NÀr belastningen plötsligt ökar, till exempel efter en konferens eller marknadsföringskampanj, kommer mÄnga mÀnniskor att besöka sajten och belastningen ökar snabbt; Aurora Serverless anpassar sig automatiskt till denna belastning och kopplar snabbt pÄ de saknade resurserna (ACU). Efter konferensen glömmer alla prototypen, servrarna (ACU) stÀngs av, och kostnaderna faller till noll - mycket praktiskt.
Denna lösning Ă€r inte lĂ€mplig för stabil hög belastning, eftersom den inte kan skala den skrivande belastningen. Alla dessa anslutningar och kopplingar av resurser sker vid den sĂ„ kallade âskala-punktenâ â tidpunkten nĂ€r databasen inte hĂ„lls av en transaktion, och inga temporĂ€ra tabeller hĂ„lls. Till exempel, under en vecka kan det hĂ€nda att ingen skala-punkt intrĂ€ffar, och databasen arbetar med samma resurser och helt enkelt inte kan varken expandera eller minska.
Det finns inget magiskt â detta Ă€r vanlig PostgreSQL. Men processen för att lĂ€gga till maskiner och stĂ€nga av dem Ă€r delvis automatiserad.
Serverless by design
Aurora Serverless Ă€r en gammal databas som skrivits om för molnet för att utnyttja de specifika fördelarna med Serverless. Nu kommer jag att prata om en databas som frĂ„n början Ă€r skriven för molnet, under serverless-ansatsen â Serverless-by-design. Den designades utan förutsĂ€ttningar om att den skulle fungera pĂ„ fysiska servrar.
Denna databas kallas Snowflake. Den har tre centrala block.
Det första Àr metadata-blocket. Detta Àr en snabb in-memory-tjÀnst som hanterar frÄgor kring sÀkerhet, metadata, transaktioner, och query-optimering (i illustrationen till vÀnster).
Det andra blocket â en mĂ€ngd virtuella berĂ€kningskluster för berĂ€kningar (i illustrationen â ett set av blĂ„ cirklar).
Det tredje blocket â datalagringssystemet baserat pĂ„ S3. S3 Ă€r en dimensionlös objektlagring i AWS, ett slags dimensionlös Dropbox för företag.
LÄt oss titta pÄ hur Snowflake fungerar under förutsÀttning av en kall start. Det vill sÀga att databasen finns, data Àr laddad, men inga aktiva förfrÄgningar görs. Om inga förfrÄgningar görs mot databasen har vi en snabb in-memory Metadata-tjÀnst uppe (den första blocket). Vi har ocksÄ en S3-lagring dÀr tabellernas data ligger uppdelad i sÄ kallade mikropartitioner. Förenklat: om tabellen innehÄller affÀrer, sÄ Àr mikropartitionerna dagar av affÀrer. Varje dag Àr en separat mikropartition, en egen fil. NÀr databasen fungerar i detta lÀge betalar du endast för det utrymme som data tar. Dessutom Àr kostnaden för utrymme mycket lÄg (sÀrskilt med tanke pÄ betydande kompression). Metadata-tjÀnsten Àr ocksÄ stÀndigt verksam, men för att optimera förfrÄgningarna krÀvs inte mycket resurser, och tjÀnsten kan anses vara i praktiken kostnadsfri.
Nu förestÀller vi oss att en anvÀndare har skickat en SQL-förfrÄgan till vÄr databas. SQL-förfrÄgan skickas omedelbart för behandling till Metadata-tjÀnsten. TjÀnsten analyserar förfrÄgan, tillgÀngliga data, anvÀndarens behörigheter, och om allt ser bra ut skapar den en plan för hur förfrÄgan ska bearbetas.
DĂ€refter initierar tjĂ€nsten starten av ett berĂ€kningskluster. BerĂ€kningsklustret Ă€r ett kluster av servrar som utför berĂ€kningar. Det vill sĂ€ga, det kan innehĂ„lla 1 server, 2 servrar, 4, 8, 16, 32 â sĂ„ mĂ„nga ni vill. Du skickar din förfrĂ„gan och klustret startas omedelbart för den. Det tar verkligen sekunder.
Sedan, efter att klustret har startat, börjar mikropartiklar kopieras frĂ„n S3 till klustret, vilket Ă€r nödvĂ€ndigt för att bearbeta just din förfrĂ„gan. Det vill sĂ€ga, lĂ„t oss förestĂ€lla oss att för att utföra en SQL-förfrĂ„gan behövs tvĂ„ partitioner frĂ„n en tabell och en frĂ„n den andra. I sĂ„ fall kommer endast de tre nödvĂ€ndiga partitionerna att kopieras till klustret, och inte hela tabeller. Just dĂ€rför och pĂ„ grund av att allt ligger inom ett datacenter och Ă€r anslutet med mycket snabba kanaler, sker hela överföringsprocessen mycket snabbt: pĂ„ sekunder, mycket sĂ€llan â pĂ„ minuter, om det rör sig om nĂ„gra enorma förfrĂ„gningar. Följaktligen kopieras mikropartiklarna till det berĂ€kningsklustret, och nĂ€r det Ă€r klart utförs SQL-förfrĂ„gan pĂ„ detta berĂ€kningskluster. Resultatet av denna förfrĂ„gan kan vara en rad, flera rader eller en tabell â de skickas ut till anvĂ€ndaren sĂ„ att denne kan hĂ€mta dem, visa dem i sitt BI-verktyg, eller anvĂ€nda dem pĂ„ nĂ„got annat sĂ€tt.
Varje SQL-förfrÄgan kan inte bara rÀkna aggregat frÄn tidigare inladdade data, utan ocksÄ ladda/formera nya data i databasen. Det vill sÀga, det kan vara en förfrÄgan som till exempel utför en insÀttning av nya poster i en annan tabell, vilket resulterar i att en ny partition skapas pÄ det berÀkningsklustret, som i sin tur automatiskt sparas i det gemensamma S3-lagringsutrymmet.
Det beskrivna scenariot, frÄn det att anvÀndaren kommer in tills klustret startas, dataladdning, utförande av förfrÄgningar, och mottagande av resultat, faktureras per minut för anvÀndningen av det uppstartade virtuella berÀkningsklustret, det virtuella lagret. Avgiften varierar beroende pÄ AWS-zon och storlek pÄ klustret, men i genomsnitt handlar det om nÄgra dollar i timmen. Klustret med fyra maskiner Àr dubbelt sÄ dyrt som klustret med tvÄ maskiner, och klustret med Ätta maskiner Àr dubbelt sÄ dyrt som det med fyra. Alternativ med 16, 32 maskiner finns tillgÀngliga beroende pÄ komplexiteten hos förfrÄgningarna. Men du betalar endast för de minuter som klustret verkligen arbetar, eftersom, nÀr det inte finns nÄgra förfrÄgningar, kan du som det vore lÀgga ner hÀnderna, och efter 5-10 minuters vÀntan (anpassningsbar parameter) kommer det automatiskt att stÀngas av, frigöra resurser och bli gratis.
Det Àr helt realistiskt att ett scenario dÀr du skickar en begÀran, klustret dyker upp, för att sÀga, pÄ en minut, ytterligare en minut för att rÀkna, fem minuter för stÀngning, och du betalar till slut för sju minuters arbete av det klustret, istÀllet för mÄnader och Är.
Det första scenariot beskrev anvÀndningen av Snowflake i en enskild anvÀndare-version. Nu lÄt oss förestÀlla oss att det finns mÄnga anvÀndare, vilket Àr nÀrmare ett verkligt scenario.
Anta att vi har mÄnga analytiker och Tableau-rapporter som stÀndigt bombarderar vÄr databas med en stor mÀngd enkla analytiska SQL-frÄgor.
Dessutom, lÄt oss anta att vi har pÄhittiga Data Scientists som försöker göra monsterartade saker med data, hantera tiotals terabyte, analysera miljarder och triljoner rader data.
För de tvÄ typerna av belastning som beskrivits ovan tillÄter Snowflake att flera oberoende berÀkningskluster av olika kapaciteter upprÀttas. Dessa berÀkningskluster arbetar oberoende men med gemensamma koordinerade data.
För ett stort antal lĂ€tta frĂ„gor kan man upprĂ€tta 2-3 smĂ„ kluster, som var och en bestĂ„r av, sĂ€g, 2 maskiner. Detta beteende kan implementeras, bland annat, med hjĂ€lp av automatiska instĂ€llningar. Det vill sĂ€ga, du sĂ€ger: âSnowflake, upprĂ€tta ett litet kluster. Om belastningen pĂ„ det ökar över en viss parameter, upprĂ€tta en liknande andra, tredje. NĂ€r belastningen börjar avta - stĂ€ng av överskottetâ. SĂ„ att oavsett hur mĂ„nga analytiker som kommer och börjar titta pĂ„ rapporterna, har alla tillrĂ€ckligt med resurser.
Om analytikerna sover, och rapporterna inte tittas pÄ - kan klustren helt stÀngas av, och du slutar betala för dem.
För tunga frÄgor (frÄn Data Scientists) kan du upprÀtta ett mycket stort kluster bestÄende av hypotetiska 32 maskiner. Detta kluster kommer ocksÄ att debiteras endast för de minuter och timmar nÀr din gigantiska frÄga körs dÀr.
Den beskrivna möjligheten ovan gör det möjligt att dela upp kluster inte bara i 2, utan Àven i fler typer av belastningar (ETL, övervakning, materialisering av rapporter,⊠).
Sammanfattningsvis om Snowflake. Databasen kombinerar en vacker idé med en fungerande implementation. PÄ ManyChat anvÀnder vi Snowflake för att analysera all tillgÀnglig data. Vi har inte tre kluster som i exemplet, utan mellan 5 och 9, i olika storlekar. Vi har sÄ kallade 16-maskins och 2-maskins-kluster, samt supersmÄ 1-maskins-kluster för vissa uppgifter. De fördelar lasten effektivt och hjÀlper oss att spara pengar.
Databasen skalar framgÄngsrikt bÄde lÀs- och skrivbelastning. Detta Àr en stor skillnad och ett stort genombrott jÀmfört med "Aurora", som endast hanterade lÀsbelastning. Snowflake möjliggör att skala skrivbelastningen med dessa berÀkningskluster. SÄ, som jag nÀmnde, anvÀnder vi flera kluster pÄ ManyChat, smÄ och super-smÄ kluster anvÀnds frÀmst för ETL, för att ladda data. Och analytiker anvÀnder de medelstora kluster som absolut inte pÄverkas av ETL-belastningen, vilket gör att de arbetar mycket snabbt.
DÀrmed passar databasen bra för OLAP-uppgifter. TyvÀrr Àr den dock Ànnu inte tillÀmplig för OLTP-belastningar. För det första Àr denna databas kolumnbaserad, med alla dÀrav följande konsekvenser. För det andra Àr tillvÀgagÄngssÀttet att du vid varje begÀran vid behov aktiverar ett berÀkningskluster och matar in data i det, tyvÀrr fortfarande inte tillrÀckligt snabbt för OLTP-belastningar. SekundÀra vÀntetider för OLAP-uppgifter Àr acceptabla, men för OLTP-uppgifter Àr det oacceptabelt; det skulle helst vara 100 ms, Ànnu bÀttre 10 ms.
Resultat
Serverless databas Ă€r möjlig tack vare uppdelningen av databasen i Stateless och Stateful delar. Du har sĂ€kert lagt mĂ€rke till att i alla de givna exemplen, sĂ„ Ă€r Stateful-delen â sĂ„ att sĂ€ga â lagringen av mikro-partitioner i S3, medan Stateless Ă€r optimeraren, arbetet med metadata, och hanteringen av sĂ€kerhetsfrĂ„gor som kan lyftas som oberoende lĂ€ttvikts Stateless-tjĂ€nster.
Utförande av SQL-frÄgor kan ocksÄ ses som tjÀnster med ett lÀtt state, som kan dyka upp i serverless-lÀge, likt Snowflake berÀkningskluster, hÀmta endast nödvÀndig data, utföra frÄgan och "slÀckas".
Serverless-databaser av produktionsnivÄ Àr nu tillgÀngliga för anvÀndning och fungerar. Dessa serverless-databaser Àr redan redo att hantera OLAP-uppgifter. TyvÀrr anvÀnds de för OLTP-uppgifter... med vissa nyanser, dÄ det finns begrÀnsningar. à ena sidan Àr det en nackdel. Men Ä andra sidan Àr det en möjlighet. Kanske hittar nÄgon av lÀsarna ett sÀtt att göra en OLTP-databas helt serverless, utan begrÀnsningar frÄn Aurora.
Jag hoppas att ni tyckte det var intressant. För serverless framtid đ
KĂ€lla: habr.com
