Depozitul temporar este cur\u0103\u021bat, resursele sunt eliberate.<\/li>\n<\/ul>\n\u00cen aceast\u0103 arhitectur\u0103, pl\u0103tim doar pentru procesul de execu\u021bie a interog\u0103rii. F\u0103r\u0103 interog\u0103ri \u2014 f\u0103r\u0103 cheltuieli.<\/p>\n
Din exemplul Athena, se observ\u0103 c\u0103 baza de date Serverless func\u021bioneaz\u0103 cu interog\u0103ri reale av\u00e2nd zeci \u0219i sute de Terabai\u021bi de date. Pentru sute de Terabai\u021bi vor fi necesari sute de servere, dar nu trebuie s\u0103 pl\u0103tim pentru acestea \u2014 pl\u0103tim pentru interog\u0103ri. Viteza fiec\u0103rei interog\u0103ri este (foarte) sc\u0103zut\u0103 \u00een compara\u021bie cu bazele de date analitice specializate precum Vertica, dar \u00een schimb nu pl\u0103tim pentru perioadele de nefunc\u021bionare.<\/p>\n
Aceast\u0103 baz\u0103 de date este aplicabil\u0103 pentru interog\u0103ri analitice ad-hoc mai rare. De exemplu, atunci c\u00e2nd decidem spontan s\u0103 verific\u0103m o ipotez\u0103 pe o cantitate uria\u0219\u0103 de date. Pentru aceste cazuri, Athena este perfect\u0103. Pentru interog\u0103rile regulate, un astfel de sistem devine costisitor. \u00cen acest caz, face\u021bi cache pentru date \u00eentr-o solu\u021bie specializat\u0103. <\/p>\n
Serverless pentru solu\u021bii OLTP<\/h2>\n \n\u00cen exemplul anterior, au fost discutate sarcinile OLAP (analitice). Acum s\u0103 analiz\u0103m sarcinile OLTP.<\/p>\n
S\u0103 ne imagin\u0103m un PostgreSQL sau MySQL scalabil. S\u0103 ridic\u0103m o instan\u021b\u0103 gestionat\u0103 obi\u0219nuit\u0103 de PostgreSQL sau MySQL pe resurse minime. C\u00e2nd instan\u021ba va primi mai mult\u0103 \u00eenc\u0103rcare, vom conecta replici suplimentare, pe care vom distribui o parte din sarcina de citire. Dac\u0103 nu sunt cereri \u0219i \u00eenc\u0103rcare, dezactiv\u0103m replicile. Prima instan\u021b\u0103 este master, iar celelalte sunt replici.<\/p>\n
Aceast\u0103 idee este implementat\u0103 \u00een baza numit\u0103 Aurora Serverless AWS. Principiul este simplu: cererile din aplica\u021bii externe sunt preluate de o flot\u0103 proxy. Observ\u00e2nd cre\u0219terea \u00eenc\u0103rc\u0103rii, acesta aloc\u0103 resurse de calcul din instan\u021bele minime pre\u00eenc\u0103lzite - conectarea se face c\u00e2t mai rapid posibil. Deconectarea instan\u021belor se realizeaz\u0103 la fel.<\/p>\n
\u00cen cadrul Aurora exist\u0103 conceptul de Aurora Capacity Unit, ACU. Acesta este (\u00een mod arbitrar) o instan\u021b\u0103 (server). Fiecare ACU specific poate fi master sau slave. Fiecare Capacity Unit dispune de propria memorie RAM, procesor \u0219i disc minim. Astfel, un master \u0219i celelalte replici sunt doar pentru citire.<\/p>\n
Num\u0103rul acestor Aurora Capacity Units active este un parametru configurabil. Num\u0103rul minim poate fi unul sau zero (\u00een acest caz baza nu func\u021bioneaz\u0103, dac\u0103 nu exist\u0103 cereri).<\/p>\n
Baza Aurora Serverless poate scala sarcina de citire. Dar \u00een documenta\u021bie nu se spune acest lucru \u00een mod direct. Poate ap\u0103rea senza\u021bia c\u0103 ar putea ridica multi-master. Totu\u0219i, nu este vorba de magie. <\/p>\n
Aceast\u0103 baz\u0103 este binevenit\u0103 pentru a nu cheltui o sum\u0103 uria\u0219\u0103 pe sisteme cu acces imprevizibil. De exemplu, atunci c\u00e2nd cre\u0103m un MVP sau site-uri de marketing, \u00een general nu ne a\u0219tept\u0103m la o sarcin\u0103 stabil\u0103. Astfel, \u00een cazul \u00een care nu exist\u0103 acces, nu pl\u0103tim pentru instan\u021be. C\u00e2nd apare brusc o \u00eenc\u0103rcare, cum ar fi dup\u0103 o conferin\u021b\u0103 sau o campanie publicitar\u0103, mul\u021bimi de oameni acceseaz\u0103 site-ul \u0219i sarcina cre\u0219te brusc, Aurora Serverless preia automat aceast\u0103 sarcin\u0103 \u0219i conecteaz\u0103 rapid resursele lips\u0103 (ACU). Apoi, dup\u0103 conferin\u021b\u0103, toat\u0103 lumea uit\u0103 de prototip, serverele (ACU) se opresc, iar cheltuielile scad la zero - convenabil.<\/p>\n
Aceast\u0103 solu\u021bie nu este potrivit\u0103 pentru un highload stabil, deoarece nu poate scala sarcina de scriere. Toate aceste conexiuni \u0219i deconect\u0103ri de resurse au loc \u00een momentul a\u0219a-numitului \u201escale point\u201d - momentul \u00een care baza nu este \u021binut\u0103 de o tranzac\u021bie, nu sunt tabele temporare. De exemplu, pe parcursul unei s\u0103pt\u0103m\u00e2ni, este posibil s\u0103 nu se produc\u0103 scale point, iar baza func\u021bioneaz\u0103 pe acelea\u0219i resurse \u0219i pur \u0219i simplu nu poate fi extins\u0103 sau restr\u00e2ns\u0103. <\/p>\n
Nu exist\u0103 magie - este doar un PostgreSQL obi\u0219nuit. Dar procesul de ad\u0103ugare a ma\u0219inilor \u0219i de deconectare este par\u021bial automatizat.<\/p>\n
Serverless by design<\/h2>\n \nAurora Serverless este o baz\u0103 veche, rescris\u0103 pentru cloud pentru a utiliza avantajele Serverless. Acum v\u0103 voi vorbi despre o baz\u0103 care a fost scris\u0103 din start pentru cloud, sub abordarea serverless - Serverless-by-design. A fost dezvoltat\u0103 f\u0103r\u0103 s\u0103 se presupun\u0103 c\u0103 func\u021bioneaz\u0103 pe servere fizice.<\/p>\n
Aceast\u0103 baz\u0103 se nume\u0219te Snowflake. Are trei blocuri cheie.<\/p>\n
Al doilea bloc - este format din numeroase clustere virtuale de calcul pentru calcule (\u00een ilustra\u021bie - un set de cercuri albastre).<\/p>\n
Al treilea bloc - este sistemul de stocare a datelor pe baza S3. S3 este un spa\u021biu de stocare de obiecte nelimitat \u00een AWS, ceva asem\u0103n\u0103tor unui Dropbox nelimitat pentru afaceri.<\/p>\n
S\u0103 vedem cum func\u021bioneaz\u0103 Snowflake, presupun\u00e2nd c\u0103 avem un start rece. Cu alte cuvinte, baza de date este prezent\u0103, datele sunt \u00eenc\u0103rcate \u00een aceasta, dar nu exist\u0103 interog\u0103ri active. Prin urmare, dac\u0103 nu sunt interog\u0103ri c\u0103tre baza de date, avem un serviciu rapid de Metadata \u00een memorie (primul bloc). \u0218i avem un stocare S3, unde sunt p\u0103strate datele din tabele, \u00eemp\u0103r\u021bite \u00een a\u0219a-numitele micro-parti\u021bii. Pentru simplificare: dac\u0103 \u00een tabel sunt tranzac\u021bii, micro-parti\u021biile sunt zilele tranzac\u021biilor. Fiecare zi este o micro-parti\u021bie separat\u0103, un fi\u0219ier separat. \u0218i atunci c\u00e2nd baza de date func\u021bioneaz\u0103 \u00een acest mod, pl\u0103ti\u021bi doar pentru spa\u021biul ocupat de date. De asemenea, tariful pentru spa\u021biu este foarte mic (mai ales av\u00e2nd \u00een vedere compresia semnificativ\u0103). Serviciul de metadata func\u021bioneaz\u0103 constant, dar pentru optimizarea interog\u0103rilor nu sunt necesare multe resurse, iar serviciul poate fi considerat condi\u021bionat gratuit. <\/p>\n
Acum s\u0103 ne imagin\u0103m c\u0103 un utilizator a venit la baza noastr\u0103 de date \u0219i a trimis o interogare SQL. Interogarea SQL este trimis\u0103 imediat c\u0103tre serviciul Metadata pentru procesare. A\u0219adar, primind interogarea, acest serviciu analizeaz\u0103 interogarea, datele disponibile, drepturile utilizatorului \u0219i, dac\u0103 totul este \u00een regul\u0103, elaboreaz\u0103 un plan pentru procesarea interog\u0103rii.<\/p>\n
Apoi, serviciul ini\u021biaz\u0103 lansarea unui cluster de calcul. Un cluster de calcul este un grup de servere care efectueaz\u0103 calcule. Cu alte cuvinte, este un cluster care poate con\u021bine 1 server, 2 servere, 4, 8, 16, 32 \u2014 c\u00e2te dori\u021bi. Trimite\u021bi interogarea \u0219i clusterul \u00eencepe s\u0103 se lanseze instantaneu pentru aceasta. Acest proces dureaz\u0103, de fapt, c\u00e2teva secunde.<\/p>\n
Fiecare interogare SQL poate nu doar s\u0103 calculeze agregate din datele deja \u00eenc\u0103rcate, ci \u0219i s\u0103 \u00eencarce\/formateze date noi \u00een baza de date. Asta \u00eenseamn\u0103 c\u0103 poate fi o interogare care, de exemplu, realizeaz\u0103 inser\u021bii de noi \u00eenregistr\u0103ri \u00eentr-un alt tabel, ceea ce duce la crearea unei noi parti\u021bii \u00een clusterul de calcul, care, la r\u00e2ndul s\u0103u, este salvat\u0103 automat \u00een depozitul S3 unic.<\/p>\n
Scenariul descris mai sus, de la sosirea utilizatorului p\u00e2n\u0103 la pornirea clusterului, \u00eenc\u0103rcarea datelor, executarea interog\u0103rilor, primirea rezultatelor, este tarifat pe baza minutei de utilizare a clusterului virtual de calcul ridicat, warehouse-ului virtual. Tariful variaz\u0103 \u00een func\u021bie de zona AWS \u0219i dimensiunea clusterului, dar, \u00een medie, cost\u0103 c\u00e2\u021biva dolari pe or\u0103. Un cluster format din patru ma\u0219ini cost\u0103 de dou\u0103 ori mai mult dec\u00e2t unul format din dou\u0103 ma\u0219ini, iar unul din opt ma\u0219ini cost\u0103 de \u00eenc\u0103 dou\u0103 ori mai mult. Sunt disponibile op\u021biuni de 16, 32 ma\u0219ini, \u00een func\u021bie de complexitatea interog\u0103rilor. Dar pl\u0103te\u0219ti doar pentru minutele \u00een care clusterul este cu adev\u0103rat activ, deoarece, atunci c\u00e2nd nu sunt interog\u0103ri, practic \u00eei dai drumul, iar dup\u0103 5-10 minute de a\u0219teptare (parametru configurabil) se va opri singur, eliber\u00e2nd resursele \u0219i devenind gratuit.<\/p>\n
Exist\u0103 un scenariu complet real \u00een care trimite\u021bi o solicitare, clusterul apare, s\u0103 zicem, \u00eentr-un minut, se g\u00e2nde\u0219te timp de \u00eenc\u0103 un minut, apoi cinci minute pentru a se opri, \u0219i \u00een final pl\u0103ti\u021bi pentru \u0219apte minute de func\u021bionare a acestui cluster, nu pentru luni \u0219i ani.<\/p>\n
Primul scenariu descria utilizarea Snowflake \u00eentr-o variant\u0103 pentru un singur utilizator. Acum s\u0103 ne imagin\u0103m c\u0103 sunt mul\u021bi utilizatori, ceea ce se apropie mai mult de un scenariu real.<\/p>\n
S\u0103 presupunem c\u0103 avem mul\u021bi anali\u0219ti \u0219i rapoarte Tableau care bombardeaz\u0103 constant baza noastr\u0103 cu un num\u0103r mare de interog\u0103ri SQL de analiz\u0103 simple.<\/p>\n
\u00cen plus, s\u0103 presupunem c\u0103 avem Data Scientists inventivi care \u00eencearc\u0103 s\u0103 fac\u0103 lucruri monstruoase cu datele, oper\u00e2nd cu zeci de terabytes, analiz\u00e2nd miliarde \u0219i trilioane de r\u00e2nduri de date. <\/p>\n
Pentru cele dou\u0103 tipuri de sarcini descrise mai sus, Snowflake permite ridicarea mai multor clustere de calcul independente de putere diferit\u0103. Aceste clustere de calcul func\u021bioneaz\u0103 independent, dar cu date comune consistente.<\/p>\n
Pentru un num\u0103r mare de interog\u0103ri u\u0219oare, se pot ridica 2-3 clustere mici, fiecare av\u00e2nd, s\u0103 zicem, 2 ma\u0219ini. Acest comportament poate fi realizat, de asemenea, prin set\u0103ri automate. Asta \u00eenseamn\u0103 c\u0103 spune\u021bi: \u201eSnowflake, ridic\u0103 un cluster mic. Dac\u0103 \u00eenc\u0103rcarea pe acesta dep\u0103\u0219e\u0219te un anumit parametru, ridic\u0103 un al doilea, al treilea similar. C\u00e2nd \u00eenc\u0103rcarea \u00eencepe s\u0103 scad\u0103, opre\u0219te cele \u00een plus.\u201d Astfel, indiferent de c\u00e2\u021bi anali\u0219ti vin \u0219i \u00eencep s\u0103 vizioneze rapoartele, toat\u0103 lumea are suficiente resurse.<\/p>\n
\u00cen acest context, dac\u0103 anali\u0219tii dorm \u0219i nimeni nu vizioneaz\u0103 rapoartele, clusterele se pot opri complet, iar dumneavoastr\u0103 nu mai pl\u0103ti\u021bi pentru ele.<\/p>\n
\u00cen plus, pentru interog\u0103rile complexe (de la Data Scientists), pute\u021bi ridica un singur cluster foarte mare cu 32 de ma\u0219ini, de exemplu. Acest cluster va fi de asemenea pl\u0103tit doar pentru minutele \u0219i orele \u00een care func\u021bioneaz\u0103 uria\u0219a dumneavoastr\u0103 interogare.<\/p>\n
Posibilitatea descris\u0103 mai sus permite separarea nu doar a dou\u0103, ci \u0219i a mai multor tipuri de sarcini prin clustere (ETL, monitorizare, materializare a rapoartelor,\u2026).<\/p>\n
S\u0103 rezum\u0103m Snowflake. Baza combin\u0103 o idee frumoas\u0103 cu o implementare func\u021bional\u0103. \u00cen ManyChat, folosim Snowflake pentru analiza tuturor datelor disponibile. Noi avem nu doar trei clustere, ca \u00een exemplu, ci \u00eentre 5 \u0219i 9, de dimensiuni diferite. Avem clustere de 16 ma\u0219ini, de 2 ma\u0219ini, dar \u0219i super-mici de 1 ma\u0219in\u0103 pentru anumite sarcini. Ele distribuie eficient sarcina \u0219i ne permit s\u0103 economisim considerabil.<\/p>\n
Baza scaleaz\u0103 cu succes sarcina de citire \u0219i scriere. Aceasta este o diferen\u021b\u0103 uria\u0219\u0103 \u0219i o mare progrese fa\u021b\u0103 de \u201eAurora\u201d, care gestiona doar sarcina de citire. Snowflake permite scalarea sarcinii de scriere prin aceste clustere de calcul. A\u0219a cum am men\u021bionat, \u00een ManyChat folosim mai multe clustere, iar clusterele mici \u0219i super-mici sunt folosite \u00een principal pentru ETL, pentru \u00eenc\u0103rcarea datelor. Iar anali\u0219tii lucreaz\u0103 pe clusterele medii, care nu sunt afectate de sarcina ETL, a\u0219a c\u0103 func\u021bioneaz\u0103 foarte rapid. <\/p>\n
Prin urmare, baza se preteaz\u0103 bine pentru sarcini OLAP. Din p\u0103cate, pentru sarcinile OLTP, aceasta nu este \u00eenc\u0103 aplicabil\u0103. \u00cen primul r\u00e2nd, aceasta este o baz\u0103 de date pe coloane, cu toate consecin\u021bele decurg\u0103toare. \u00cen al doilea r\u00e2nd, abordarea de a ridica un cluster de calcul pentru fiecare cerere \u0219i de a-l alimenta cu date, din p\u0103cate, nu este rapid\u0103 suficient pentru sarcinile OLTP. Secunde de a\u0219teptare pentru sarcinile OLAP sunt acceptabile, dar pentru OLTP sunt inacceptabile; ar trebui s\u0103 fie 100 ms, iar ideal 10 ms.<\/p>\n
Rezultatul<\/h2>\n \nO baz\u0103 de date f\u0103r\u0103 server este posibil\u0103 prin separarea acesteia \u00een p\u0103r\u021bi Stateless \u0219i Stateful. Probabil a\u021bi observat c\u0103 \u00een toate exemplele date, partea Stateful este, s\u0103 zicem, stocarea micro-parti\u021biilor \u00een S3, iar Stateless este optimizatorul, gestionarea metadatelor, tratarea problemelor de securitate, care pot fi ridicate ca servicii independente, u\u0219oare, Stateless.<\/p>\n
Executarea interog\u0103rilor SQL poate fi v\u0103zut\u0103 \u0219i ca servicii cu un stat u\u0219or, care pot ap\u0103rea \u00een modul f\u0103r\u0103 server, asemenea clustrelor de calcul Snowflake, desc\u0103rc\u00e2nd doar datele necesare, execut\u00e2nd interogarea \u0219i \u201esting\u00e2ndu-se\u201d.<\/p>\n
Bazele de date serverless de nivel de produc\u021bie sunt deja disponibile pentru utilizare, func\u021bioneaz\u0103. Aceste baze de date serverless sunt deja preg\u0103tite s\u0103 fac\u0103 fa\u021b\u0103 sarcinilor OLAP. Din p\u0103cate, pentru sarcinile OLTP sunt aplicate... cu nuan\u021be, deoarece exist\u0103 limit\u0103ri. Pe de o parte, acesta este un dezavantaj. Dar, pe de alt\u0103 parte, este o oportunitate. Poate c\u0103 cineva dintre cititori va g\u0103si o modalitate de a transforma o baz\u0103 de date OLTP \u00een una complet serverless, f\u0103r\u0103 limit\u0103ri Aurora.<\/p>\n
Sper c\u0103 v-a fost interesant. Spre viitorul Serverless \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