Questo documento aiuta gli sviluppatori di software e gli amministratori di database a eseguire la migrazione delle applicazioni Aerospike esistenti con Bigtable come database. Utilizza le tue conoscenze di Aerospike per descrivere i concetti che devi comprendere prima di eseguire la migrazione a Bigtable.
Per aiutarti a iniziare a utilizzare Bigtable e Aerospike, questo documento:
- Confronta la terminologia tra Aerospike e Bigtable.
- Fornisce una panoramica delle operazioni Bigtable e descrive il layout dei dati all'interno di Bigtable.
- Spiega la modellazione dei dati e le considerazioni chiave per la progettazione.
- Spiega come viene eseguita la replica e qual è il suo impatto.
Per informazioni sul processo di migrazione e sugli strumenti open source che puoi utilizzare per completare la migrazione, consulta Migrazione da Aerospike a Bigtable.
Confronto della terminologia
Aerospike e Bigtable sono entrambi database NoSQL distribuiti, ma differiscono in modo significativo per progettazione, funzionamento e terminologia.
In Aerospike, i dati vengono archiviati nei record. Ogni record contiene uno o più bin denominati, insieme a metadati come le dimensioni del record (in byte), la durata (TTL) e l'ora dell'ultimo aggiornamento (LUT).
Bigtable archivia i dati in tabelle scalabili, ciascuna delle quali è una mappa chiave-valore ordinata. La tabella è composta da righe indicizzate dalle chiavi di riga e da colonne identificate da un qualificatore di colonna. Se correlate tra loro, le colonne possono formare una famiglia di colonne. Questa struttura ti consente di memorizzare più versioni di un valore con la stessa chiave. Ogni versione è identificata da un timestamp univoco. Le versioni precedenti possono essere filtrate durante le operazioni di lettura o rimosse tramite la garbage collection in base ai criteri configurati.
Per saperne di più, consulta Modello di archiviazione Bigtable.
La seguente tabella delinea e descrive i concetti condivisi e la terminologia corrispondente utilizzata da ciascun prodotto:
| Aerospike | Bigtable |
|---|---|
| Nessun elemento corrispondente diretto. | Istanza: un gruppo gestito di cluster in diverse zone o regioni Google Cloud tra cui si verificano la replica e il routing delle connessioni. |
| Cluster: un deployment di Aerospike costituito da una raccolta di nodi. | cluster: un gruppo di nodi nelle stesse zone geografiche Google Cloud . |
| Nodo: un server che fornisce risorse di calcolo e possiede il proprio spazio di archiviazione. | nodo: un server che fornisce solo risorse di calcolo. L'archiviazione è gestita da Colossus, un file system distribuito separato. |
| namespace: memorizza parametri come TTL o tipo di archiviazione. All'interno di uno spazio dei nomi, i dati vengono suddivisi in set e record. | table: l'equivalente più vicino a uno spazio dei nomi Aerospike. Alcuni parametri sono impostati per tutte le tabelle a livello di cluster. È possibile un controllo più preciso a livello di tabella o famiglia di colonne. |
| set: utilizzato per la divisione logica di record e parametri come TTL e dimensione del limite. Le chiavi devono essere univoche all'interno di un insieme. | Nessun elemento corrispondente diretto. |
| Nessun elemento corrispondente diretto. | table: una risorsa a livello di istanza che viene replicata automaticamente in ogni cluster. Una tabella contiene un insieme di valori identificati da chiavi di riga univoche. Le tabelle sono sparse, il che significa che non utilizzano spazio aggiuntivo per archiviare colonne che non contengono valori. |
| Nessun elemento corrispondente diretto. | Tabella: un intervallo continuo di righe archiviate insieme. Bigtable utilizza i tablet per il bilanciamento del carico assegnandoli ai nodi. I confini dei tablet sono dinamici: possono dividersi o unirsi nel tempo. |
| Record: un insieme di bin denominati utilizzati per archiviare i dati. Può avere una dimensione massima di 8 MB. | Riga: un insieme di valori identificati da famiglia di colonne, qualificatore di colonna e timestamp. Tutte le operazioni sono atomiche a livello di riga. |
| Nessun elemento corrispondente diretto. | Famiglia di colonne: un gruppo di colonne ordinate in ordine lessicografico. La garbage collection è impostata a questo livello. |
| bin: una coppia chiave-valore in cui il nome del bin è l'identificatore di un valore all'interno di un record. | Qualificatore di colonna: un'etichetta per un valore memorizzato in una tabella. |
| Nessun elemento corrispondente diretto. | Cella: un'etichetta per un valore con timestamp memorizzato in una tabella. |
| Digest(record): hash di una tupla di tre elementi che identifica un record: spazio dei nomi, set e chiave. | Nessun elemento corrispondente diretto. |
| key: un identificatore di record univoco all'interno di un set. | Chiave di riga: un identificatore di riga univoco all'interno di una tabella. |
| AQL:uno strumento a riga di comando per sfogliare i dati e sviluppare funzioni definite dall'utente per il database Aerospike. | GoogleSQL: un linguaggio di query utilizzato da più servizi, tra cui Spanner, BigQuery e Bigtable. Google Cloud |
Limiti dei tipi di dati
La seguente tabella confronta i limiti per i tipi di dati utilizzati da Aerospike e Bigtable:
| Aerospike | Bigtable |
|---|---|
| namespace: il numero massimo di spazi dei nomi per Enterprise Edition è 32. | table: un'istanza può avere fino a 1000 tabelle. Il nome di una tabella non può superare i 50 caratteri. |
| set: un cluster può avere fino a 4095 set. Il nome di un insieme non può superare i 63 byte. | Nessun elemento corrispondente diretto. |
| Record: la dimensione massima del record è 8 MB. | Riga: la dimensione massima della riga è 256 MB. |
| Nessun elemento corrispondente diretto. | Famiglia di colonne: il numero di famiglie di colonne è illimitato, ma più di 100 possono causare un calo delle prestazioni. |
| bin: il numero di bin è illimitato, ma ogni bin può contenere non più di 1 MB di dati. Il nome del cestino non può superare i 15 byte. | Qualificatore di colonna: il limite è 100 MB, ma è consigliabile non superare i 10 MB. Il numero di colonne è illimitato. |
| key: la dimensione massima della chiave è 8 kB. | Chiave riga: la dimensione massima della chiave di riga è 4 kB. |
Per ulteriori informazioni sui limiti di Bigtable e Aerospike, consulta rispettivamente Quote e limiti e Limiti e soglie di sistema di Aerospike.
Architettura
Le sezioni seguenti forniscono una panoramica dell'architettura di Bigtable e Aerospike.
Bigtable
I nodi Bigtable sono separati dal livello di archiviazione, il che significa che non influiscono sulla durabilità dei dati. I client della tabella Bigtable non sono a conoscenza della distribuzione dei dati sottostante. Un ulteriore livello di routing distribuisce le richieste al nodo corretto. Ogni nodo gestisce un sottoinsieme delle richieste al cluster. Una tabella Bigtable viene partizionata orizzontalmente in blocchi di righe contigue, denominati tablet, che vengono archiviati su Colossus, un file system distribuito che offre un'elevata durabilità. Ogni tablet è associato a un nodo Bigtable specifico.
L'architettura di Bigtable offre i seguenti vantaggi:
- I client Bigtable non devono essere a conoscenza della distribuzione dei dati e del bilanciamento del carico. Queste complessità vengono gestite dal livello di routing.
- Il ribilanciamento avviene molto rapidamente e il ripristino in caso di errore è veloce perché i dati effettivi non vengono copiati tra i nodi.
- Quando un nodo Bigtable non funziona, non vengono persi dati.
Aerospike
A differenza di Bigtable, l'archiviazione di Aerospike si trova sui nodi che la pubblicano. Ogni nodo (un server) nel cluster Aerospike è identico. I dati in ogni spazio dei nomi vengono suddivisi in esattamente 4096 partizioni tramite l'hashing dei nomi dei record. Queste partizioni sono distribuite uniformemente tra i nodi.
I nodi sono consapevoli l'uno dell'altro e ribilanciano le partizioni archiviate quando il cluster cambia. Ogni volta che si verifica una modifica del cluster, le repliche eleggono una replica primaria che coordina il ribilanciamento. Le librerie client devono tenere traccia della replica che archivia la partizione principale e inviare le richieste di scrittura alle repliche corrette. Se un client invia una richiesta al nodo sbagliato (cosa che può accadere durante il ribilanciamento), la richiesta viene reindirizzata dai nodi.
Replica
Questa sezione confronta la procedura di replica per Aerospike e Bigtable.
Bigtable
Un'istanza Bigtable può essere costituita da un singolo cluster o da più cluster replicati. Una tabella viene sempre replicata in tutti i cluster all'interno di un'istanza. I cluster possono essere aggiunti o rimossi da un'istanza con un impatto minimo sugli altri cluster.
Bigtable fornisce la coerenza read-your-writes all'interno di un singolo cluster. Le operazioni di scrittura vengono eseguite su un singolo cluster e diventano coerenti nel tempo negli altri cluster dell'istanza. A differenza di Aerospike, Bigtable non perde gli aggiornamenti intermedi perché le singole celle sono versionate internamente, garantendo che nessuna scrittura venga persa. Ogni cluster gestisce le celle con i timestamp più recenti disponibili.
L'API Bigtable offre un token di coerenza a livello di tabella, che può essere utilizzato per verificare se tutte le modifiche apportate prima della creazione del token sono state replicate completamente.
Aerospike
Aerospike gestisce la replica all'interno di un cluster a livello di partizione. Uno spazio dei nomi viene suddiviso in partizioni distribuite uniformemente tra i nodi. La coerenza forte è garantita all'interno di un cluster. Un'operazione di scrittura viene confermata solo dopo che tutte le repliche all'interno del cluster l'hanno riconosciuta.
La replica tra data center (XDR) può essere configurata per la sincronizzazione dei dati tra cluster diversi. La convergenza dei bin di Aerospike garantisce che i dati siano alla fine gli stessi in tutti i data center al termine della replica, tuttavia gli aggiornamenti intermedi possono essere persi.
Per la durabilità, l'algoritmo di coerenza basato sull'elenco di Aerospike richiede N+1 copie per gestire N errori.
Modello dei dati
Questa sezione confronta i modelli di dati utilizzati da Bigtable e Aerospike.
Schema flessibile
Aerospike non applica vincoli di schema, consentendo a ogni record di avere bin diversi con tipi di valori variabili. Allo stesso modo, Bigtable supporta le colonne sparse, quindi non viene consumato spazio di archiviazione per le colonne senza valori. Sebbene non esista un limite rigoroso al numero di colonne o famiglie di colonne, è consigliabile mantenere il numero di famiglie di colonne inferiore a 100 per motivi di prestazioni.
Progettazione della chiave di riga
Bigtable identifica le righe in base alle chiavi di riga, che devono essere univoche all'interno di una tabella. Sono ordinate lessicograficamente e raggruppate in tablet. Ciò è diverso da Aerospike, in cui i record vengono distribuiti tra i nodi in base al loro hash. Le chiavi di riga devono essere progettate in modo da garantire che le righe a cui si accede di frequente insieme vengano archiviate insieme.
Tipi di dati
Aerospike supporta tipi di dati avanzati, tra cui scalari, GeoJSON, HyperLogLog, elenchi e oggetti nidificati. Questi tipi possono essere indicizzati e interrogati con il supporto degli indici secondari. Inoltre, Aerospike fornisce API lato server che consentono operazioni complesse su questi tipi di dati, come il filtraggio per geolocalizzazione o la manipolazione dei contenuti degli elenchi.
L'API Bigtable si concentra principalmente sulla gestione dei byte non elaborati, con alcune eccezioni. Inoltre, utilizza in modo nativo INT64 per timestamp e contatori, che possono essere incrementati come operazione atomica. Il linguaggio di query supporta anche molti tipi complessi come scalari, oggetti JSON e contenitori HLL. I tipi avanzati potrebbero essere sempre più supportati in futuro, ma al momento della stesura di questo documento non è possibile inserire questi tipi in Bigtable, tutto viene serializzato lato client. Puoi utilizzare la libreria di adattatori di aerospike-migration-tools per serializzare i tipi di dati.
Famiglia di colonne
In Bigtable, le famiglie di colonne definiscono quali colonne di una tabella vengono archiviate e recuperate insieme e deve esistere almeno una famiglia di colonne per ogni tabella. Le colonne correlate devono essere raggruppate nella stessa famiglia. I dati con requisiti di conservazione diversi devono essere separati in famiglie di colonne distinte, poiché le norme di Garbage Collection si applicano a livello di famiglia di colonne.
Qualificatori di colonna
In Bigtable, i qualificatori di colonna vengono utilizzati all'interno di una famiglia di colonne per definire le singole colonne. Le tabelle possono supportare milioni di colonne, ma la best practice è limitare il numero di colonne in una singola riga. Facoltativamente, i qualificatori di colonna possono essere trattati come dati, consentendo di incorporare i valori direttamente nel nome della colonna per risparmiare spazio.
Celle
In Bigtable, una cella è l'intersezione della chiave di riga e del nome della colonna (una famiglia di colonne combinata con un qualificatore di colonna). Ogni cella contiene uno o più valori con timestamp che possono essere forniti dal client o applicati automaticamente dal servizio.
Indici secondari
Le viste materializzate continue possono fungere da indici secondari asincroni, consentendo di eseguire query sulle tabelle utilizzando attributi o pattern di ricerca diversi. Per saperne di più, consulta Crea un indice secondario asincrono.
Transazioni
Bigtable e Aerospike non supportano le transazioni multiriga, ma differiscono per le funzionalità a riga singola. Bigtable fornisce scritture su una sola riga completamente coerenti all'interno di un cluster e supporta le transazioni su una sola riga tramite richieste mutate-row. Consentono più operazioni su una singola riga, tutte eseguite in modo atomico e tutte riuscite o tutte non riuscite. Inoltre, sono disponibili le operazioni di lettura-modifica-scrittura e di controllo e modifica, anche se non sono disponibili con i profili di routing multi-cluster. Al contrario, Aerospike estende le transazioni a una sola riga con la manipolazione dei dati lato server e l'esecuzione di funzioni definite dal client.
Bilanciamento del carico e failover
Aerospike utilizza Smart Client per gestire il bilanciamento del carico lato client. Un processo in esecuzione lato client che è a conoscenza dello stato del cluster e della distribuzione dei dati. Questo client è responsabile dell'instradamento della richiesta.
Se un nodo non funziona o viene aggiunto un nuovo nodo, il cluster deve essere ribilanciato. Viene scelta un'istanza primaria temporanea per orchestrare l'operazione di ribilanciamento e ridistribuzione delle partizioni tra i nodi. Durante questo periodo, il cluster rimane operativo, ma il client deve monitorare le modifiche per il routing delle richieste. Se una richiesta raggiunge il nodo sbagliato, viene indirizzata internamente a quello corretto.
Il client Bigtable è un thin client che nasconde all'utente tutte le complessità, come lo stato del cluster e la distribuzione dei dati. Il routing della richiesta viene gestito dal livello successivo, un client spesso all'interno dell'infrastruttura di Google CloudBigtable.
Un'altra differenza è la policy di routing, che non è disponibile in Aerospike. Bigtable utilizza i profili dell'applicazione per gestire il routing delle richieste, con priorità configurabili per controllare l'ordine in cui vengono gestite le richieste. Esistono due tipi di criteri di routing: a cluster singolo e a cluster multipli. Un profilo multi-cluster indirizza le operazioni al cluster disponibile più vicino. I cluster nella stessa regione sono considerati equidistanti dal punto di vista del router delle operazioni. Se il nodo responsabile dell'intervallo di chiavi richiesto è sovraccarico o temporaneamente non disponibile in un cluster, questo profilo fornisce il failover automatico. Al contrario, Aerospike non fornisce il failover automatico in caso di errore completo del cluster.
Backup e ripristino
Aerospike fornisce strumenti esterni di backup e ripristino chiamati asbackup e asrestore che creano backup logici lato client e sono analoghi all'esecuzione di una scansione. La gestione dei backup può essere gestita anche tramite il servizio di backup Aerospike o l'operatore Aerospike Kubernetes, entrambi utilizzano internamente asbackup e asrestore e forniscono la pianificazione e il coordinamento multi-processo. I backup non sono atomici, il che significa che le operazioni di scrittura eseguite durante il backup potrebbero non essere acquisite.
Bigtable offre due metodi per soddisfare le esigenze comuni di backup: backup di Bigtable ed esportazioni di dati gestite. I backup creano copie ripristinabili di una tabella, che vengono archiviate come oggetti membri di un cluster. Puoi ripristinare i backup come nuova tabella nel cluster che ha avviato il backup. I backup sono progettati per creare punti di ripristino in caso di danneggiamento a livello di applicazione. Inoltre, i backup di Bigtable non sono atomici. Le modifiche potrebbero essere apportate in una sezione della tabella già copiata dal backup.
Differenze principali nella gestione dei backup
- I backup di Aerospike vengono creati lato client. Non richiedono spazio aggiuntivo lato server, ma sono più lenti. In Bigtable, un backup condivide lo spazio di archiviazione fisico con la tabella di origine e altri backup della tabella.
- L'utente di Aerospike deve gestire l'esportazione, l'archiviazione e la rimozione dei backup obsoleti. Poiché i backup in Bigtable sono completamente integrati, tutte queste azioni vengono gestite automaticamente dal servizio Bigtable.
Considerazioni sulle prestazioni
Poiché Aerospike e Bigtable trattano le operazioni di lettura e scrittura in modo diverso, presentano differenze di prestazioni importanti da considerare. La tabella seguente include diversi esempi di differenze di prestazioni tra i due database. Per ulteriori informazioni, consulta le linee guida per il rendimento di Bigtable.
| Considerazione | Bigtable | Aerospike |
|---|---|---|
| Righe calde | Distribuisce i tablet e le operazioni per uniformare l'utilizzo delle risorse. Una riga a cui si accede di frequente può essere isolata in una tabella a una sola riga su un nodo, limitando l'impatto sulle altre righe. | Distribuisce le righe in base agli hash su tutti i nodi, indipendentemente dal traffico. Una riga calda può influire sul rendimento di un'intera partizione. |
| Scansioni su chiavi ordinate | Archivia i dati in ordine lessicografico, il che lo rende molto efficace per lo streaming di dati ordinati. | Distribuisce i record in base agli hash, quindi la scansione di molte chiavi consecutive richiede l'interrogazione di più nodi e l'aggregazione dei risultati, il che può essere più lento. Supporta gli indici secondari, inclusi i tipi avanzati, che potrebbero ridurre la necessità di scansioni. |
| Inserimento di molte chiavi consecutive | Archivia i dati in ordine lessicografico, il che significa che un singolo nodo gestisce molte operazioni di scrittura di chiavi consecutive. Di conseguenza, un pattern di lettura o scrittura può finire sul nodo che contiene il tablet responsabile della fine dello spazio chiave di riga, sovraccaricandolo di fatto. | Distribuisce le chiavi in base all'hash, distribuendo il carico tra più nodi durante la scrittura di chiavi consecutive. |
| Righe con un numero molto elevato di colonne | Sebbene Bigtable possa supportare righe fino a 256 MB, l'elaborazione di righe di grandi dimensioni può influire sulle prestazioni. Bigtable è ottimizzato per righe più piccole, pertanto l'organizzazione delle celle e l'accesso ai dati devono essere presi in considerazione durante la progettazione dello schema per evitare di distribuire i dati su molte celle, se non necessario. | Funziona in modo non ottimale quando incontra una riga o un record con un numero molto elevato di colonne o bin. |
| Avvii a freddo | Funziona meglio con tabelle di grandi dimensioni a cui si accede di frequente. Se inizi a inviare richieste dopo un periodo di inattività (avvio a freddo), potresti notare una latenza elevata. Ciò accade perché la suddivisione in tablet e la loro distribuzione tra i nodi potrebbero non essere ottimali e perché le cache sono fredde. La distribuzione tra i nodi potrebbe non essere completamente ottimale fino a qualche minuto durante l'avvio a freddo e il ribilanciamento. | Il rendimento non cambia nel tempo perché la distribuzione dei dati non è basata sul carico. Mentre le cache devono essere riscaldate, gli indici vengono mantenuti in memoria, riducendo al minimo il tempo di ricerca sul disco e l'importanza della memorizzazione nella cache. |
| Molte tabelle piccole | Evita di creare molte tabelle piccole. Tabelle separate sono giustificate per schemi o casi d'uso diversi, ma non per dati simili, in quanto non migliorano il bilanciamento del carico e aumentano il sovraccarico di gestione. | La maggior parte dei record si trova in uno spazio dei nomi, raggruppati in set. I set non hanno schemi specifici, ma è possibile impostare indici secondari o operazioni di scansione per set. La suddivisione dei dati in set non influisce sul rendimento. |
| Set di dati di grandi dimensioni | In grado di archiviare set di dati nell'ordine degli exabyte. Le prestazioni non sono influenzate dalle dimensioni totali del set di dati grazie alla sua architettura e alla suddivisione dinamica delle tabelle. | Tecnicamente, i database Aerospike non hanno un limite di dimensioni, tuttavia Aerospike archivia separatamente indici e record. Entrambi i tipi di dati possono essere archiviati su tipi diversi di dispositivi di archiviazione per aumentare le prestazioni. L'archiviazione degli indici nella RAM è essenziale per ottenere latenze ridotte, ma potrebbe non essere fattibile per set di dati molto grandi. Ad esempio, con 4 miliardi di oggetti e un fattore di replica di 2 (RF2), la memoria consumata in associazione all'indice principale nel cluster in All Flash è 2,5 GiB. Utilizzando lo stesso esempio in una configurazione di memoria ibrida, in cui l'indice principale si trova in memoria, verranno utilizzati 476,8 GiB di memoria. |
| Scalabilità | L'elaborazione e l'archiviazione sono disaccoppiate e possono essere scalate in modo indipendente. Un singolo nodo può gestire blocchi di dati di diverse centinaia di terabyte o addirittura petabyte. | L'archiviazione degli indici nella RAM è essenziale per ottenere latenze ridotte. In questo caso, le macchine devono essere scalate verticalmente insieme alla capacità di archiviazione per tenere conto dell'indice primario. |
Passaggi successivi
- Scopri di più sulla progettazione dello schema Bigtable.
- Scopri di più su Aerospike.
- Scopri di più sull'emulatore Bigtable.
- Esplora architetture, diagrammi e best practice di riferimento su Google Cloud. Consulta il nostro Cloud Architecture Center.