Det tempor\u00e4ra lagret rensas, resurser frig\u00f6rs.<\/li>\n<\/ul>\nI denna arkitektur betalar vi endast f\u00f6r processen att utf\u00f6ra fr\u00e5gan. Inga fr\u00e5gor - inga kostnader.<\/p>\n
Exemplet med Athena visar att Serverless-databaser fungerar med verkliga fr\u00e5gor med tiotals och hundratals terabyte data. F\u00f6r hundratals terabyte beh\u00f6vs hundratals servrar, men vi beh\u00f6ver inte betala f\u00f6r dem - vi betalar f\u00f6r fr\u00e5gorna. Hastigheten f\u00f6r varje fr\u00e5ga \u00e4r (mycket) l\u00e5g j\u00e4mf\u00f6rt med specialiserade analytiska databaser som Vertica, men vi betalar inte f\u00f6r stillast\u00e5ende tid.<\/p>\n
En s\u00e5dan databas \u00e4r till\u00e4mpbar f\u00f6r s\u00e4llsynta analytiska ad-hoc fr\u00e5gor. Till exempel, n\u00e4r vi spontant beslutar att testa en hypotes p\u00e5 ett enormt datam\u00e4ngd. F\u00f6r dessa fall \u00e4r Athena perfekt. F\u00f6r regelbundna fr\u00e5gor blir ett s\u00e5dant system dyrt. I detta fall, cache data i en specialiserad l\u00f6sning. <\/p>\n
Serverless f\u00f6r OLTP-l\u00f6sningar<\/h2>\n \nI det f\u00f6reg\u00e5ende exemplet diskuterades OLAP-uppgifter (analytiska). Nu ser vi p\u00e5 OLTP-uppgifter.<\/p>\n
L\u00e5t oss t\u00e4nka oss en skalbar PostgreSQL eller MySQL. Vi ska starta en vanlig managed instans av PostgreSQL eller MySQL med minimala resurser. N\u00e4r instansen f\u00e5r mer belastning kommer vi att ansluta ytterligare repliker, som vi f\u00f6rdelar en del av l\u00e4sbelastningen p\u00e5. Om det inte finns n\u00e5gra f\u00f6rfr\u00e5gningar eller belastning st\u00e4nger vi av replikerna. Den f\u00f6rsta instansen \u00e4r master, medan de \u00f6vriga \u00e4r repliker.<\/p>\n
Denna id\u00e9 realiseras i en databas som kallas Aurora Serverless AWS. Principen \u00e4r enkel: f\u00f6rfr\u00e5gningar fr\u00e5n externa applikationer tas emot av en proxyflotta. N\u00e4r den ser en \u00f6kning av belastningen tilldelar den ber\u00e4kningsresurser fr\u00e5n f\u00f6rv\u00e4g uppv\u00e4rmda minimala instanser \u2014 anslutningen sker s\u00e5 snabbt som m\u00f6jligt. Avst\u00e4ngning av instanser sker p\u00e5 samma s\u00e4tt.<\/p>\n
Inom Aurora finns begreppet Aurora Capacity Unit, ACU. Detta \u00e4r (villkorligt) en instans (server). Varje specifik ACU kan vara master eller slave. Varje Capacity Unit har sin egen RAM, processor och minimal disk. F\u00f6ljaktligen \u00e4r en master och de \u00f6vriga skrivskyddade repliker.<\/p>\n
Antalet aktiva Aurora Capacity Units \u00e4r en konfigurerbar parameter. Det minimiantal som kan s\u00e4ttas \u00e4r ett eller noll (i s\u00e5 fall fungerar inte databasen om det inte finns n\u00e5gra f\u00f6rfr\u00e5gningar).<\/p>\n
Aurora Serverless-databasen kan skala l\u00e4sbelastningen. Men detta n\u00e4mns inte uttryckligen i dokumentationen. Det kan bli en k\u00e4nsla av att de kan skapa en multi-master. Det finns dock inget magiskt med det. <\/p>\n
Denna databas \u00e4r v\u00e4l l\u00e4mpad f\u00f6r att undvika att spendera stora pengar p\u00e5 system med of\u00f6ruts\u00e4gbart tillg\u00e5ng. Till exempel, n\u00e4r vi skapar MVP eller marknadsf\u00f6ringssajter, f\u00f6rv\u00e4ntar vi oss vanligtvis inte en stabil belastning. D\u00e4rf\u00f6r, vid brist p\u00e5 tillg\u00e5ng, betalar vi inget f\u00f6r instanser. N\u00e4r belastningen pl\u00f6tsligt \u00f6kar, till exempel efter en konferens eller marknadsf\u00f6ringskampanj, kommer m\u00e5nga m\u00e4nniskor att bes\u00f6ka sajten och belastningen \u00f6kar snabbt; Aurora Serverless anpassar sig automatiskt till denna belastning och kopplar snabbt p\u00e5 de saknade resurserna (ACU). Efter konferensen gl\u00f6mmer alla prototypen, servrarna (ACU) st\u00e4ngs av, och kostnaderna faller till noll - mycket praktiskt.<\/p>\n
Denna l\u00f6sning \u00e4r inte l\u00e4mplig f\u00f6r stabil h\u00f6g belastning, eftersom den inte kan skala den skrivande belastningen. Alla dessa anslutningar och kopplingar av resurser sker vid den s\u00e5 kallade \u201eskala-punkten\u201d \u2014 tidpunkten n\u00e4r databasen inte h\u00e5lls av en transaktion, och inga tempor\u00e4ra tabeller h\u00e5lls. Till exempel, under en vecka kan det h\u00e4nda att ingen skala-punkt intr\u00e4ffar, och databasen arbetar med samma resurser och helt enkelt inte kan varken expandera eller minska. <\/p>\n
Det finns inget magiskt \u2014 detta \u00e4r vanlig PostgreSQL. Men processen f\u00f6r att l\u00e4gga till maskiner och st\u00e4nga av dem \u00e4r delvis automatiserad.<\/p>\n
Serverless by design<\/h2>\n \nAurora Serverless \u00e4r en gammal databas som skrivits om f\u00f6r molnet f\u00f6r att utnyttja de specifika f\u00f6rdelarna med Serverless. Nu kommer jag att prata om en databas som fr\u00e5n b\u00f6rjan \u00e4r skriven f\u00f6r molnet, under serverless-ansatsen \u2014 Serverless-by-design. Den designades utan f\u00f6ruts\u00e4ttningar om att den skulle fungera p\u00e5 fysiska servrar.<\/p>\n
Denna databas kallas Snowflake. Den har tre centrala block.<\/p>\n
Det andra blocket \u2014 en m\u00e4ngd virtuella ber\u00e4kningskluster f\u00f6r ber\u00e4kningar (i illustrationen \u2014 ett set av bl\u00e5 cirklar).<\/p>\n
Det tredje blocket \u2014 datalagringssystemet baserat p\u00e5 S3. S3 \u00e4r en dimensionl\u00f6s objektlagring i AWS, ett slags dimensionl\u00f6s Dropbox f\u00f6r f\u00f6retag.<\/p>\n
L\u00e5t oss titta p\u00e5 hur Snowflake fungerar under f\u00f6ruts\u00e4ttning av en kall start. Det vill s\u00e4ga att databasen finns, data \u00e4r laddad, men inga aktiva f\u00f6rfr\u00e5gningar g\u00f6rs. Om inga f\u00f6rfr\u00e5gningar g\u00f6rs mot databasen har vi en snabb in-memory Metadata-tj\u00e4nst uppe (den f\u00f6rsta blocket). Vi har ocks\u00e5 en S3-lagring d\u00e4r tabellernas data ligger uppdelad i s\u00e5 kallade mikropartitioner. F\u00f6renklat: om tabellen inneh\u00e5ller aff\u00e4rer, s\u00e5 \u00e4r mikropartitionerna dagar av aff\u00e4rer. Varje dag \u00e4r en separat mikropartition, en egen fil. N\u00e4r databasen fungerar i detta l\u00e4ge betalar du endast f\u00f6r det utrymme som data tar. Dessutom \u00e4r kostnaden f\u00f6r utrymme mycket l\u00e5g (s\u00e4rskilt med tanke p\u00e5 betydande kompression). Metadata-tj\u00e4nsten \u00e4r ocks\u00e5 st\u00e4ndigt verksam, men f\u00f6r att optimera f\u00f6rfr\u00e5gningarna kr\u00e4vs inte mycket resurser, och tj\u00e4nsten kan anses vara i praktiken kostnadsfri. <\/p>\n
Nu f\u00f6rest\u00e4ller vi oss att en anv\u00e4ndare har skickat en SQL-f\u00f6rfr\u00e5gan till v\u00e5r databas. SQL-f\u00f6rfr\u00e5gan skickas omedelbart f\u00f6r behandling till Metadata-tj\u00e4nsten. Tj\u00e4nsten analyserar f\u00f6rfr\u00e5gan, tillg\u00e4ngliga data, anv\u00e4ndarens beh\u00f6righeter, och om allt ser bra ut skapar den en plan f\u00f6r hur f\u00f6rfr\u00e5gan ska bearbetas.<\/p>\n
D\u00e4refter initierar tj\u00e4nsten starten av ett ber\u00e4kningskluster. Ber\u00e4kningsklustret \u00e4r ett kluster av servrar som utf\u00f6r ber\u00e4kningar. Det vill s\u00e4ga, det kan inneh\u00e5lla 1 server, 2 servrar, 4, 8, 16, 32 \u2013 s\u00e5 m\u00e5nga ni vill. Du skickar din f\u00f6rfr\u00e5gan och klustret startas omedelbart f\u00f6r den. Det tar verkligen sekunder.<\/p>\n
Varje SQL-f\u00f6rfr\u00e5gan kan inte bara r\u00e4kna aggregat fr\u00e5n tidigare inladdade data, utan ocks\u00e5 ladda\/formera nya data i databasen. Det vill s\u00e4ga, det kan vara en f\u00f6rfr\u00e5gan som till exempel utf\u00f6r en ins\u00e4ttning av nya poster i en annan tabell, vilket resulterar i att en ny partition skapas p\u00e5 det ber\u00e4kningsklustret, som i sin tur automatiskt sparas i det gemensamma S3-lagringsutrymmet.<\/p>\n
Det beskrivna scenariot, fr\u00e5n det att anv\u00e4ndaren kommer in tills klustret startas, dataladdning, utf\u00f6rande av f\u00f6rfr\u00e5gningar, och mottagande av resultat, faktureras per minut f\u00f6r anv\u00e4ndningen av det uppstartade virtuella ber\u00e4kningsklustret, det virtuella lagret. Avgiften varierar beroende p\u00e5 AWS-zon och storlek p\u00e5 klustret, men i genomsnitt handlar det om n\u00e5gra dollar i timmen. Klustret med fyra maskiner \u00e4r dubbelt s\u00e5 dyrt som klustret med tv\u00e5 maskiner, och klustret med \u00e5tta maskiner \u00e4r dubbelt s\u00e5 dyrt som det med fyra. Alternativ med 16, 32 maskiner finns tillg\u00e4ngliga beroende p\u00e5 komplexiteten hos f\u00f6rfr\u00e5gningarna. Men du betalar endast f\u00f6r de minuter som klustret verkligen arbetar, eftersom, n\u00e4r det inte finns n\u00e5gra f\u00f6rfr\u00e5gningar, kan du som det vore l\u00e4gga ner h\u00e4nderna, och efter 5-10 minuters v\u00e4ntan (anpassningsbar parameter) kommer det automatiskt att st\u00e4ngas av, frig\u00f6ra resurser och bli gratis.<\/p>\n
Det \u00e4r helt realistiskt att ett scenario d\u00e4r du skickar en beg\u00e4ran, klustret dyker upp, f\u00f6r att s\u00e4ga, p\u00e5 en minut, ytterligare en minut f\u00f6r att r\u00e4kna, fem minuter f\u00f6r st\u00e4ngning, och du betalar till slut f\u00f6r sju minuters arbete av det klustret, ist\u00e4llet f\u00f6r m\u00e5nader och \u00e5r.<\/p>\n
Det f\u00f6rsta scenariot beskrev anv\u00e4ndningen av Snowflake i en enskild anv\u00e4ndare-version. Nu l\u00e5t oss f\u00f6rest\u00e4lla oss att det finns m\u00e5nga anv\u00e4ndare, vilket \u00e4r n\u00e4rmare ett verkligt scenario.<\/p>\n
Anta att vi har m\u00e5nga analytiker och Tableau-rapporter som st\u00e4ndigt bombarderar v\u00e5r databas med en stor m\u00e4ngd enkla analytiska SQL-fr\u00e5gor.<\/p>\n
Dessutom, l\u00e5t oss anta att vi har p\u00e5hittiga Data Scientists som f\u00f6rs\u00f6ker g\u00f6ra monsterartade saker med data, hantera tiotals terabyte, analysera miljarder och triljoner rader data. <\/p>\n
F\u00f6r de tv\u00e5 typerna av belastning som beskrivits ovan till\u00e5ter Snowflake att flera oberoende ber\u00e4kningskluster av olika kapaciteter uppr\u00e4ttas. Dessa ber\u00e4kningskluster arbetar oberoende men med gemensamma koordinerade data.<\/p>\n
F\u00f6r ett stort antal l\u00e4tta fr\u00e5gor kan man uppr\u00e4tta 2-3 sm\u00e5 kluster, som var och en best\u00e5r av, s\u00e4g, 2 maskiner. Detta beteende kan implementeras, bland annat, med hj\u00e4lp av automatiska inst\u00e4llningar. Det vill s\u00e4ga, du s\u00e4ger: \u201eSnowflake, uppr\u00e4tta ett litet kluster. Om belastningen p\u00e5 det \u00f6kar \u00f6ver en viss parameter, uppr\u00e4tta en liknande andra, tredje. N\u00e4r belastningen b\u00f6rjar avta - st\u00e4ng av \u00f6verskottet\u201d. S\u00e5 att oavsett hur m\u00e5nga analytiker som kommer och b\u00f6rjar titta p\u00e5 rapporterna, har alla tillr\u00e4ckligt med resurser.<\/p>\n
Om analytikerna sover, och rapporterna inte tittas p\u00e5 - kan klustren helt st\u00e4ngas av, och du slutar betala f\u00f6r dem.<\/p>\n
F\u00f6r tunga fr\u00e5gor (fr\u00e5n Data Scientists) kan du uppr\u00e4tta ett mycket stort kluster best\u00e5ende av hypotetiska 32 maskiner. Detta kluster kommer ocks\u00e5 att debiteras endast f\u00f6r de minuter och timmar n\u00e4r din gigantiska fr\u00e5ga k\u00f6rs d\u00e4r.<\/p>\n
Den beskrivna m\u00f6jligheten ovan g\u00f6r det m\u00f6jligt att dela upp kluster inte bara i 2, utan \u00e4ven i fler typer av belastningar (ETL, \u00f6vervakning, materialisering av rapporter,\u2026 ).<\/p>\n
Sammanfattningsvis om Snowflake. Databasen kombinerar en vacker id\u00e9 med en fungerande implementation. P\u00e5 ManyChat anv\u00e4nder vi Snowflake f\u00f6r att analysera all tillg\u00e4nglig data. Vi har inte tre kluster som i exemplet, utan mellan 5 och 9, i olika storlekar. Vi har s\u00e5 kallade 16-maskins och 2-maskins-kluster, samt supersm\u00e5 1-maskins-kluster f\u00f6r vissa uppgifter. De f\u00f6rdelar lasten effektivt och hj\u00e4lper oss att spara pengar.<\/p>\n
Databasen skalar framg\u00e5ngsrikt b\u00e5de l\u00e4s- och skrivbelastning. Detta \u00e4r en stor skillnad och ett stort genombrott j\u00e4mf\u00f6rt med \"Aurora\", som endast hanterade l\u00e4sbelastning. Snowflake m\u00f6jligg\u00f6r att skala skrivbelastningen med dessa ber\u00e4kningskluster. S\u00e5, som jag n\u00e4mnde, anv\u00e4nder vi flera kluster p\u00e5 ManyChat, sm\u00e5 och super-sm\u00e5 kluster anv\u00e4nds fr\u00e4mst f\u00f6r ETL, f\u00f6r att ladda data. Och analytiker anv\u00e4nder de medelstora kluster som absolut inte p\u00e5verkas av ETL-belastningen, vilket g\u00f6r att de arbetar mycket snabbt. <\/p>\n
D\u00e4rmed passar databasen bra f\u00f6r OLAP-uppgifter. Tyv\u00e4rr \u00e4r den dock \u00e4nnu inte till\u00e4mplig f\u00f6r OLTP-belastningar. F\u00f6r det f\u00f6rsta \u00e4r denna databas kolumnbaserad, med alla d\u00e4rav f\u00f6ljande konsekvenser. F\u00f6r det andra \u00e4r tillv\u00e4gag\u00e5ngss\u00e4ttet att du vid varje beg\u00e4ran vid behov aktiverar ett ber\u00e4kningskluster och matar in data i det, tyv\u00e4rr fortfarande inte tillr\u00e4ckligt snabbt f\u00f6r OLTP-belastningar. Sekund\u00e4ra v\u00e4ntetider f\u00f6r OLAP-uppgifter \u00e4r acceptabla, men f\u00f6r OLTP-uppgifter \u00e4r det oacceptabelt; det skulle helst vara 100 ms, \u00e4nnu b\u00e4ttre 10 ms.<\/p>\n
Resultat<\/h2>\n \nServerless databas \u00e4r m\u00f6jlig tack vare uppdelningen av databasen i Stateless och Stateful delar. Du har s\u00e4kert lagt m\u00e4rke till att i alla de givna exemplen, s\u00e5 \u00e4r Stateful-delen \u2013 s\u00e5 att s\u00e4ga \u2013 lagringen av mikro-partitioner i S3, medan Stateless \u00e4r optimeraren, arbetet med metadata, och hanteringen av s\u00e4kerhetsfr\u00e5gor som kan lyftas som oberoende l\u00e4ttvikts Stateless-tj\u00e4nster.<\/p>\n
Utf\u00f6rande av SQL-fr\u00e5gor kan ocks\u00e5 ses som tj\u00e4nster med ett l\u00e4tt state, som kan dyka upp i serverless-l\u00e4ge, likt Snowflake ber\u00e4kningskluster, h\u00e4mta endast n\u00f6dv\u00e4ndig data, utf\u00f6ra fr\u00e5gan och \"sl\u00e4ckas\".<\/p>\n
Serverless-databaser av produktionsniv\u00e5 \u00e4r nu tillg\u00e4ngliga f\u00f6r anv\u00e4ndning och fungerar. Dessa serverless-databaser \u00e4r redan redo att hantera OLAP-uppgifter. Tyv\u00e4rr anv\u00e4nds de f\u00f6r OLTP-uppgifter... med vissa nyanser, d\u00e5 det finns begr\u00e4nsningar. \u00c5 ena sidan \u00e4r det en nackdel. Men \u00e5 andra sidan \u00e4r det en m\u00f6jlighet. Kanske hittar n\u00e5gon av l\u00e4sarna ett s\u00e4tt att g\u00f6ra en OLTP-databas helt serverless, utan begr\u00e4nsningar fr\u00e5n Aurora.<\/p>\n
Jag hoppas att ni tyckte det var intressant. F\u00f6r serverless framtid \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