Il database temporaneo viene svuotato e le risorse vengono liberate.<\/li>\n<\/ul>\nIn questa architettura paghiamo solo per il processo di esecuzione della richiesta. Nessuna richiesta \u2014 nessun costo.<\/p>\n
Dall'esempio di Athena, \u00e8 evidente che il database Serverless funziona con richieste reali di decine e centinaia di terabyte di dati. Per centinaia di terabyte saranno necessari centinaia di server, ma non dobbiamo pagare per loro \u2014 paghiamo per le richieste. La velocit\u00e0 di ogni richiesta \u00e8 (molto) bassa rispetto ai database analitici specializzati come Vertica, ma non paghiamo i periodi di inattivit\u00e0.<\/p>\n
Tale database \u00e8 applicabile per richieste analitiche ad-hoc rare. Ad esempio, quando decidiamo spontaneamente di verificare un'ipotesi su un gigantesco volume di dati. Per questi casi, Athena \u00e8 perfetta. Per le richieste regolari, questo sistema diventa costoso. In tal caso, \u00e8 consigliabile memorizzare i dati in una soluzione specializzata. <\/p>\n
Serverless per soluzioni OLTP<\/h2>\n \nNel precedente esempio sono stati trattati compiti OLAP (analitici). Ora esaminiamo compiti OLTP.<\/p>\n
Immaginiamo un PostgreSQL o un MySQL scalabile. Creiamo un'istanza gestita di PostgreSQL o MySQL con risorse minime. Quando l'istanza subir\u00e0 un carico maggiore, collegheremo repliche aggiuntive su cui distribuiamo parte del carico di lettura. Se non ci sono richieste e carico \u2014 disconnettiamo 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: il proxy fleet accoglie le richieste delle applicazioni esterne. Vedendo un aumento del carico, assegna risorse computazionali da istanze minime precedentemente attivate \u2014 la connessione avviene il pi\u00f9 rapidamente possibile. Anche la disconnessione delle istanze avviene in modo simile.<\/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 operativa, processore e disco minimi. Di conseguenza, un master e le altre repliche sono solo in lettura.<\/p>\n
Il numero di Aurora Capacity Units attivi \u00e8 un parametro configurabile. Il numero minimo pu\u00f2 essere uno o zero (in tal caso, il database non funziona se non ci sono richieste).<\/p>\n
Il database Aurora Serverless pu\u00f2 scalare il carico di lettura. Ma nella documentazione non viene detto esplicitamente. Potrebbe sorgere l'impressione che possano attivare un multi-master. Non c'\u00e8 alcun trucco. <\/p>\n
Questo database \u00e8 molto adatto per non spendere enormi 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 si verifica improvvisamente un carico, ad esempio dopo una conferenza o una campagna pubblicitaria, le folle di persone accedono al sito e il carico aumenta drasticamente, Aurora Serverless accetta automaticamente questo carico e collega rapidamente le risorse mancanti (ACU). Successivamente, la conferenza termina, tutti dimenticano il prototipo, i server (ACU) si spengono e le spese scendono a zero \u2014 comodo.<\/p>\n
Questa soluzione non \u00e8 adatta per carichi di lavoro stabili e elevati, perch\u00e9 non \u00e8 in grado di scalare il carico di scrittura. Tutti questi collegamenti e disconnessioni delle risorse avvengono nel momento noto come 'scale point' \u2014 il momento in cui il database non \u00e8 mantenuto da una transazione, n\u00e9 da tabelle temporanee. Ad esempio, nel corso della settimana, lo scale point potrebbe non verificarsi affatto, e il database lavora con risorse fisse e semplicemente non pu\u00f2 n\u00e9 espandersi n\u00e9 contrarsi. <\/p>\n
Non c'\u00e8 magia \u2014 \u00e8 un normale PostgreSQL. Ma il processo di aggiunta e disconnessione delle macchine \u00e8 parzialmente automatizzato.<\/p>\n
Serverless by design<\/h2>\n \nAurora Serverless \u00e8 un vecchio database riscritto per il cloud, per sfruttare i singoli vantaggi del Serverless. E ora parler\u00f2 di un database che \u00e8 stato inizialmente scritto per il cloud, secondo l'approccio serverless \u2014 Serverless-by-design. \u00c8 stato subito sviluppato senza presupporre che funzionasse su server fisici.<\/p>\n
Questo database si chiama Snowflake. Esso comprende tre blocchi chiave.<\/p>\n
Il secondo blocco \u00e8 composto da numerosi cluster computazionali virtuali per i calcoli (nell'illustrazione \u2014 un insieme di cerchi blu).<\/p>\n
Il terzo blocco \u00e8 un sistema di archiviazione dati basato su S3. S3 \u00e8 uno spazio di archiviazione oggetti illimitato in AWS, simile a un Dropbox illimitato per le aziende.<\/p>\n
Vediamo come funziona Snowflake, ipotizzando un avvio a freddo. Cio\u00e8, il database esiste, i dati sono stati caricati, ma non ci sono query in corso. Di conseguenza, se non ci sono query sul database, abbiamo un servizio Metadata in-memory rapido attivo (il primo blocco). E abbiamo uno storage S3 dove si trovano i dati delle tabelle, suddivisi in cosiddette micro-partizioni. Per semplificare: se nella tabella ci sono affari, le micro-partizioni corrispondono ai giorni degli affari. 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). Anche il servizio di metadati funziona costantemente, ma per ottimizzare le query non servono molte risorse, quindi si pu\u00f2 considerare un servizio condizionatamente gratuito. <\/p>\n
Immaginiamo ora che un utente abbia effettuato una richiesta SQL al nostro database. La richiesta SQL viene immediatamente inviata per l'elaborazione al servizio Metadata. Di conseguenza, ricevuta la richiesta, questo servizio analizza la richiesta, i dati disponibili, i diritti dell'utente e, se tutto \u00e8 in ordine, elabora un piano di esecuzione per la query.<\/p>\n
Successivamente, il servizio avvia un cluster di calcolo. Un cluster di calcolo \u00e8 un insieme di server che eseguono calcoli. Cio\u00e8, questo cluster pu\u00f2 contenere 1 server, 2 server, 4, 8, 16, 32 \u2014 quanti ne vuoi. Invi un'query e questo cluster inizia a essere avviato istantaneamente. Ci\u00f2 richiede realmente pochi secondi.<\/p>\n
Ogni query SQL pu\u00f2 non solo calcolare aggregati dai dati precedentemente caricati, ma anche caricare\/formare nuovi dati nel database. Ad esempio, pu\u00f2 trattarsi di una query che esegue l'inserimento di nuovi record in un'altra tabella, il che porta alla creazione di una nuova partizione nel cluster di calcolo, che viene automaticamente salvata nell'archivio S3 unico.<\/p>\n
Lo scenario descritto sopra, dall'arrivo dell'utente fino all'avvio del cluster, al caricamento dei dati, all'esecuzione delle query e all'ottenimento dei risultati, viene fatturato a una tariffa in base ai minuti di utilizzo del cluster di calcolo virtuale attivato, il warehouse virtuale. La tariffa varia a seconda della zona AWS e delle 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, 32 macchine, a seconda della complessit\u00e0 delle query. Ma paghi solo per i minuti in cui il cluster \u00e8 realmente attivo, perch\u00e9 quando non ci sono query, puoi semplicemente rilassarti e, dopo 5-10 minuti di attesa (un parametro configurabile), si spegner\u00e0 da solo, liberer\u00e0 risorse e diventer\u00e0 gratuito.<\/p>\n
\u00c8 assolutamente realistico uno scenario in cui inviate una richiesta, il cluster si attiva, per cos\u00ec dire, dopo un minuto, impiega un altro minuto per calcolare, poi cinque minuti per spegnersi, e alla fine pagate per sette minuti di lavoro di questo cluster, e non per mesi o anni.<\/p>\n
Il primo scenario descriveva l'uso di Snowflake in modalit\u00e0 monoutente. Ora immaginiamo che ci siano molti utenti, che \u00e8 gi\u00e0 pi\u00f9 vicino a uno scenario reale.<\/p>\n
Supponiamo di avere molti analisti e report di Tableau che bombardano continuamente il nostro database con un grande numero di semplici query SQL analitiche.<\/p>\n
Oltre a ci\u00f2, supponiamo che abbiamo data scientist ingegnosi che cercano di fare cose stravaganti con i dati, operando su decine di terabyte, analizzando miliardi e trilioni di righe di dati. <\/p>\n
Per i due tipi di carico descritti sopra, Snowflake consente di attivare diversi cluster di calcolo indipendenti di varie potenze. Questi cluster di calcolo operano in modo indipendente, ma con dati coerenti condivisi.<\/p>\n
Per un gran numero di richieste leggere, \u00e8 possibile attivare 2-3 piccoli cluster, ciascuno di dimensioni, per cos\u00ec dire, 2 macchine. Questo comportamento \u00e8 realizzabile anche tramite impostazioni automatiche. Cio\u00e8, dici: \"Snowflake, attiva un piccolo cluster. Se il carico su di esso supera un certo parametro, attiva un secondo e un terzo simile. Quando il carico inizia a diminuire, spegni i cluster superflui.\" In questo modo, indipendentemente da quanti analisti arrivano e iniziano a visualizzare i report, ci sono sempre risorse sufficienti.<\/p>\n
Tuttavia, se gli analisti dormono e non si visualizzano report, i cluster possono spegnersi completamente, e smettete di pagare per essi.<\/p>\n
Inoltre, per le richieste pesanti (da parte dei data scientist), potete attivare un cluster molto grande di circa 32 macchine. Anche questo cluster sar\u00e0 pagato solo per i minuti e le ore in cui il vostro gigante sta eseguendo una query.<\/p>\n
La possibilit\u00e0 descritta sopra consente di suddividere i carichi non solo in 2, ma anche in pi\u00f9 tipi di carico (ETL, monitoraggio, materializzazione dei report,\u2026).<\/p>\n
Faremo un riepilogo su Snowflake. La base combina un'idea elegante e una realizzazione funzionale. In ManyChat utilizziamo Snowflake per analizzare tutti i dati disponibili. I nostri cluster non sono tre, come nell'esempio, ma da 5 a 9, di varie dimensioni. Abbiamo cluster convenzionali di 16 macchine, cluster di 2 macchine, e anche piccolissimi cluster di 1 macchina per alcune attivit\u00e0. Questi distribuiscono efficacemente il carico e ci permettono di risparmiare significativamente.<\/p>\n
La base scala efficacemente il carico di lettura e scrittura. Questa \u00e8 una differenza enorme e un grande progresso rispetto alla 'Aurora', che gestiva solo il carico di lettura. Snowflake consente di scalare anche il carico di scrittura con questi cluster computazionali. Come ho gi\u00e0 accennato, in ManyChat utilizziamo diversi cluster, i cluster pi\u00f9 piccoli e super piccoli sono principalmente impiegati per l'ETL, per il caricamento dei dati. Gli analisti operano su cluster medi, che non sono affatto influenzati dal carico dell'ETL, quindi funzionano molto rapidamente. <\/p>\n
Di conseguenza, la base \u00e8 ben adatta per le attivit\u00e0 OLAP. Tuttavia, sfortunatamente, non \u00e8 ancora adatta per i carichi OLTP. In primo luogo, questa base \u00e8 a colonne, con tutte le conseguenze del caso. In secondo luogo, l'approccio stesso, in cui per ogni richiesta si solleva un cluster computazionale e lo si alimenta di dati, purtroppo non \u00e8 ancora sufficientemente veloce per i carichi OLTP. Secondi di attesa per attivit\u00e0 OLAP sono accettabili, mentre per le attivit\u00e0 OLTP sono inaccettabili; sarebbe meglio 100 ms, e ancora meglio 10 ms.<\/p>\n
Risultato<\/h2>\n \nLe basi database senza server sono possibili grazie alla separazione della base in parti Stateless e Stateful. Avrete notato che in tutti gli esempi forniti, la parte Stateful \u00e8, per cos\u00ec dire, lo storage delle micro-partizioni in S3, mentre la parte Stateless \u00e8 l'ottimizzatore, il lavoro con i meta-dati, e la gestione delle questioni di sicurezza, che possono essere sollevate come servizi leggeri Stateless indipendenti.<\/p>\n
L'esecuzione delle query SQL pu\u00f2 essere considerata anch'essa come servizi con uno stato leggero, che possono apparire in modalit\u00e0 senza server, come i cluster computazionali di Snowflake, scaricare solo i dati necessari, eseguire la query e \"spegnersi\".<\/p>\n
Le basi serverless di livello produttivo sono gi\u00e0 disponibili per l'uso, e funzionano. Queste basi serverless sono gi\u00e0 pronte ad affrontare compiti OLAP. Sfortunatamente, per i compiti OLTP sono utilizzate... con delle sfide, poich\u00e9 ci sono delle limitazioni. Da un lato, questo \u00e8 un problema. Ma, dall'altro lato, \u00e8 un'opportunit\u00e0. Forse qualche lettore trover\u00e0 un modo per rendere completamente serverless una base OLTP, senza limitazioni di Aurora.<\/p>\n
Spero che vi sia piaciuto. Verso 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