Ajutine andmehoidla puhastatakse, ressursid vabastatakse.<\/li>\n<\/ul>\nSelles arhitektuuris maksame ainult p\u00e4ringu t\u00e4itmise protsessi eest. Pole p\u00e4ringuid \u2014 pole kulusid.<\/p>\n
Athena n\u00e4itel on n\u00e4ha, et Serverless andmebaas toimib tegelike p\u00e4ringute p\u00f5hjal, millega k\u00e4sitletakse k\u00fcmneid ja sadu terabaiti andmeid. Saja terabaiti jaoks on vajalik sadu servereid, kuid me ei pea nende eest maksma \u2014 maksame p\u00e4ringute eest. Iga p\u00e4ringu kiirus on (v\u00e4ga) madal v\u00f5rreldes spetsialiseeritud anal\u00fc\u00fctiliste andmebaasidega nagu Vertica, kuid me ei maksa seisakute eest.<\/p>\n
Selline andmebaas on rakendatav harvade anal\u00fc\u00fctiliste ad-hoc p\u00e4ringute jaoks. N\u00e4iteks siis, kui otsustame spontaanselt kontrollida h\u00fcpoteesi hiiglaslikus andmemahtudes. Neid juhtumeid jaoks sobib Athena ideaalselt. Regulaarsete p\u00e4ringute puhul osutub selline s\u00fcsteem kalliks. Sel juhul salvestage andmed m\u00f5nes spetsialiseeritud lahenduses. <\/p>\n
Serverless OLTP lahenduste jaoks<\/h2>\n \nEelnevas n\u00e4ites vaadeldi OLAP-\u00fclesandeid (anal\u00fc\u00fctilised). N\u00fc\u00fcd vaatame OLTP-\u00fclesandeid.<\/p>\n
Kujundame skaleeritav PostgreSQL v\u00f5i MySQL. Loome tavalise hallatava instantsi PostgreSQL v\u00f5i MySQL minimaalsete ressurssidega. Kui instantsile tuleb rohkem koormust, \u00fchendame t\u00e4iendavaid koopiaid, kuhu jaotame osa lugemisekoormusest. Kui p\u00e4ringut ja koormust pole \u2014 l\u00fclitame koopiad v\u00e4lja. Esimene instants on peamine ja \u00fclej\u00e4\u00e4nud on koopiad.<\/p>\n
See idee on ellu viidud andmebaasis nimega Aurora Serverless AWS. Princips on lihtne: v\u00e4liste rakenduste p\u00e4ringud v\u00f5tab vastu proxy fleet. N\u00e4ha koormuse kasvu, eraldatakse arvutusressursid eelnevalt soojendatud minimaalsetest instantsidest \u2014 \u00fchendamine toimub maksimaalselt kiiresti. Instantside v\u00e4ljal\u00fclitamine toimub samuti.<\/p>\n
Aurora-s on m\u00f5isted Aurora Capacity Unit, ACU. See on (tinglikult) instants (server). Iga konkreetne ACU v\u00f5ib olla peamine v\u00f5i koopia. Igal Capacity Unit'il on oma operatiivm\u00e4lu, protsessor ja minimaalne ketas. Vastavalt on \u00fcks peamine ja \u00fclej\u00e4\u00e4nud ainult lugemiseks koopiad.<\/p>\n
Nende t\u00f6\u00f6tavate Aurora Capacity Unit'ide arv on seadistatav parameeter. Minimaalne arv v\u00f5ib olla \u00fcks v\u00f5i null (sel juhul andmebaas ei t\u00f6\u00f6ta, kui p\u00e4ringuid ei ole).<\/p>\n
Aurora Serverless andmebaas suudab skaleerida lugemisekoormust. Kuid dokumentatsioonis ei ole sellest otseselt \u00f6eldud. V\u00f5ib tekkida tunne, et nad saavad t\u00f5sta multi-masteri. Imesid pole siin aga. <\/p>\n
See and on infrusturi, et viia ei oleneb, kui ta ei ole l\u00fcganud s\u00fcsteemide. N\u00e4iteks, MVP v\u00f5i visiitkaardilehtede loomise puhul ei ootame tavaliselt stabiilset koormust. Seega, kui juurdep\u00e4\u00e4su ei ole, ei maksa me instantside eest. Kui ootamatult tekib koormus, n\u00e4iteks p\u00e4rast konverentsi v\u00f5i reklaamikampaaniat, plahvatavad ligip\u00e4\u00e4su ja koormus t\u00f5useb kiiresti, Aurora Serverless v\u00f5tab automaatselt selle koormuse ja kiirelt \u00fchendab lisav\u00e4hendused (ACU). J\u00e4rgmine konverents l\u00e4heb, k\u00f5ik unustavad protot\u00fc\u00fcbi, serverid (ACU) kustutatakse ja kulud langevad nulli \u2014 mugav.<\/p>\n
See lahendus ei sobi stabiilse k\u00f5rge koormuse korral, kuna see ei oska skaleerida kirjutamiskoormust. K\u00f5ik need ressursid \u00fchendavad ja lahti \u00fchendavad toimuvad nii-\u00f6elda 'scale point'i' hetkel \u2014 ajal, mil andmebaas ei ole tehingu all, ajutised tabelid ei hoia. N\u00e4iteks, n\u00e4dalas v\u00f5ib scale point mitte toimuda ja andmebaas t\u00f6\u00f6tab \u00fcksi ressursidega ning ei saa ei laieneda, ega v\u00e4heneda. <\/p>\n
Mingeid imesid ei ole \u2014 see on tavaline PostgreSQL. Kuid masinate lisamise ja lahti\u00fchendamise protsess on osaliselt automatiseeritud.<\/p>\n
Serverless by design<\/h2>\n \nAurora Serverless on vana andmebaas, \u00fcmber kirjutatud pilve jaoks, et kasutada eraldi Serverless'i eeliseid. N\u00fc\u00fcd r\u00e4\u00e4gin andmebaasist, mis on algselt kirjutatud pilve jaoks, serverless l\u00e4henemise alla \u2014 Serverless-by-design. Seda arendati kohe ilma eelduseta, et see t\u00f6\u00f6tab f\u00fc\u00fcsilistel serveritel.<\/p>\n
See andmebaas on nimega Snowflake. Sellel on kolm peamist plokki.<\/p>\n
Teine plokk \u2014 see on hulk virtuaalseid arvutusklastreid arvutuste jaoks (joonisel \u2014 siniste ringide kogum).<\/p>\n
Kolmas plokk \u2014 andmete salvestamise s\u00fcsteem, mis p\u00f5hineb S3-l. S3 on m\u00f5\u00f5tmeteta objektide salvestus AWS-is, just nagu m\u00f5\u00f5tmeteta Dropbox ettev\u00f5tetele.<\/p>\n
Vaadake, kuidas Snowflake t\u00f6\u00f6tab k\u00fclma k\u00e4ivitamise eeldustes. See t\u00e4hendab, et andmebaas on olemas, andmed on laaditud, kuid t\u00f6\u00f6tavaid p\u00e4ringuid pole. Seega, kui andmebaasi ei tule p\u00e4ringuid, siis on meil \u00fcles t\u00f5stetud kiire in-memory Metaandmete teenus (esimene plokk). Ja meil on S3 salvestus, kus on andmed tabelite kohta, jagatud nn mikropartiidesse. Lihtsuse huvides: kui tabelis on tehingud, siis on mikropartiid tehingute p\u00e4evad. Iga p\u00e4ev on eraldi mikroparti, eraldi fail. Ja kui andmebaas t\u00f6\u00f6tab sellises re\u017eiimis, maksate ainult andmete kasutatud koha eest. Lisaks on koha maksumus v\u00e4ga madal (eriti arvestades olulist tihendamist). Metaandmete teenus t\u00f6\u00f6tab samuti pidevalt, kuid p\u00e4ringute optimeerimise jaoks ei ole palju ressursse vajalik, seega v\u00f5ib teenust pidada tinglikult tasuta. <\/p>\n
N\u00fc\u00fcd kujutame ette, et meie andmebaasi on tulnud kasutaja ja esitanud SQL-p\u00e4ringu. SQL-p\u00e4ring saadetakse kohe t\u00f6\u00f6tlemiseks Metaandmete teenusele. Seega, p\u00e4rast p\u00e4ringu saamist, anal\u00fc\u00fcsib see teenus p\u00e4ringut, saadaval olevaid andmeid, kasutaja \u00f5igusi ja kui k\u00f5ik on h\u00e4sti, koostab t\u00f6\u00f6tlemise plaani.<\/p>\n
Seej\u00e4rel k\u00e4ivitab teenus arvutusklastri. Arvutusklaster on serverite klaster, mis teostab arvutusi. See t\u00e4hendab, et klaster v\u00f5ib sisaldada 1 serverit, 2 serverit, 4, 8, 16, 32 \u2014 nii palju kui soovite. Te esitate p\u00e4ringu ja selle jaoks algab klastrite k\u00e4ivitamine sekundite jooksul.<\/p>\n
Iga SQL-p\u00e4ring mitte ainult ei loe agrageeritud andmeid varasemalt laaditud andmetest, vaid v\u00f5ib ka laadida\/luua uusi andmeid andmebaasis. See t\u00e4hendab, et see v\u00f5ib olla p\u00e4ring, mis n\u00e4iteks sisestab teise tabelisse uusi kirjeid, mis toob kaasa uue partitsiooni tekkimise arvutusklassis, mis omakorda salvestatakse automaatselt \u00fchte S3 salvestusse.<\/p>\n
\u00dclaltoodud stsenaarium, alates kasutaja saabumisest kuni klastrite t\u00f5stmiseni, andmete laadimine, p\u00e4ringute t\u00e4itmine ja tulemuste saamine, arvestatakse v\u00e4lja t\u00f5stetud virtuaalse arvutusklastri, virtuaalse ladustamise, kasutamise minutitasu alusel. Tasu varieerub s\u00f5ltuvalt AWS tsoonist ja klastrisuurusest, kuid keskmiselt on see paar dollarit tunnis. Neli masinat sisaldav klaster maksab kaks korda rohkem kui kaks masinat, kaheksa masinat maksab veel kaks korda rohkem. Saadaval on variandid 16, 32 masinaga, s\u00f5ltuvalt p\u00e4ringute keerukusest. Kuid te maksate ainult selle eest, kui klaster reaalselt t\u00f6\u00f6tab, kuna p\u00e4ringute puudumisel kui te nagu eemaldatud k\u00e4ed, ja p\u00e4rast 5-10-minutilist ootamist (kohandatav parameeter) l\u00fclitub see iseenesest v\u00e4lja, vabastab ressursid ja muutub tasuta.<\/p>\n
On t\u00e4iesti reaalne stsenaarium, kus esitades p\u00e4ringu kerkib klaster \u00fcles, nii \u00f6elda, minuti jooksul, veel minut ta arvutab, seej\u00e4rel viis minutit v\u00e4lja l\u00fclitamiseks, ning l\u00f5puks maksate te selle klastiku t\u00f6\u00f6 eest seitsme minuti alusel, mitte kuude ja aastate kaupa.<\/p>\n
Esimene stsenaarium kirjeldas Snowflake'i kasutamist \u00fchem\u00f5tmelises variandis. N\u00fc\u00fcd kujutame ette, et kasutajaid on palju, mis on juba l\u00e4hemal reaalsetele stsenaariumidele.<\/p>\n
Oletame, et meil on palju anal\u00fc\u00fctikuid ja Tableau aruandeid, mis pidevalt pommitavad meie andmebaasi suure hulga mitte liiga keeruliste anal\u00fc\u00fctiliste SQL-p\u00e4ringutega.<\/p>\n
Peale selle oletame, et meil on leidlikud andateadlased, kes proovivad andmetega hirmsaid asju teha, k\u00e4sitledes k\u00fcmneid terabaite, anal\u00fc\u00fcsides miljardeid ja triljoneid andmereale. <\/p>\n
\u00dclaltoodud kahe koormust\u00fc\u00fcbi jaoks v\u00f5imaldab Snowflake t\u00f5sta mitmeid s\u00f5ltumatuid arvutusklastreid erineva v\u00f5imsusega. Veel enam, need arvutusklastrid t\u00f6\u00f6tavad iseseisvalt, kuid jagavad \u00fchist koosk\u00f5lastatud teavet.<\/p>\n
Paljude kergete p\u00e4ringute jaoks saab t\u00f5sta 2-3 v\u00e4ikest klastrit, mis on suuruselt, \u00f6eldes tinglikult, 2 masinat iga\u00fches. See k\u00e4itumine on rakendatav ka automaatsete seadistuste abil. St \u00fctlete: \u201eSnowflake, t\u00f5sta v\u00e4ike klaster. Kui koormus sellel kasvab \u00fcle teatud parameetri, t\u00f5sta sarnane teine, kolmas. Kui koormus hakkab langema\u2014l\u00fclita liigsed v\u00e4lja.\u201d Selleks, et s\u00f5ltumata sellest, kui palju anal\u00fc\u00fctikuid tuleb ja aruandeid vaatab, jaguks k\u00f5igile ressursse.<\/p>\n
Sel juhul, kui anal\u00fc\u00fctikud magavad ja keegi aruandeid ei vaata \u2014 klastrid v\u00f5ivad t\u00e4ielikult v\u00e4lja l\u00fclituda, ja te l\u00f5petate nende eest maksmise.<\/p>\n
Samas, raskete p\u00e4ringute (andateadlastelt) jaoks v\u00f5ite t\u00f5sta \u00fche v\u00e4ga suure klastriga, n\u00e4iteks 32 masinat. Seda klastrit hakatakse samuti arvestama ainult nende minutite ja tundide eest, mil seal t\u00f6\u00f6tab teie hiiglaslik p\u00e4ring.<\/p>\n
\u00dclaltoodud v\u00f5imalus v\u00f5imaldab jagada klastreid mitte ainult kahe, vaid ka rohkemate koormust\u00fc\u00fcpide vahel (ETL, monitooring, aruannete materialiseerimine,\u2026).<\/p>\n
Teeme kokkuv\u00f5tte Snowflake'ist. Andmebaas \u00fchendab kauni idee ja t\u00f6\u00f6tava rakenduse. ManyChat'is kasutame Snowflake'i k\u00f5igi olemasolevate andmete anal\u00fc\u00fcsiks. Meil ei ole klastreid kolm, nagu n\u00e4ites, vaid 5 kuni 9, erineva suurusega. Meil on tinglikult 16-masinilised, 2-masinilised ning superv\u00e4ikesed 1-masinilised teatud \u00fclesannete jaoks. Nad jaotavad koormust t\u00f5husalt ja aitavad meil palju kokku hoida.<\/p>\n
Andmebaas suudab edukalt skaleerida nii lugemise kui kirjutamise koormust. See on tohutu erinevus ja suur l\u00e4bimurre v\u00f5rreldes n\u00e4iteks \u201eAurora\u2019ga\u201d, mis toetas vaid lugemise koormust. Snowflake v\u00f5imaldab nende arvutuste klastrite abil skaleerida ka kirjutamise koormust. Nagu mainisin, kasutame ManyChat'is mitut klastrit, kus v\u00e4ikesed ja superv\u00e4ikesed klastrid on peamiselt kasutusel ETL-ks, andmete laadimiseks. Anal\u00fc\u00fctikud t\u00f6\u00f6tavad keskmistel klastritel, mis ei puutu ETL-koormusse, seega t\u00f6\u00f6tavad nad v\u00e4ga kiiresti. <\/p>\n
Seega sobib andmebaas h\u00e4sti OLAP-\u00fclesannete jaoks. Kahjuks ei ole see veel rakendatav OLTP-koormuste jaoks. Esiteks on see andmebaas veergude p\u00f5hine, koos k\u00f5ikide sellest tulenevate tagaj\u00e4rgedega. Teiseks, ise l\u00e4henemine, kus iga p\u00e4ringu korral t\u00f5state vastavalt vajadusele arvutusklastri ja t\u00e4idate selle andmetega, on kahjuks OLTP-koormuste jaoks veel liiga aeglane. Sekundite ootamine OLAP-\u00fclesannete jaoks on normaalne, kuid OLTP-\u00fclesannete puhul on see vastuv\u00f5etamatu; parem oleks 100 ms, veel parem \u2014 10 ms.<\/p>\n
Kokkuv\u00f5te<\/h2>\n \nServerless andmebaas on v\u00f5imalik t\u00e4nu andmebaasi jagamisele staatless ja stateful osadeks. Olete kindlasti m\u00e4rganud, et k\u00f5igis toodud n\u00e4idetes on stateful osa \u2013 tinglikult \u00f6eldes, mikropartitsioonide salvestamine S3-s, samas kui stateless on optimeerija, tegevus metaandmetega, turvalisuse k\u00fcsimuste t\u00f6\u00f6tlemine, mida saab t\u00f5sta s\u00f5ltumatute kergete stateless teenustena.<\/p>\n
SQL-p\u00e4ringute t\u00e4itmist saab samuti v\u00e4lja v\u00f5tta teenustena, millel on kerge olek, mis v\u00f5ivad ilmuda serverless re\u017eiimis, nagu Snowflake'i arvutuskogud, alla laadida ainult vajalikud andmed, teostada p\u00e4ring ja \"surnud\".<\/p>\n
Serverless andmete baasid tootmisv\u00f5imsusega on juba kasutamiseks saadaval ja need t\u00f6\u00f6tavad. Need serverless andmebaasid on juba valmis toime tulema OLAP-\u00fclesannetega. Kahjuks kasutatakse neid OLTP-\u00fclesannete puhul... teatud erip\u00e4radega, kuna on piiranguid. \u00dchelt poolt on see miinus. Teiselt poolt on see v\u00f5imalus. V\u00f5ib-olla leiab m\u00f5ni lugeja viisi, kuidas OLTP-andmebaasi t\u00e4ielikult serverless'iks teha, ilma Aurora piiranguteta.<\/p>\n
Loodan, et see oli huvitav. Serverless'i tulevik on tulemas \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