Migrazione da Aerospike a Bigtable

Questo documento ti guida nella procedura di migrazione dei dati da Aerospike a Bigtable. Descrive come utilizzare strumenti open source, come la libreria dell'adattatore, per eseguire la migrazione.

Prima di iniziare la migrazione, acquisisci familiarità con Bigtable per gli utenti di Aerospike.

Panoramica della migrazione

Puoi eseguire la migrazione dei dati da Aerospike a Bigtable con tempi di inattività minimi o nulli.

Il seguente diagramma illustra i passaggi della migrazione:

Il processo di migrazione di Aerospike a Bigtable.
Figura 1. Il processo di migrazione di Aerospike a Bigtable (fai clic per ingrandire).
  1. Trasmetti in streaming le modifiche in corso:replica gli aggiornamenti in corso da Aerospike a Bigtable utilizzando il connettore di origine Aerospike Kafka (in uscita) e il connettore di sink Kafka Connect Bigtable.
  2. Importazione del backup:crea un backup di Aerospike e importalo in Bigtable utilizzando il job Dataflow AerospikeBackupToBigtable.
  3. Esegui il cutover:sposta il traffico dell'applicazione su Bigtable.

Ambito e compatibilità della migrazione

Poiché Bigtable opera su byte non elaborati anziché su bin tipizzati, il processo di migrazione prevede la mappatura delle funzionalità di Aerospike a strutture Bigtable compatibili. La libreria di adattatori fornisce gli strumenti necessari per ottenere la compatibilità strutturale e colmare le lacune, ad esempio la serializzazione degli oggetti. Tuttavia, alcune funzionalità, come le funzioni definite dall'utente (UDF), non possono essere migrate a causa di differenze fondamentali tra i sistemi.

La tabella seguente riassume il modo in cui il processo di migrazione gestisce le funzionalità di Aerospike.

Funzionalità Supporto Descrizione
Architettura di memoria ibrida (HMA) di Aerospike Supportato Eseguita la migrazione al livello di archiviazione SSD o al livello in memoria. La versione Bigtable Enterprise Plus fornisce l'accesso allo spazio di archiviazione in memoria per i workload sensibili alla latenza che richiedono tempi di risposta inferiori al millisecondo, simili alle prestazioni di Aerospike.
Scalari (Int, Float, String, Bool) Supportato Migrazione alle celle Bigtable.
Elenchi e mappe Supportato Le mappe devono avere chiavi stringa. Gli elenchi e le mappe vengono serializzati in colonne separate dalla libreria dell'adattatore.
Indici secondari Parzialmente supportate Non viene eseguita la migrazione diretta. Deve essere implementato nuovamente come indici secondari asincroni.
Durata (TTL) a livello di record Supportato Configurato a livello di famiglia di colonne o simulato per cella in Bigtable.
UDF Non supportata La logica lato server personalizzata deve essere spostata nell'applicazione lato client.
HyperLogLog Non supportata Non supportato nel processo di migrazione.
GeoJSON Non supportata Non supportato nel processo di migrazione.
Chiavi di record Non supportata Le chiavi dei record non vengono migrate direttamente. La migrazione utilizza invece il digest del record come chiave di riga.

Prima di iniziare

Prima di iniziare la migrazione, completa i seguenti passaggi preparatori per ridurre i rischi e garantire una transizione senza problemi:

  • Convalida i dati:verifica che il deployment di Aerospike non si basi su tipi di dati, indici secondari o UDF non supportati. Come misura di salvaguardia, puoi importare un sottoinsieme rappresentativo dei tuoi dati in Bigtable e convalidare la progettazione dello schema.
  • Esegui il provisioning dell'infrastruttura:configura i servizi richiesti per la pipeline di migrazione: Bigtable, Kafka e Kafka Connect.
    • Pianificazione della capacità: esegui il provisioning di Bigtable con una capacità sufficiente a gestire il workload previsto. Seleziona una regione vicina al cluster Aerospike esistente. Per indicazioni sulla stima delle risorse richieste, consulta Informazioni sulle prestazioni di Bigtable.
    • Livello di archiviazione: per i carichi di lavoro che richiedono tempi di risposta inferiori al millisecondo, valuta la possibilità di utilizzare il livello in memoria di Bigtable. Questo livello archivia i dati nella RAM per fornire le massime prestazioni per le applicazioni con molte letture o sensibili alla latenza. Per ulteriori informazioni, consulta la panoramica del livello in memoria.
  • Configura l'accesso e il networking:assegna i ruoli Identity and Access Management (IAM) appropriati e assicurati la connettività di rete.
  • Attiva il monitoraggio e la segnalazione degli errori:configura l'osservabilità per il nuovo ambiente, inclusi logging, metriche e avvisi.
  • Misura le prestazioni di base: registra le prestazioni attuali del sistema per fornire un riferimento per la convalida dopo la migrazione.
  • Crea backup:crea un backup completo dei dati di Aerospike.
  • Esegui una migrazione di prova:convalida la configurazione in un ambiente di staging prima di tentare una migrazione di produzione.

Migrazione dei dati

Completa i seguenti passaggi per eseguire la migrazione dei dati da Aerospike a Bigtable.

Avviare il flusso di modifiche

Quando abiliti lo stream di modifiche di Aerospike, il connettore di origine Aerospike Kafka (in uscita) inizia a pubblicare gli aggiornamenti dei record Aerospike in un argomento Kafka. Assicurati che Kafka disponga di spazio di archiviazione sufficiente per memorizzare nel buffer le modifiche e configura il connettore per generare dati in formato JSON.

Di seguito è riportata una configurazione di esempio del connettore Kafka:


  service:
    port: <port_to_run_on>

  producer-props:
    bootstrap.servers:
      - <kafka_host>

  format:
    mode: json
    metadata-key: metadata

  routing:
    mode: static
    destination: <kafka_topic>

La comunicazione con Kafka utilizzando il connettore di origine Aerospike Kafka (in uscita) richiede Aerospike Cross-Datacenter Replication (XDR), che replica in modo asincrono le modifiche al cluster tramite link a latenza più elevata. XDR è disponibile solo in Aerospike Enterprise Edition. Se utilizzi Aerospike Community Edition, passa a Enterprise Edition o esegui una migrazione offline utilizzando solo il job AerospikeBackupToBigtable Dataflow.

Una configurazione di esempio per XDR in Aerospike è la seguente:


  xdr {
      dc aerospike-kafka-source {
              connector true
              node-address-port <aerospike_connect_host> <aerospike_connect_port>
              namespace <your_namespace_to_replicate> {
              }
      }
  }

Esportare dati da Aerospike

Dopo aver avviato lo stream di modifiche, genera un backup del set di dati Aerospike esistente. Utilizza lo strumento a riga di comando asbackup per creare backup da un cluster di database Aerospike. Alcuni aggiornamenti potrebbero essere visualizzati sia nel backup sia nel flusso delle modifiche, il che è previsto e non influisce sulla migrazione. Per consentire le importazioni parallele durante il ripristino, dividi i backup in più file.

Importa dati in Bigtable

Per importare i dati di backup in Bigtable:

  1. Carica il backup in un bucket Cloud Storage.
  2. Esegui il job Dataflow AerospikeBackupToBigtable per importare il backup in Bigtable. Se il backup è suddiviso in più file, il job li elabora in parallelo. Per gestire il carico di scrittura aumentato e mantenere un throughput ottimale, esegui il provisioning di risorse Bigtable aggiuntive.

Applica gli aggiornamenti dei record a Bigtable

Dopo aver importato il backup in Bigtable, applica gli aggiornamenti dei record memorizzati nel buffer in Kafka a Bigtable utilizzando il connettore sink Bigtable di Kafka Connect.

Tradurre i messaggi in un formato compatibile

Gli strumenti di migrazione di Aerospike includono Replicator SMT, che viene eseguito in Kafka Connect. Il replicatore traduce i messaggi pubblicati dal connettore di origine Aerospike Kafka (in uscita) in un formato compatibile con il sink di destinazione che scrive i record in Bigtable. La traduzione è necessaria perché il sink prevede dati in un formato specifico diverso da quello in cui Aerospike trasmette le modifiche.

La seguente tabella ti aiuta a stimare le risorse macchina necessarie per ottenere un determinato throughput:

Struttura del record Throughput Latenza p99
Piatto Fino a 3700 record al secondo per vCPU 300 ms
Nidificati Fino a 2600 record al secondo per vCPU 300 ms

Queste stime presuppongono che i record serializzati in formato JSON abbiano una dimensione di 1 KB. Il tempo di analisi aumenta con la complessità delle strutture dei messaggi, il che significa che l'analisi degli oggetti nidificati archiviati nei record Aerospike richiede più tempo.

Puoi utilizzare la metrica consumer_lag per verificare quanti messaggi si trovano nella coda di elaborazione e misurare il ritardo di replica. Quando il sink elabora l'arretrato di messaggi nell'argomento, il ritardo del consumer diminuisce fino a stabilizzarsi vicino allo zero, a quel punto il sink elabora gli aggiornamenti di Aerospike quasi in tempo reale, preparandoti per il cutover. Puoi utilizzare sink-record-active-count per verificare il numero di messaggi già elaborati.

Importa messaggi con il connettore di sink Kafka Connect Bigtable

Il connettore di sink Kafka Connect Bigtable importa i messaggi da Kafka a Bigtable. Quando configuri il connettore, imposta insert.mode su REPLACE_IF_NEWEST per assicurarti che il record scritto nella riga di destinazione in Bigtable sia il più recente. Per saperne di più, consulta Configurazione del connettore sink Kafka Connect Bigtable.

La tabella seguente fornisce indicazioni sulla latenza introdotta e sulle risorse di calcolo richieste per diversi workload:

Struttura del record Throughput Latenza p99
Piatto Fino a 3700 record al secondo per vCPU 74 ms
Nidificati Fino a 3700 record al secondo per vCPU 100 ms

Queste stime presuppongono che i record serializzati in formato JSON abbiano una dimensione di 1 KB. La latenza segnalata è il tempo di elaborazione nel sink. Supponi un overhead aggiuntivo per l'invio di una richiesta di scrittura a Bigtable di circa 600 ms.

Passa a Bigtable

Passa all'utilizzo di Bigtable come database principale.

Per garantire la coerenza read-your-writes, chiudi temporaneamente l'applicazione finché il ritardo di replica non raggiunge lo zero. In questo modo, nessuna mutazione viene persa e le letture dei dati riflettono lo stato più recente.

Ad esempio, una mutazione applicata in Aerospike poco prima del cutover potrebbe non essere ancora replicata in Bigtable, causando letture non aggiornate. Per evitare questo scenario, mantieni l'applicazione offline finché le metriche consumer_lag e sink-record-active-count non raggiungono 0. Dopo la propagazione di tutte le modifiche in attesa, riavvia l'applicazione con Bigtable come database principale.

Sebbene una migrazione live possa evitare tempi di inattività, presenta i seguenti vincoli:

  • Le mutazioni applicate in Bigtable non vengono replicate in Aerospike.
  • Le mutazioni provenienti da Aerospike potrebbero essere visualizzate in Bigtable con un ritardo.
  • Le mutazioni ritardate di Aerospike possono sovrascrivere gli aggiornamenti più recenti in Bigtable.

Verifica il deployment

Dopo il deployment, convalida il rendimento dell'applicazione esaminando metriche quali tassi di errore, latenza e costi. Puoi anche eseguire controlli sull'integrità dei dati.

Monitoraggio e osservabilità

Monitora le seguenti metriche durante la migrazione:

  • Ritardo totale: calcolato come ritardo del consumer Kafka più sink-record-active-count. Queste metriche indicano il ritardo di Bigtable rispetto ad Aerospike. È necessario un valore di ritardo stabile prima di reindirizzare il traffico a Bigtable.
  • Utilizzo di CPU e memoria: monitora l'utilizzo di CPU e memoria di tutti i componenti della pipeline di stream delle modifiche.
  • Capacità di archiviazione Kafka: monitora la capacità per le implementazioni Kafka autogestite. Se lo spazio di archiviazione si riempie, i nuovi eventi non possono essere memorizzati nel buffer, causando l'errore di migrazione.
  • Tassi di errore dell'applicazione: monitora i tassi di errore e gli output di errore di tutti gli elementi della pipeline del flusso di modifiche.

Limitazioni

Le sezioni seguenti descrivono in dettaglio le limitazioni da considerare durante la migrazione dei dati da Aerospike a Bigtable.

Coerenza dei dati durante la migrazione

Quando utilizzi lo strumento asbackup per generare il backup di Aerospike, i record modificati durante il processo di backup potrebbero essere esclusi perché il processo di backup non supporta i backup atomici. Questa limitazione non influisce sulla correttezza perché tutte le modifiche vengono visualizzate nel flusso di modifiche.

Durante l'importazione del backup in Bigtable, ogni riga viene scritta con un timestamp dell'ora dell'ultimo aggiornamento (LUT) di 0. Gli aggiornamenti dallo stream delle modifiche vengono applicati in aggiunta al backup importato. Le righe scritte dallo stream utilizzano il valore della tabella di ricerca come timestamp della riga Bigtable. La configurazione del sink fa sì che l'aggiornamento con un timestamp più recente sovrascriva quello precedente. In questo modo, qualsiasi modifica riprodotta dallo stream sovrascrive la riga corrispondente.

Utilizzo della LUT

Il processo di migrazione utilizza Aerospike XDR per replicare le modifiche e si basa sulla LUT per la risoluzione dei conflitti. Poiché le LUT si basano sull'orologio di sistema del nodo, potrebbero non essere strettamente monotone. Di conseguenza, un record obsoleto potrebbe occasionalmente avere una LUT più recente e sovrascrivere un record più recente. Inoltre, il connettore di origine Aerospike Kafka (in uscita) potrebbe non conservare l'ordine esatto dei messaggi durante la pubblicazione su Kafka. Di conseguenza, la LUT funge da indicatore della versione autorevole, garantendo che a Bigtable vengano applicati solo i record con la LUT più recente.

Se un record viene aggiornato dopo l'avvio dello stream di modifiche, ma prima della generazione del backup, il backup potrebbe acquisire la versione più recente, mentre lo stream contiene una versione precedente. Questa versione precedente potrebbe sovrascrivere temporaneamente quella più recente. Tuttavia, quando arriva l'evento di stream successivo con la LUT corretta, viene ripristinata l'ultima versione. Per evitare incoerenze, attendi di eseguire il cutover finché la replica non si stabilizza e il messaggio non elaborato meno recente nella pipeline non è più recente del backup.

Convalida dei dati

La pipeline di migrazione non esegue il controllo della somma di controllo dei dati in transito. Se hai bisogno di controlli di integrità dei dati end-to-end, devi implementare la convalida.

Risoluzione dei problemi

Le sezioni seguenti descrivono gli errori comuni che potrebbero verificarsi durante il processo di migrazione e forniscono indicazioni su come risolverli.

Errori di importazione del backup

Durante l'importazione del backup di Aerospike in Bigtable, potresti riscontrare i seguenti errori:

Tipo di errore Causa Soluzione
File di backup danneggiato I file di backup sono illeggibili o contengono record danneggiati. Il job di importazione non riesce. Controlla i file interessati per verificare la presenza di problemi di integrità. Se non è recuperabile, genera un nuovo backup e ripeti l'importazione.
Errori di scrittura di Bigtable Si verificano problemi di connettività o di servizio Bigtable. L'importazione non ha esito negativo. I record non riusciti vengono esportati in un file di output degli errori in formato JSON. Applicali di nuovo manualmente o riprova a eseguire il job di importazione completo.
Dati non supportati Il backup contiene voci che non possono essere importate in Bigtable. L'importazione non ha esito negativo. I dati non supportati, come le UDF, vengono segnalati come avvisi nei log dei job. Esamina i log per verificare la presenza di voci non supportate.

Una volta completata l'importazione del backup e risolti i problemi relativi ai record non validi, puoi procedere all'applicazione dello stream delle modifiche.

Errori del flusso di modifiche

Durante l'applicazione dello stream di modifiche, potrebbero verificarsi errori ai seguenti livelli:

  • Errori SMT di Replicator:SMT non riesce a trasformare i dati prodotti da Aerospike.
  • Errori di destinazione:gli eventi non possono essere applicati a Bigtable.

In entrambi i casi, gli eventi non riusciti vengono reindirizzati a un argomento Kafka dedicato. Puoi registrare gli eventi per il controllo o elaborarli utilizzando una logica di recupero personalizzata.

Passaggi successivi