Lo storage temporaneo viene pulito, le risorse vengono liberate.<\/li>\n<\/ul>\nIn questa architettura paghiamo solo per il processo di esecuzione della query. Nessuna query \u2014 nessuna spesa.<\/p>\n
L'esempio di Athena dimostra che un database Serverless opera su richieste reali con decine e centinaia di terabyte di dati. Per centinaia di terabyte sono necessari centinaia di server, ma non dobbiamo pagarli \u2014 paghiamo solo per le richieste. La velocit\u00e0 di ogni richiesta \u00e8 (molto) bassa rispetto ai database analitici specializzati come Vertica, ma non paghiamo i tempi di inattivit\u00e0.<\/p>\n
Questo tipo di database \u00e8 applicabile per richieste analitiche ad-hoc rare. Ad esempio, quando decidiamo spontaneamente di testare un'ipotesi su un'enorme quantit\u00e0 di dati. Per questi casi, Athena \u00e8 perfetta. Per richieste regolari, questo sistema diventa costoso. In tal caso, memorizza i dati in una soluzione specializzata. <\/p>\n
Serverless per soluzioni OLTP<\/h2>\n \nNell'esempio precedente, abbiamo esaminato compiti OLAP (analitici). Ora consideriamo i compiti OLTP.<\/p>\n
Immaginiamo un'istanza PostgreSQL o MySQL scalabile. Creiamo un'istanza gestita di PostgreSQL o MySQL con risorse minime. Quando l'istanza riceve un carico maggiore, possiamo aggiungere repliche supplementari per distribuire parte del carico di lettura. Se non ci sono richieste o carico, disattiviamo le repliche. La prima istanza \u00e8 il master, mentre le altre sono repliche.<\/p>\n
Questa idea \u00e8 realizzata in un database chiamato Aurora Serverless AWS. Il principio \u00e8 semplice: le richieste da applicazioni esterne vengono gestite da un proxy fleet. Con l'aumento del carico, vengono allocate risorse di calcolo da istanze minime gi\u00e0 pronte \u2014 la connessione avviene nel modo pi\u00f9 rapido possibile. Anche la disattivazione delle istanze avviene allo stesso modo.<\/p>\n
All'interno di Aurora esiste il concetto di Aurora Capacity Unit, ACU. Questo \u00e8 (in termini generali) un'istanza (server). Ogni singolo ACU pu\u00f2 essere master o slave. Ogni Capacity Unit ha la propria memoria, processore e disco minimo. Di conseguenza, esiste un master, mentre le altre sono repliche in sola lettura.<\/p>\n
Il numero di Aurora Capacity Units attive \u00e8 un parametro configurabile. Il valore minimo pu\u00f2 essere uno o zero (in tal caso il database non \u00e8 operativo se non ci sono richieste).<\/p>\n
Il database Aurora Serverless pu\u00f2 scalare il carico di lettura. Tuttavia, questo non \u00e8 specificato chiaramente nella documentazione. Potrebbe sembrare che possano attivare il multi-master. Ma non ci sono magie. <\/p>\n
Questa base \u00e8 ideale per evitare di spendere grandi somme per sistemi con accesso imprevedibile. Ad esempio, nella creazione di MVP o siti web di marketing, di solito non ci aspettiamo un carico stabile. Pertanto, in assenza di accesso, non paghiamo per le istanze. Quando sorge un carico imprevisto, ad esempio dopo una conferenza o una campagna pubblicitaria, grandi gruppi di persone accedono al sito e il carico aumenta drasticamente; Aurora Serverless gestisce automaticamente questo carico e connette rapidamente le risorse necessarie (ACU). Poi, dopo la conferenza, tutti dimenticano il prototipo, i server (ACU) si spengono e i costi cadono a zero \u2014 molto comodo.<\/p>\n
Questa soluzione non \u00e8 adatta per carichi stabili e elevati, perch\u00e9 non \u00e8 in grado di scalare il carico di scrittura. Tutte queste connessioni e disconnessioni delle risorse avvengono nel momento chiamato 'scale point' \u2014 un momento in cui il database non \u00e8 bloccato da una transazione e non ha tabelle temporanee. Ad esempio, nel corso di una settimana potrebbe non verificarsi alcuno 'scale point', e il database funziona con le stesse risorse, non potendo n\u00e9 espandersi n\u00e9 ridursi. <\/p>\n
Non c'\u00e8 magia: si tratta di un normale PostgreSQL. Tuttavia, il processo di aggiunta di macchine e disattivazione \u00e8 parzialmente automatizzato.<\/p>\n
Serverless per design<\/h2>\n \nAurora Serverless \u00e8 un database vecchio adattato al cloud per sfruttare i vantaggi di Serverless. Ora, parler\u00f2 di un database progettato fin dall'inizio per il cloud e per un approccio serverless: Serverless-by-design. \u00c8 stato sviluppato sin dall'inizio senza l'assunzione di essere eseguito su server fisici.<\/p>\n
Questo database si chiama Snowflake. Esso \u00e8 composto da tre blocchi chiave.<\/p>\n
Il secondo blocco consiste in numerosi cluster di calcolo virtuali per le elaborazioni (nell'illustrazione \u2014 un insieme di cerchi blu).<\/p>\n
Il terzo blocco \u00e8 il sistema di archiviazione dei dati basato su S3. S3 \u00e8 uno spazio di archiviazione oggetti illimitato in AWS, simile a un Dropbox illimitato per il business.<\/p>\n
Vediamo come funziona Snowflake assumendo un avvio a freddo. Cio\u00e8, il database esiste, i dati sono stati caricati, ma non ci sono query attive. Di conseguenza, se non ci sono query, abbiamo un veloce servizio di Metadata in memoria (il primo blocco). E abbiamo uno storage S3 dove sono conservati i dati delle tabelle, suddivisi in quelle che chiamiamo micro-partizioni. Per semplicit\u00e0: se nella tabella ci sono transazioni, le micro-partizioni corrispondono ai giorni delle transazioni. Ogni giorno \u00e8 una micro-partizione separata, un file separato. E quando il database funziona in questo modo, paghi solo per lo spazio occupato dai dati. Inoltre, la tariffa per lo spazio \u00e8 molto bassa (soprattutto considerando la significativa compressione). Il servizio di metadati \u00e8 sempre attivo, ma per ottimizzare le query non richiede molte risorse, e possiamo considerarlo a costo zero. <\/p>\n
Immaginiamo ora che un utente si connetta al nostro database e invii una query SQL. La query SQL viene subito inviata al servizio di Metadata per l'elaborazione. Di conseguenza, ricevuta la query, questo servizio la analizza, insieme ai dati disponibili e alle autorizzazioni dell'utente, e, se tutto \u00e8 a posto, elabora un piano di esecuzione della query.<\/p>\n
Successivamente, il servizio avvia il lancio del cluster di calcolo. Un cluster di calcolo \u00e8 un insieme di server che esegue elaborazioni. Ci\u00f2 significa che pu\u00f2 includere 1 server, 2 server, 4, 8, 16, 32 \u2014 quanti ne desiderate. Inviate una richiesta e il lancio di questo cluster inizia immediatamente. Questo richiede davvero solo pochi secondi.<\/p>\n
Ogni richiesta SQL non solo pu\u00f2 calcolare aggregati dai dati precedentemente caricati, ma pu\u00f2 anche caricare\/formare nuovi dati nel database. In altre parole, pu\u00f2 trattarsi di una richiesta che, ad esempio, esegue un'inserimento in un'altra tabella di nuovi record, il che porta alla creazione di una nuova partizione nel cluster di calcolo, che a sua volta viene automaticamente salvata in un unico storage S3.<\/p>\n
Lo scenario descritto sopra, dalla connessione dell'utente fino all'attivazione del cluster, il caricamento dei dati, l'esecuzione delle query e la ricezione dei risultati, \u00e8 fatturato a una tariffa per minuti di utilizzo del cluster di calcolo virtuale attivato, virtual warehouse. La tariffa varia in base alla regione AWS e alle dimensioni del cluster, ma in media \u00e8 di alcuni dollari all'ora. Un cluster di quattro macchine costa il doppio rispetto a uno di due macchine, e uno di otto macchine costa ancora il doppio. Sono disponibili opzioni da 16 o 32 macchine, a seconda della complessit\u00e0 delle query. Ma paghi solo per i minuti in cui il cluster \u00e8 effettivamente attivo, perch\u00e9, quando non ci sono richieste, puoi semplicemente allontanarti e dopo 5-10 minuti di attesa (parametro configurabile) si spegner\u00e0 automaticamente, liberando risorse e diventando gratuito.<\/p>\n
\u00c8 assolutamente realistico che tu invii una richiesta, il cluster si attivi, per cos\u00ec dire, in un minuto, poi un minuto per eseguire i calcoli, successivamente cinque minuti per lo spegnimento, e alla fine paghi solo per sette minuti di funzionamento di questo cluster, non per mesi o anni.<\/p>\n
Il primo scenario descriveva l'uso di Snowflake in modalit\u00e0 singolo utente. Ora immaginiamo che ci siano molti utenti, che si avvicina di pi\u00f9 a uno scenario reale.<\/p>\n
Supponiamo di avere molti analisti e report di Tableau che bombardano costantemente il nostro database con un gran numero di semplici query SQL analitiche.<\/p>\n
In aggiunta, ipotizziamo di avere data scientist ingegnosi che cercano di fare cose incredibili con i dati, operando con decine di terabyte e analizzando miliardi e trilioni di righe di dati. <\/p>\n
Per i due tipi di carico descritti sopra, Snowflake consente di attivare pi\u00f9 cluster di calcolo indipendenti di diversa potenza. Questi cluster di calcolo funzionano in modo indipendente ma condividono dati coerenti.<\/p>\n
Per un numero elevato di richieste leggere, \u00e8 possibile attivare 2-3 piccoli cluster, ognuno composto da, diciamo, 2 macchine. Questo comportamento \u00e8 realizzabile anche attraverso impostazioni automatiche. In altre parole, si pu\u00f2 semplicemente dire: \u00abSnowflake, avvia un piccolo cluster. Se il carico supera un certo parametro, avvia un secondo e un terzo simili. Quando il carico inizia a diminuire, spegni quelli in pi\u00f9\u00bb. Cos\u00ec, indipendentemente dal numero di analisti che accedono e iniziano a consultare i report, ci saranno sempre risorse sufficienti.<\/p>\n
D'altra parte, se gli analisti sono inattivi e nessuno consulta i report, i cluster possono essere completamente spenti, e non si paga per loro.<\/p>\n
Per le richieste pesanti (da parte dei Data Scientists), \u00e8 possibile attivare un cluster molto grande con circa 32 macchine. Questo cluster sar\u00e0 addebitato solo per i minuti e le ore in cui il vostro grosso comando \u00e8 in esecuzione.<\/p>\n
La possibilit\u00e0 descritta sopra consente di separare i carichi in cluster non solo su 2, ma anche su pi\u00f9 tipi di carico (ETL, monitoraggio, materializzazione dei report,\u2026).<\/p>\n
Riassumiamo riguardo a Snowflake. La piattaforma combina un'idea accattivante con un'implementazione funzionale. In ManyChat utilizziamo Snowflake per analizzare tutti i dati disponibili. Non abbiamo tre cluster come nell'esempio, ma tra 5 e 9, di diverse dimensioni. Abbiamo cluster convenzionali da 16 macchine, cluster da 2 macchine e anche super piccoli cluster da 1 macchina per alcune attivit\u00e0. Questi gestiscono efficacemente il carico e ci permettono di risparmiare significativamente.<\/p>\n
La piattaforma scalda con successo il carico di lettura e scrittura. Questa \u00e8 una grande differenza e una grande innovazione rispetto a \"Aurora\", che gestiva solo il carico di lettura. Snowflake consente di scalare anche il carico di scrittura con questi cluster computazionali. Come ho accennato, in ManyChat utilizziamo diversi cluster; i cluster piccoli e super piccoli sono principalmente utilizzati per ETL, per il caricamento dei dati. Gli analisti operano su cluster medi, che non sono affatto influenzati dal carico ETL, quindi lavorano molto velocemente. <\/p>\n
Pertanto, il database \u00e8 ben adatto per compiti OLAP. Tuttavia, sfortunatamente, non \u00e8 ancora applicabile ai carichi di lavoro OLTP. Innanzitutto, questo database \u00e8 colonnare, con tutte le conseguenze del caso. In secondo luogo, l'approccio stesso, in cui si attiva un cluster computazionale per ogni richiesta e si riversano i dati, purtroppo, non \u00e8 ancora sufficientemente veloce per carichi di lavoro OLTP. Attendere alcuni secondi per compiti OLAP \u00e8 normale, ma inaccettabile per OLTP; sarebbe meglio avere 100 ms, e ancor meglio \u2014 10 ms.<\/p>\n
Risultato<\/h2>\n \nUn database serverless \u00e8 possibile grazie alla separazione del database in parti Stateless e Stateful. Avrete notato che, in tutti gli esempi forniti, la parte Stateful \u00e8, per cos\u00ec dire, la memorizzazione delle micro-partizioni in S3, mentre Stateless riguarda l'ottimizzatore, la gestione dei metadati, il trattamento delle questioni di sicurezza, che possono essere attivate come servizi Stateless leggeri e indipendenti.<\/p>\n
L'esecuzione di query SQL pu\u00f2 essere vista anch'essa come servizi con uno stato leggero, che possono attivarsi in modalit\u00e0 serverless, come i cluster computazionali di Snowflake, scaricando solo i dati necessari, eseguendo la query e 'spegnendosi'.<\/p>\n
Le banche dati serverless di livello enterprise sono ora disponibili per l'uso e funzionano. Queste banche serverless sono gi\u00e0 pronte a gestire compiti OLAP. Purtroppo, per i compiti OLTP, vengono utilizzate\u2026 con delle problematiche, poich\u00e9 ci sono delle limitazioni. Da un lato, \u00e8 un aspetto negativo. Dall'altro, \u00e8 un'opportunit\u00e0. Forse qualcuno dei lettori trover\u00e0 un modo per rendere una banca dati OLTP completamente serverless, senza limitazioni Aurora.<\/p>\n
Spero che sia stato interessante. Per un futuro 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