The temporary storage is cleared, and resources are freed up.<\/li>\n<\/ul>\nIn this architecture, we only pay for the query execution process. No queries = no costs.<\/p>\n
The example of Athena shows that the Serverless database operates on real queries with tens and hundreds of terabytes of data. For hundreds of terabytes, we need hundreds of servers, but we don't have to pay for them \u2014 we pay for the queries. The speed of each query is (very) low compared to specialized analytical databases like Vertica, but we do not pay for downtime.<\/p>\n
Such a database is applicable for rare analytical ad-hoc queries. For example, when we spontaneously decide to test a hypothesis on a massive volume of data. For these cases, Athena is ideal. For regular queries, such a system becomes costly. In this case, cache the data in some specialized solution. <\/p>\n
Serverless for OLTP solutions<\/h2>\n \nThe previous example discussed OLAP tasks (analytical). Now, let's consider OLTP tasks.<\/p>\n
Lad os forestille os en skalerbar PostgreSQL eller MySQL. Lad os oprette en almindelig managed instance PostgreSQL eller MySQL med minimale ressourcer. N\u00e5r der kommer mere belastning p\u00e5 instansen, tilslutter vi ekstra replikaer, som vi fordeler en del af l\u00e6sebelastningen til. Hvis der ikke er nogen foresp\u00f8rgsler og belastning, slukker vi for replikaerne. Den f\u00f8rste instans er master, mens de \u00f8vrige er replikaer.<\/p>\n
Denne id\u00e9 er realiseret i en database kaldet Aurora Serverless AWS. Princippet er enkelt: foresp\u00f8rgsler fra eksterne applikationer modtages af en proxy-fl\u00e5de. N\u00e5r den ser en stigning i belastningen, tildeler den beregningsressourcer fra forvarmede minimale instanser - tilslutningen sker s\u00e5 hurtigt som muligt. Afbrydelse af instanserne sker ogs\u00e5 p\u00e5 samme m\u00e5de.<\/p>\n
Inden for Aurora findes begrebet Aurora Capacity Unit, ACU. Dette er (betegnet) en instans (server). Hver specifik ACU kan v\u00e6re master eller slave. Hver Capacity Unit har sit eget RAM, processor og minimal disk. Dermed er \u00e9n master, mens de \u00f8vrige er read-only replikaer.<\/p>\n
Antallet af aktive Aurora Capacity Units er en konfigurerbar parameter. Det minimale antal kan v\u00e6re en eller nul (i s\u00e5 fald virker databasen ikke, hvis der ikke er foresp\u00f8rgsler).<\/p>\n
Aurora Serverless-databasen kan skalere l\u00e6sebelastningen. Men dette n\u00e6vnes ikke direkte i dokumentationen. Der kan opst\u00e5 en f\u00f8lelse af, at de kan konfigurere multi-master. Der er dog ikke nogen magi involveret. <\/p>\n
Denne database er velegnet til at spare penge p\u00e5 systemer med uforudsigelig adgang. For eksempel, n\u00e5r vi opretter MVP'er eller marketinglandingssider, forventer vi normalt ikke stabil belastning. Derfor betaler vi ikke for instanser, n\u00e5r der ikke er adgang. N\u00e5r der pludselig opst\u00e5r belastning, for eksempel efter en konference eller reklamekampagne, bes\u00f8ger mange mennesker siden, og belastningen stiger pludseligt. Aurora Serverless h\u00e5ndterer automatisk denne belastning og tilslutter hurtigt de n\u00f8dvendige ressourcer (ACU). Efter konferencen glemmer alle prototypen, serverne (ACU) slukker, og omkostningerne falder til nul \u2014 det er praktisk.<\/p>\n
Denne l\u00f8sning er ikke velegnet til stabil h\u00f8j belastning, fordi den ikke kan skalere skrivebelastningen. Alle disse tilslutninger og frakoblinger af ressourcer sker p\u00e5 et s\u00e5kaldt 'scale point' \u2014 det tidspunkt, hvor databasen ikke er under en transaktion, og der ikke holdes midlertidige tabeller. For eksempel kan der i l\u00f8bet af en uge ikke ske et scale point, og databasen fungerer med de samme ressourcer og kan simpelthen hverken udvides eller samles. <\/p>\n
Der er ikke noget magisk \u2014 det er almindelig PostgreSQL. Men processen med at tilf\u00f8je maskiner og frakoble dem er delvist automatiseret.<\/p>\n
Serverless by design<\/h2>\n \nAurora Serverless er en gammel database, der er omskrevet til skyen for at udnytte de unikke fordele ved Serverless. Og nu vil jeg fort\u00e6lle om en database, der oprindeligt er skrevet til skyen, til en serverless tilgang \u2014 Serverless-by-design. Den blev straks udviklet uden antagelsen om, at den k\u00f8rte p\u00e5 fysiske servere.<\/p>\n
Denne database kaldes Snowflake. Den har tre n\u00f8glekomponenter.<\/p>\n
Den anden blok er et stort antal virtuelle compute-klynger til beregninger (i illustrationen \u2014 en samling bl\u00e5 cirkler).<\/p>\n
Den tredje blok er et datalagringssystem baseret p\u00e5 S3. S3 er en ubegribelig objektlagring i AWS, lidt som en ubegribelig Dropbox til virksomheder.<\/p>\n
Lad os se, hvordan Snowflake fungerer under antagelse af en kold start. Det vil sige, at databasen eksisterer, dataene er indl\u00e6st, og der er ingen aktive foresp\u00f8rgsler. Hvis der ikke er nogen foresp\u00f8rgsler mod databasen, s\u00e5 har vi den hurtige in-memory Metadata service (den f\u00f8rste blok) k\u00f8rende. Og vi har et S3-lager, hvor tabellerne er gemt, opdelt i s\u00e5kaldte mikropartitioner. For enkelhedens skyld: hvis tabellen indeholder handler, s\u00e5 er mikropartitionerne dage med handler. Hver dag er en separat mikropartition, en separat fil. N\u00e5r databasen k\u00f8rer i dette tilstand, betaler du kun for det plads, der optages af dataene. Desuden er taksten for pladsen meget lav (is\u00e6r i betragtning af den betydelige komprimering). Metadata tjenesten k\u00f8rer ogs\u00e5 konstant, men kr\u00e6ver ikke mange ressourcer for at optimere foresp\u00f8rgsler, og tjenesten kan betragtes som betinget gratis. <\/p>\n
Lad os nu forestille os, at en bruger kommer til vores database og sender en SQL-foresp\u00f8rgsel. SQL-foresp\u00f8rgslen sendes straks til behandling i Metadata tjenesten. Tjenesten analyserer foresp\u00f8rgslen, de tilg\u00e6ngelige data, brugerens rettigheder, og hvis alt er i orden, udarbejder den en behandlingsplan for foresp\u00f8rgslen.<\/p>\n
Derefter initierer tjenesten opstarten af \u200b\u200bberegningsklusteret. Beregningsklusteret er et cluster af servere, der udf\u00f8rer beregninger. Det er et cluster, der kan indeholde 1 server, 2 servere, 4, 8, 16, 32 \u2014 s\u00e5 mange du \u00f8nsker. Du sender en foresp\u00f8rgsel, og der startes straks dette cluster. Det tager virkelig kun sekunder.<\/p>\n
Hver SQL-anmodning kan ikke kun l\u00e6se aggregater fra tidligere indl\u00e6ste data, men ogs\u00e5 indl\u00e6se\/andre nye data i databasen. Det vil sige, det kan v\u00e6re en anmodning, der for eksempel foretage en inds\u00e6ttelse af nye poster i en anden tabel, hvilket f\u00f8rer til oprettelsen af en ny partition p\u00e5 beregningsklyngen, som automatisk gemmes i det samlede S3-lager.<\/p>\n
Det ovenfor beskrevne scenarie, fra brugerens ankomst til klyngens oprettelse, dataloading, udf\u00f8relse af foresp\u00f8rgsler og modtagelse af resultater, afregnes med en takst pr. minut for brugen af den oprettede virtuelle beregningsklynge, den virtuelle warehouse. Taksten varierer afh\u00e6ngigt af AWS-zonen og klyngeens st\u00f8rrelse, men i gennemsnit koster det nogle f\u00e5 dollars i timen. En klynge med fire maskiner koster det dobbelte af en med to maskiner, og en med otte maskiner koster yderligere det dobbelte. Der er muligheder for 16, 32 maskiner, alt efter kompleksiteten af foresp\u00f8rgslerne. Men du betaler kun for de minutter, hvor klyngen faktisk er aktiv, fordi n\u00e5r der ikke er nogen foresp\u00f8rgsler, kan du n\u00e6sten tr\u00e6kke h\u00e6nderne v\u00e6k, og efter 5-10 minutters ventetid (justerbar parameter) slukker den selv, frigiver ressourcer og bliver gratis.<\/p>\n
Det er helt realistisk, at du sender en foresp\u00f8rgsel, og klustret dukker op, s\u00e5 at sige, p\u00e5 et minut. Det tager et minut at beregne, yderligere fem minutter til at slukke, og du betaler i sidste ende for syv minutters brug af dette kluster i stedet for m\u00e5neder og \u00e5r.<\/p>\n
Det f\u00f8rste scenarie beskrev brugen af Snowflake i en enkeltbruger-ops\u00e6tning. Lad os nu forestille os, at der er mange brugere, hvilket er t\u00e6ttere p\u00e5 et realistisk scenarie.<\/p>\n
Lad os antage, at vi har mange analytikere og Tableau-rapporter, der konstant bombarderer vores database med et stort antal enkle analytiske SQL-foresp\u00f8rgsler.<\/p>\n
Derudover, lad os antage, at vi har opfindsomme dataforskere, der fors\u00f8ger at g\u00f8re frygtelige ting med dataene, arbejde med titusinder af terabyte, analysere milliarder og billioner af r\u00e6kker af data. <\/p>\n
For de to typer belastning, der er beskrevet ovenfor, tillader Snowflake at ops\u00e6tte flere uafh\u00e6ngige beregningsklustre med forskellig kapacitet. Disse beregningsklustre arbejder uafh\u00e6ngigt, men med f\u00e6lles konsistente data.<\/p>\n
For et stort antal lette foresp\u00f8rgsler kan du ops\u00e6tte 2-3 sm\u00e5 klustre, hver med en st\u00f8rrelse p\u00e5, lad os sige, 2 maskiner. Denne adf\u00e6rd kan implementeres, blandt andet, ved hj\u00e6lp af automatiske indstillinger. Det vil sige, at du siger: \"Snowflake, ops\u00e6t et lille kluster. Hvis belastningen p\u00e5 det overstiger et bestemt parameter, ops\u00e6t en tilsvarende anden eller tredje. N\u00e5r belastningen begynder at falde \u2014 sluk for de overskydende.\" S\u00e5 alle f\u00e5r nok ressourcer uanset hvor mange analytikere der kommer og begynder at se rapporterne.<\/p>\n
Hvis analytikerne derimod sover, og ingen ser p\u00e5 rapporterne, kan klustrene helt slukkes, og du stopper med at betale for dem.<\/p>\n
For tunge foresp\u00f8rgsler (fra dataforskere) kan du ops\u00e6tte et meget stort kluster med for eksempel 32 maskiner. Dette kluster vil ogs\u00e5 kun blive betalt for de minutter og timer, hvor dit enorme foresp\u00f8rgsel k\u00f8rer.<\/p>\n
Den ovenfor beskrevne mulighed g\u00f8r det muligt at opdele ikke kun 2, men ogs\u00e5 flere typer belastninger (ETL, overv\u00e5gning, materialisering af rapporter,\u2026).<\/p>\n
Lad os opsummere Snowflake. Databasen kombinerer en smuk id\u00e9 med en fungerende implementering. I ManyChat bruger vi Snowflake til analyse af alle tilg\u00e6ngelige data. Vi har ikke tre klynger som i eksemplet, men mellem 5 og 9, forskellige st\u00f8rrelser. Vi har nogle med 16 maskiner, 2-maskiner, og der er ogs\u00e5 super sm\u00e5 1-maskine klynger til visse opgaver. De fordeler belastningen effektivt og hj\u00e6lper os med at spare penge.<\/p>\n
Databasen skalerer effektivt b\u00e5de l\u00e6se- og skrivebelastningen. Dette er en betydelig forskel og et stort gennembrud sammenlignet med \"Aurora\", som kun kunne h\u00e5ndtere l\u00e6sebelastning. Snowflake muligg\u00f8r skalering af disse beregningsklynger til ogs\u00e5 at h\u00e5ndtere skrivebelastning. Som n\u00e6vnt bruger vi i ManyChat flere klynger; sm\u00e5 og super sm\u00e5 klynger bruges prim\u00e6rt til ETL, til dataindl\u00e6sning. Analytikere arbejder allerede p\u00e5 mellemstore klynger, som slet ikke p\u00e5virkes af ETL-belastningen, og derfor arbejder de meget hurtigt. <\/p>\n
Derfor er databasen velegnet til OLAP-opgaver. Desv\u00e6rre er den dog endnu ikke anvendelig til OLTP-belastninger. For det f\u00f8rste er databasen kolonnebaseret, med alle de konsekvenser, det indeb\u00e6rer. For det andet er den tilgang, hvor man efter behov aktiverer en beregningsklynge for hver foresp\u00f8rgsel og fylder den med data, desv\u00e6rre ikke hurtig nok til OLTP-belastninger. Sekunder af ventetid for OLAP-opgaver er normalt, men for OLTP-opgaver er det uacceptabelt; 100 ms ville v\u00e6re bedre, og 10 ms ville v\u00e6re endnu bedre.<\/p>\n
Resultat<\/h2>\n \nEn serverless database er mulig ved at opdele databasen i stateless og stateful dele. Du har m\u00e5ske bem\u00e6rket, at i alle de n\u00e6vnte eksempler er den stateful del, s\u00e5 at sige, opbevaringen af mikropartitioner i S3, mens den stateless del er optimereren, der arbejder med metadata, h\u00e5ndterer sikkerhedssp\u00f8rgsm\u00e5l, som kan aktiveres som uafh\u00e6ngige, letv\u00e6gts stateless services.<\/p>\n
Udf\u00f8relsen af SQL-foresp\u00f8rgsler kan ogs\u00e5 betragtes som tjenester med en let state, der kan aktivere i serverless tilstand, ligesom beregningsklynger i Snowflake, hente kun de n\u00f8dvendige data, udf\u00f8re foresp\u00f8rgslen og \"slukke\".<\/p>\n
Serverless databaser p\u00e5 produktionsniveau er nu tilg\u00e6ngelige og fungerer. Disse serverless databaser er allerede klar til at h\u00e5ndtere OLAP-opgaver. Desv\u00e6rre anvendes de til OLTP-opgaver... med nuancer, da der er begr\u00e6nsninger. P\u00e5 den ene side er det et minus. Men p\u00e5 den anden side er det en mulighed. M\u00e5ske finder nogle af l\u00e6serne en m\u00e5de at g\u00f8re en OLTP-database helt serverless uden begr\u00e6nsninger i Aurora.<\/p>\n
Jeg h\u00e5ber, det har v\u00e6ret interessant for dig. For serverless fremtiden \ud83d\ude42habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0413\u043e\u043b\u043e\u0432 \u041d\u0438\u043a\u043e\u043b\u0430\u0439. \u0420\u0430\u043d\u044c\u0448\u0435 \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u043b \u0432 \u0410\u0432\u0438\u0442\u043e \u0438 \u0448\u0435\u0441\u0442\u044c \u043b\u0435\u0442 \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u043b Data Platform, \u0442\u043e \u0435\u0441\u0442\u044c \u0437\u0430\u043d\u0438\u043c\u0430\u043b\u0441\u044f \u0432\u0441\u0435\u043c\u0438 \u0431\u0430\u0437\u0430\u043c\u0438: \u0430\u043d\u0430\u043b\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u043c\u0438 (Vertica, ClickHouse), \u043f\u043e\u0442\u043e\u043a\u043e\u0432\u044b\u043c\u0438 \u0438 OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). \u0417\u0430 \u044d\u0442\u043e \u0432\u0440\u0435\u043c\u044f \u044f \u0440\u0430\u0437\u043e\u0431\u0440\u0430\u043b\u0441\u044f \u0441 \u0431\u043e\u043b\u044c\u0448\u0438\u043c \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e\u043c \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 \u2014 \u0441\u0430\u043c\u044b\u0445 \u0440\u0430\u0437\u043d\u044b\u0445 \u0438 \u043d\u0435\u043e\u0431\u044b\u0447\u043d\u044b\u0445, \u0438 \u0441 \u043d\u0435\u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442\u043d\u044b\u043c\u0438 \u043a\u0435\u0439\u0441\u0430\u043c\u0438 \u0438\u0445 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f. \u0421\u0435\u0439\u0447\u0430\u0441 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91636,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91635","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t