Ciao, Habrovčani. Tradizionalmente continuiamo a condividere contenuti interessanti in vista dell'inizio di nuovi corsi. Oggi, appositamente per voi, abbiamo tradotto un articolo su Google Cloud Spanner, collegandolo al lancio del corso .
Inizialmente pubblicato su .
Come azienda che offre molteplici soluzioni POS cloud per rivenditori, ristoratori e venditori online in tutto il mondo, Lightspeed utilizza diversi tipi di piattaforme di database per molteplici casi d'uso transazionali, analitici e di ricerca. Ognuna di queste piattaforme database ha i propri punti di forza e di debolezza. Di conseguenza, quando Google ha presentato sul mercato Cloud Spanner, con funzionalità promettenti mai viste prima nel mondo dei database relazionali, come la scalabilità orizzontale praticamente illimitata e un accordo sul livello di servizio (SLA) del 99,999%, non potevamo lasciarci sfuggire l'opportunità di averlo tra le mani!
Per fornire una panoramica completa della nostra esperienza con Cloud Spanner e dei criteri di valutazione che abbiamo utilizzato, tratteremo i seguenti argomenti:
- I nostri criteri di valutazione
- Cloud Spanner in breve
- La nostra valutazione
- Le nostre conclusioni
1. I nostri criteri di valutazione
Prima di addentrarci nelle caratteristiche di Cloud Spanner, nelle sue somiglianze e differenze rispetto ad altre soluzioni sul mercato, parliamo prima dei principali casi d'uso che abbiamo considerato quando ci siamo posti la domanda su dove implementare Cloud Spanner nella nostra infrastruttura:
- Come alternativa a (prevalentemente) una tradizionale soluzione di database SQL
- Come soluzione OLTP con supporto OLAP
Nota: Per semplicità e comodità di confronto, questo articolo confronta Cloud Spanner con MySQL nel contesto delle soluzioni GCP Cloud SQL e Amazon AWS RDS.
Utilizzo di Cloud Spanner come alternativa a una tradizionale soluzione di database SQL
In un ambiente di database tradizionali, quando il tempo di risposta delle query al database si avvicina o supera i valori soglia predefiniti dall'applicazione (principalmente a causa dell'aumento del numero di utenti e/o delle richieste), ci sono diversi modi per ridurre il tempo di risposta a livelli accettabili. Tuttavia, la maggior parte di queste soluzioni richiede un intervento manuale.
Ad esempio, il primo passo da compiere è esaminare i diversi parametri del database relativi alle prestazioni e configurarli in modo che corrispondano al meglio ai modelli di utilizzo delle applicazioni. Se ciò non fosse sufficiente, si può optare per il scaling verticale o orizzontale del database.
Il scaling verticale di un'applicazione comporta l'upgrade dell'istanza del server, di solito aggiungendo un numero maggiore di processori/core, una maggiore quantità di memoria RAM, uno storage più veloce, ecc. L'aggiunta di maggiori risorse hardware porta a un incremento delle prestazioni del database, misurato principalmente in transazioni al secondo e latenza delle transazioni per i sistemi OLTP. I sistemi di database relazionali (che utilizzano un approccio multithread), come MySQL, scalano bene verticalmente.
Questo approccio ha alcuni svantaggi, ma il più ovvio è la dimensione massima del server disponibile sul mercato. Una volta raggiunto il limite dell'istanza del server più grande, l'unica strada rimanente è lo scaling orizzontale.
Lo scaling orizzontale è un approccio in cui vengono aggiunti server al cluster per aumentare idealmente le prestazioni in modo lineare con l'aggiunta di nuovi server. La maggior parte di database dei sistemi di database scalano male orizzontalmente o non scalano affatto. Ad esempio, MySQL può scalare orizzontalmente per le operazioni di lettura aggiungendo lettori slave, ma non può scalare orizzontalmente per le operazioni di scrittura.
D'altro canto, grazie alla sua natura, Cloud Spanner può scalare facilmente orizzontalmente con un intervento minimo.
Database a servizio deve essere valutato da diverse angolazioni. Come base, abbiamo preso il database nel cloud più popolare: per Google, GCP Cloud SQL e per Amazon, AWS RDS. Nella nostra valutazione ci siamo concentrati sulle seguenti categorie: Confronto delle funzionalità: estensione di SQL, DDL, DML; librerie di connessione/connector, supporto per le transazioni e così via.
- Supporto per lo sviluppo: semplicità di sviluppo e test.
- Поддержка разработки: простота разработки и тестирования.
- Supporto all'amministrazione: gestione delle istanze – ad esempio, scaling up/down e aggiornamento delle istanze; SLA, backup e ripristino; sicurezza/accesso controllato.
Utilizzo di Cloud Spanner come soluzione OLTP con supporto OLAP
Sebbene Google non affermi esplicitamente che Cloud Spanner sia progettato per l'elaborazione analitica, condivide alcune caratteristiche con altri meccanismi, come Apache Impala & Kudu e YugaByte, progettati per carichi di lavoro OLAP.
Anche se ci fosse solo una piccola possibilità che Cloud Spanner includesse un motore HTAP (elaborazione ibrida transazionale/analitica) scalabile orizzontalmente con un set di funzioni OLAP (più o meno) utilizzabile, riteniamo che sarebbe degno della nostra attenzione.
Tenendo conto di ciò, abbiamo considerato le seguenti categorie:
- Caricamento dati, indici e supporto per partizionamento
- Prestazioni delle query e DML
2. Cloud Spanner in poche parole
Google Spanner è un sistema di gestione di database relazionali (RDBMS) a cluster che Google utilizza per diversi propri servizi. Google l'ha reso accessibile al pubblico per gli utenti della Google Cloud Platform all'inizio del 2017.
Ecco alcune delle caratteristiche di Cloud Spanner:
- Cluster RDBMS altamente coerente e scalabile: utilizza la sincronizzazione hardware del tempo per garantire la coerenza dei dati.
- Supporto per transazioni cross-tabella: le transazioni possono coprire più tabelle - non sono necessariamente limitate a una sola tabella (a differenza di Apache HBase o Apache Kudu).
- Tabelle basate su chiavi primarie: tutte le tabelle devono avere una chiave primaria (PK) dichiarata, che può consistere in più colonne della tabella. I dati della tabella sono archiviati in ordine PK, rendendoli molto efficienti e veloci da cercare per PK. Come altri sistemi basati su PK, l'implementazione deve essere modellata con attenzione considerando casi d'uso predefiniti per raggiungere .
- Tabelle alternative: le tabelle possono avere dipendenze fisiche tra di loro. Le righe della tabella secondaria possono essere abbinate alle righe della tabella principale. Questo approccio accelera la ricerca delle relazioni che possono essere definite nella fase di modellazione dei dati, ad esempio, nella co-locazione di clienti e delle loro fatture.
- Indici: Cloud Spanner supporta indici secondari. Un indice è composto da colonne indicizzate e da tutte le colonne della chiave primaria. Se lo desidera, l'indice può contenere anche altre colonne non indicizzate. L'indice può alternarsi alla tabella principale per accelerare le query. Su di esso si applicano vari vincoli, come il numero massimo di colonne aggiuntive memorizzate nell'indice. Anche le query tramite indici possono non essere così dirette come in altri RDBMS.
«Cloud Spanner sceglie automaticamente l'indice solo in rari casi. In particolare, Cloud Spanner non seleziona automaticamente un indice secondario se la query richiede colonne non memorizzate in ».
- Accordo sul livello di servizio (SLA): distribuzione in una sola regione con SLA del 99,99%; distribuzioni multiregionali con SLA del 99,999%. Anche se l'accordo sul livello di servizio è solo un accordo e non una garanzia, credo che i dipendenti di Google abbiano dati precisi per fare un'affermazione così seria. (Per riferimento, 99,999% significa 26,3 secondi di inattività del servizio al mese).
- Di più:
Nota: Il progetto Apache Tephra aggiunge supporto avanzato per le transazioni in Apache HBase (ora implementato anche in Apache Phoenix come beta).
3. La nostra valutazione
Quindi, abbiamo letto le dichiarazioni di Google sui vantaggi di Cloud Spanner: quasi illimitata scalabilità orizzontale mantenendo alta coerenza e un SLA molto elevato. Sebbene questi requisiti siano estremamente difficili da raggiungere, il nostro obiettivo non era quello di smentirli. Invece, concentriamoci su altre cose che preoccupano la maggior parte degli utenti di database: la praticità e la facilità d'uso.
Abbiamo valutato Cloud Spanner come sostituto di Sharded MySQL.
Google Cloud SQL e Amazon AWS RDS, due tra i sistemi di gestione di database relazionali (OLTP) più popolari nel mercato del cloud, offrono un ampio set di funzionalità. Tuttavia, per scalare questi database oltre le dimensioni di un singolo nodo, è necessario eseguire la partizione delle applicazioni. Questo approccio crea ulteriore complessità sia per le applicazioni che per l'amministrazione. Abbiamo esaminato come Spanner si integra nello scenario di unione di più segmenti in un'unica istanza e quali funzionalità (se ci sono) potrebbero dover essere sacrificati.
Supporto SQL, DML e DDL, oltre a connettore e librerie?
In primo luogo, quando si inizia con qualsiasi database, è necessario creare un modello di dati. Se pensi di poter collegare JDBC Spanner al tuo strumento SQL preferito, scoprirai che puoi interrogare i tuoi dati usando questo, ma non puoi utilizzarlo per creare tabelle o effettuare modifiche (DDL) o operazioni di inserimento/aggiornamento/cancellazione (DML). Il JDBC ufficiale di Google non supporta né l'uno né l'altro.
«Attualmente i driver non supportano le operazioni DML o DDL».
Documentazione Spanner
Con la console GCP la situazione non è migliore: puoi inviare solo interrogazioni SELECT. Fortunatamente, esiste un driver JDBC supportato dalla comunità che include DML e DDL, comprese le transazioni. . Sebbene questo driver sia estremamente utile, sorprende l'assenza di un driver JDBC ufficiale da parte di Google. Fortunatamente, Google offre un'ampia supporto per librerie client (basate su gRPC): C#, Go, Java, node.js, PHP, Python e Ruby.
L'uso quasi obbligatorio di API personalizzate di Cloud Spanner (a causa della mancanza di DDL e DML in JDBC) porta a alcune limitazioni per le aree correlate del codice, come pool di connessione o framework di binding del database (ad es., Spring MVC). In generale, con JDBC puoi scegliere liberamente il tuo pool di connessione preferito (ad es., HikariCP, DBCP, C3PO, ecc.) che è stato testato e funziona bene. Nel caso delle API personalizzate di Spanner, dobbiamo fare affidamento sui framework/pool di binding/sessioni che abbiamo creato noi stessi.
La struttura orientata alla chiave primaria (PK) consente a Cloud Spanner di essere molto veloce nell'accesso ai dati tramite PK, ma porta anche a alcuni problemi con le interrogazioni.
- Non puoi aggiornare il valore della chiave primaria; devi prima rimuovere la registrazione con la PK originale e reinserirla con il nuovo valore. (Questo è simile ad altre basi di dati / meccanismi di archiviazione orientati alla PK.)
- Qualsiasi operatore UPDATE e DELETE deve specificare la PK nella clausola WHERE, pertanto non possono esserci operatori DELETE all'istante — deve sempre esserci una sottoquery, ad esempio: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Mancanza di un'opzione di auto-incremento o simili, che definisce la sequenza per il campo PK. Affinché questo funzioni, il valore corrispondente deve essere creato dal lato dell'applicazione.
Indici secondari?
Google Cloud Spanner ha un supporto integrato per indici secondari. Questa è una caratteristica molto interessante, che non sempre è presente in altre tecnologie. Apache Kudu attualmente non supporta affatto indici secondari, mentre Apache HBase non supporta indici direttamente, ma può aggiungerli tramite Apache Phoenix.
Gli indici in Kudu e HBase possono essere modellati come una tabella separata con un diverso insieme di chiavi primarie, ma l'atomicità delle operazioni eseguite con la tabella padre e le relative tabelle indice deve essere gestita a livello di applicazione e non è banale in una corretta implementazione.
Come accennato nella panoramica di Cloud Spanner, i suoi indici possono differire dagli indici MySQL. Pertanto, è opportuno fare particolare attenzione nella costruzione delle query e nel profiling, per garantire l'utilizzo dell'indice appropriato dove necessario.
Vista?
Un oggetto molto popolare e utile nel database è la vista. Possono essere utili per un gran numero di casi d'uso; i miei due preferiti sono il livello di astrazione logica e il livello di sicurezza. Sfortunatamente, Cloud Spanner NON supporta le viste. Tuttavia, questo limita solo parzialmente, poiché non c'è granularità in termini di colonne per le autorizzazioni di accesso, dove le viste possono essere una soluzione accettabile.
Nella documentazione di Cloud Spanner, nella sezione in cui vengono descritti in dettaglio le quote e le limitazioni (), ci sono, in particolare, alcune che possono essere problematiche per alcune applicazioni: Cloud Spanner ha un limite massimo di 100 database per istanza di default. È chiaro che questo può rappresentare un serio ostacolo per un database pensato per scalare oltre i 100 database. Fortunatamente, dopo aver parlato con il nostro rappresentante tecnico di Google, abbiamo scoperto che questo limite può essere aumentato praticamente a qualsiasi valore tramite il supporto di Google.
Supporto allo sviluppo?
Cloud Spanner offre un supporto abbastanza compatibile per i linguaggi di programmazione con la sua API. Le librerie ufficialmente supportate includono C#, Go, Java, node.js, PHP, Python e Ruby. La documentazione è abbastanza dettagliata, ma, come nel caso di altre tecnologie avanzate, la comunità è relativamente piccola rispetto alle tecnologie di database più popolari, il che può comportare un aumento del tempo necessario per risolvere casi d'uso o problemi meno comuni.
Quindi, che dire del supporto per lo sviluppo locale?
Non abbiamo trovato un modo per creare un'istanza di Cloud Spanner in un ambiente locale. La cosa più vicina che abbiamo ottenuto è un'immagine Docker , che in teoria è simile, ma nella pratica è molto diversa. Ad esempio, CockroachDB può utilizzare PostgreSQL JDBC. Poiché l'ambiente di sviluppo deve essere il più vicino possibile all'ambiente di produzione, Cloud Spanner non è ideale, poiché è necessario fare affidamento su un'istanza Spanner completa. Per risparmiare costi, puoi scegliere un'istanza per una sola regione.
Supporto per l'amministrazione?
Creare un'istanza di Cloud Spanner è molto semplice. Devi solo scegliere tra la creazione di un'istanza multiregionale o di un'istanza per una sola regione, specificare la regione(e) e il numero di nodi. In meno di un minuto, l'istanza sarà attiva e pronta per l'uso.
Diverse metriche di base sono direttamente disponibili nella pagina Spanner della console di Google. Visualizzazioni più dettagliate sono disponibili tramite Stackdriver, dove puoi anche impostare soglie per le metriche e politiche di avviso.
Accesso alle risorse?
MySQL offre impostazioni di autorizzazione/ruoli utente ampie e molto dettagliate. È facile configurare l'accesso a una specifica tabella o anche a solo un sottoinsieme delle sue colonne. Cloud Spanner utilizza lo strumento Google Identity & Access Management (IAM), che consente di stabilire politiche e autorizzazioni solo a un livello molto elevato. L'opzione più dettagliata è l'autorizzazione a livello di database, che non si adatta alla maggior parte degli scenari di produzione. Questa limitazione ti costringe ad aggiungere ulteriori misure di sicurezza nel tuo codice, infrastruttura, o entrambi, per prevenire l'uso non autorizzato delle risorse Spanner.
Backup?
Parlando in modo semplice, non ci sono backup in Cloud Spanner. Anche se le elevate richieste del Google SLA possono garantire che tu non perda dati a causa di guasti hardware o del database, da errori umani, difetti delle applicazioni, ecc. Conosciamo tutti la regola: l'alta disponibilità non sostituisce una ragionevole strategia di backup. Al momento, l'unico modo per eseguire il backup dei dati è trasmetterli in streaming dal database a un ambiente di archiviazione separato.
Prestazioni delle query?
Per il caricamento dei dati e il test delle query abbiamo utilizzato Yahoo! Cloud Serving Benchmark. Nella tabella seguente è riportato il carico di lavoro B YCSB con un rapporto di lettura del 95% e scrittura del 5%.
* Il test di carico è stato eseguito su un motore di calcolo (CE) n1-standard-32 (32 vCPU, 120 GB di memoria), e l'istanza di test non è mai stata un collo di bottiglia nei test.
** Il numero massimo di thread in un'istanza YCSB è di 400. Era necessario eseguire sei istanze parallele di test YCSB per ottenere un totale di 2400 thread.
Osservando i risultati dei test, in particolare la combinazione del carico sulla CPU e del TPS, vediamo chiaramente che Cloud Spanner si scala molto bene. Un carico elevato, generato da un gran numero di thread, è compensato da un maggior numero di nodi nel cluster Cloud Spanner. Sebbene la latenza sembri piuttosto alta, soprattutto con 2400 thread, potrebbe essere necessario un nuovo test con 6 istanze più piccole del motore di calcolo per ottenere numeri più precisi. Ogni istanza eseguirà un test YCSB invece di una grande istanza CE con 6 test paralleli. In questo modo, sarà più facile distinguere le latenze delle richieste di Cloud Spanner e le latenze aggiunte dalla connessione di rete tra Cloud Spanner e l'istanza CE in cui viene eseguito il test.
Come se la cava Cloud Spanner come OLAP?
Partizionamento?
Dividere i dati in segmenti fisicamente e/o logicamente indipendenti, chiamati partizioni, è un concetto molto popolare presente nella maggior parte dei meccanismi OLAP. Le partizioni possono migliorare significativamente le prestazioni delle query e la manutenibilità del database. Un'ulteriore analisi delle partizioni meriterebbe un articolo (o articoli) a parte, quindi limitiamoci a menzionare l'importanza di avere uno schema di partizionamento e sub-partizionamento. La possibilità di suddividere i dati in partizioni e persino ulteriormente in sub-partizioni è fondamentale per le prestazioni delle query analitiche.
Cloud Spanner non supporta particolarmente le partizioni. Divide i dati interni in quelli che vengono chiamati split- sulla base di intervalli di chiave primaria. La suddivisione avviene automaticamente per bilanciare il carico nel cluster Cloud Spanner. Una funzionalità molto utile di Cloud Spanner è la suddivisione del carico di base della tabella principale (la tabella che non è intercalata con un'altra). Spanner determina automaticamente se contiene split dati letti più frequentemente rispetto ai dati in altri split- e può decidere di suddividere ulteriormente. In questo modo, più nodi possono essere coinvolti nella query, aumentando inoltre l'ampiezza di banda.
Caricamento dei dati?
Il metodo Cloud Spanner per i dati voluminosi è lo stesso di un normale caricamento. Per raggiungere le massime prestazioni, è necessario seguire alcune raccomandazioni, tra cui:
- Ordina i tuoi dati in base alla chiave primaria.
- Dividili in 10*numero di nodi sezioni separate.
- Crea un insieme di task di lavoro che caricano i dati in parallelo.
Con questo caricamento di dati, vengono utilizzati tutti i nodi di Cloud Spanner.
Abbiamo utilizzato il carico di lavoro A YCSB per generare un insieme di dati di 10M righe.
* Il test di carico è stato eseguito su un motore computazionale n1-standard-32 (32 vCPU, 120 GB di memoria), e l'istanza di test non è mai stata un collo di bottiglia nei test.
** La configurazione con 1 nodo non è raccomandata per alcun carico di lavoro di produzione.
Come accennato in precedenza, Cloud Spanner gestisce automaticamente gli split in base al loro carico, quindi i risultati migliorano dopo alcuni ripetizioni consecutive del test. I risultati presentati qui sono i migliori che abbiamo ottenuto. Guardando i numeri sopra, possiamo vedere come Cloud Spanner si scala (bene) con l'aumento del numero di nodi nel cluster. I numeri che emergono rappresentano latenze medie estremamente basse, che contrastano con i risultati di carichi di lavoro misti (95% in lettura e 5% in scrittura), come descritto nella sezione precedente.
Scalabilità?
Aumentare e diminuire il numero di nodi di Cloud Spanner è un compito eseguibile con un clic. Se desideri caricare rapidamente i dati, puoi considerare di potenziare l'istanza al massimo (nel nostro caso erano 25 nodi nella regione US-EAST), e poi ridurre il numero di nodi adatti al tuo carico di lavoro normale, dopo che tutti i dati sono nel database, tenendo presente il limite di 2 TB/nodo.
Ci è stato ricordato di questo limite anche con un database molto più piccolo. Dopo diverse esecuzioni di test di carico, il nostro database aveva una dimensione di circa 155 GB, e riducendo a un'istanza di 1 nodo abbiamo ricevuto il seguente errore:
Siamo riusciti a ridurre la scala da 25 a 2 istanze, ma ci siamo bloccati su due nodi.
L'aumento e la riduzione del numero di nodi nel cluster Cloud Spanner possono essere automatizzati tramite REST API. Questo può essere particolarmente utile per ridurre un carico eccessivo sul sistema durante le ore di punta.
Prestazioni delle query OLAP?
Inizialmente prevedevamo di dedicare tempo significativo alla nostra valutazione di Spanner su questa parte. Dopo alcune SELECT COUNT, abbiamo subito capito che il test sarebbe stato breve e che Spanner NON sarebbe stato adatto come motore OLAP. Indipendentemente dal numero di nodi nel cluster, una semplice query per contare le righe in una tabella di 10 milioni di righe ha impiegato tra i 55 e i 60 secondi. Inoltre, qualsiasi query che richiedeva una maggiore quantità di memoria per memorizzare i risultati intermedi si è conclusa con un errore OOM.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M valori distinti) -> SpoolingHashAggregateIterator ha esaurito la memoria durante la nuova riga.
Alcuni dati per le query TPC-H possono essere trovati nell'articolo di Todd Lipkon , diapositive 42 e 43. Questi dati sono in linea con i nostri risultati (sfortunatamente).
4. Le nostre conclusioni
Data l'attuale stato delle funzionalità di Cloud Spanner, è difficile immaginarlo come una semplice sostituzione delle attuali soluzioni OLTP, soprattutto quando le tue esigenze supereranno le sue capacità. Sarebbe necessario dedicare un periodo di tempo significativo per costruire una soluzione tenendo conto delle carenze di Cloud Spanner.
Quando abbiamo iniziato la valutazione di Cloud Spanner, ci aspettavamo che le sue funzionalità di gestione fossero al livello, o almeno non molto distanti, da altre soluzioni Google SQL. Ma siamo rimasti sorpresi dalla totale assenza di backup e dal controllo degli accessi ai risorse molto limitato. Per non parlare dell'assenza di viste, della mancanza di un ambiente di sviluppo locale, delle sequenze non supportate, di JDBC senza supporto per DML e DDL e così via.
Quindi, dove andare per chi deve scalare un database transazionale? Sembra che attualmente non ci sia una soluzione unica sul mercato che si adatti a tutti i casi d'uso. Esistono molte soluzioni con codice sorgente chiuso e aperto (alcune delle quali vengono menzionate in questo articolo), ognuna delle quali ha i propri punti di forza e di debolezza, ma nessuna di esse offre un SaaS con SLA al 99,999% e un alto grado di coerenza. Se un alto livello di SLA è il tuo obiettivo principale e non hai intenzione di creare una soluzione personalizzata per più ambienti cloud, Cloud Spanner potrebbe rivelarsi la soluzione che stai cercando. Ma devi conoscere tutte le sue limitazioni.
A onor del vero, va detto che Cloud Spanner è stato reso accessibile solo nella primavera del 2017, quindi è ragionevole aspettarsi che alcuni dei suoi attuali difetti possano eventualmente scomparire (speriamo), e quando ciò accadrà, potrebbe cambiare le regole del gioco. Dopotutto, Cloud Spanner non è solo un progetto secondario per Google. Google lo usa come base per altri prodotti Google. E quando Google ha recentemente sostituito Megastore in Google Cloud Storage con Cloud Spanner, ciò ha permesso a Google Cloud Storage di diventare fortemente coerente per le liste degli oggetti a livello globale (il che non si applica ancora a ).
Quindi, c'è ancora speranza… speriamo.
Questo è tutto. Come l'autore dell'articolo, anche noi continuiamo a sperare, e tu cosa ne pensi al riguardo? Scrivi nei commenti
Invitiamo tutti gli interessati a visitare il nostro durante il quale parleremo in dettaglio del corso di OTUS.
Fonte: habr.com
