Esercitazione: Eseguire la migrazione dei dati a un account API per Cassandra

Articolo
03/25/2024

SI APPLICA A: Cassandra

Gli sviluppatori potrebbero avere carichi di lavoro Cassandra esistenti in esecuzione in locale o nel cloud e volerne eseguire la migrazione in Azure. È possibile eseguire la migrazione di tali carichi di lavoro a un account API per Cassandra in Azure Cosmos DB. Questa esercitazione fornisce istruzioni sulle diverse opzioni disponibili per eseguire la migrazione dei dati Apache Cassandra nell'account dell'API per Cassandra in Azure Cosmos DB.

Questa esercitazione illustra le attività seguenti:

Pianificare la migrazione
Prerequisiti per la migrazione
Eseguire la migrazione dei dati con il comando cqlshCOPY
Eseguire la migrazione dei dati con Spark

Se non si ha una sottoscrizione di Azure, creare un account gratuito prima di iniziare.

Prerequisiti per la migrazione

Stimare le esigenze di velocità effettiva: prima di eseguire la migrazione dei dati nell'account dell'API per Cassandra in Azure Cosmos DB, è necessario stimare le esigenze di velocità effettiva del carico di lavoro. In generale, iniziare con la velocità effettiva media necessaria per le operazioni CRUD, quindi includere la velocità effettiva aggiuntiva necessaria per le operazioni picco o di estrazione, trasformazione e caricamento. Per pianificare la migrazione, sono necessari i dettagli seguenti:
- Dimensioni dei dati esistenti o dimensioni dei dati stimate: definisce i requisiti minimi di dimensione e velocità effettiva del database. Se si sta stimando la dimensione dei dati per una nuova applicazione, è possibile presumere che i dati vengano distribuiti uniformemente tra le righe e stimare il valore moltiplicando la dimensione dei dati.
- Velocità effettiva necessaria: velocità effettiva approssimativa delle operazioni di lettura (query/get) e scrittura (update/delete/insert). Questo valore è obbligatorio per calcolare le unità richiesta necessarie insieme alle dimensioni dei dati con stato stabile.
- Schema: connettersi al cluster Cassandra esistente tramite cqlsh ed esportare lo schema da Cassandra:
```
cqlsh [IP] "-e DESC SCHEMA" > orig_schema.cql
```
  Dopo avere identificato i requisiti del carico di lavoro esistente, creare un account, un database e i contenitori Azure Cosmos DB in base ai requisiti di velocità effettiva raccolti.
- Determinare l'addebito di unità richiesta per un'operazione: è possibile determinare le unità richiesta usando uno degli SDK supportati dall'API per Cassandra. Questo esempio illustra la versione .NET per ottenere gli addebiti delle unità richiesta.
```
var tableInsertStatement = table.Insert(sampleEntity);
var insertResult = await tableInsertStatement.ExecuteAsync();

foreach (string key in insertResult.Info.IncomingPayload)
  {
     byte[] valueInBytes = customPayload[key];
     double value = Encoding.UTF8.GetString(valueInBytes);
     Console.WriteLine($"CustomPayload:  {key}: {value}");
  }
```
Allocare la velocità effettiva necessaria: Azure Cosmos DB può eseguire automaticamente la scalabilità della risorsa di archiviazione e della velocità effettiva man mano che aumentano i requisiti. Per stimare le esigenze di unità elaborate, usa il calcolatore di unità richieste di Azure Cosmos DB.
Creare le tabelle nell'account dell'API per Cassandra: prima di iniziare la migrazione dei dati, creare in anticipo tutte le tabelle dal portale di Azure o da cqlsh. Se si esegue la migrazione a un account Azure Cosmos DB con velocità effettiva a livello di database, assicurarsi di fornire una chiave di partizione quando si creano i contenitori.
Aumentare la velocità effettiva: la durata della migrazione dei dati dipende dalla velocità effettiva di cui è stato eseguito il provisioning per le tabelle in Azure Cosmos DB. Aumentare la velocità effettiva per la durata della migrazione. Con una velocità effettiva più elevata, è possibile evitare la limitazione di velocità e completare più rapidamente la migrazione. Dopo avere completato la migrazione, diminuire la velocità effettiva per ridurre i costi. È anche consigliabile disporre dell'account Azure Cosmos DB nella stessa area del database di origine.
Abilitare TLS: Azure Cosmos DB ha standard e requisiti di sicurezza restrittivi. Assicurarsi di abilitare TLS quando si interagisce con l'account. Quando si usa CQL con SSH, è possibile fornire le informazioni TLS.

Opzioni per la migrazione dei dati

È possibile spostare dati da carichi di lavoro esistenti di Cassandra in Azure Cosmos DB usando il comando cqlshCOPY o Spark.

Eseguire la migrazione dei dati tramite il comando cqlsh COPY

Usare il comando CQL COPY per copiare i dati locali nell'account API per Cassandra in Azure Cosmos DB.

Avviso

Usare CQL COPY solo per eseguire la migrazione di set di dati di piccole dimensioni. Per spostare set di dati di grandi dimensioni, eseguire la migrazione dei dati usando Spark.

Per essere certi che il file CSV contenga la struttura di file corretta, usare il comando COPY TO per esportare i dati direttamente dalla tabella Cassandra di origine in un file CSV (assicurarsi che cqlsh sia connesso alla tabella di origine usando le credenziali appropriate):
```
COPY exampleks.tablename TO 'data.csv' WITH HEADER = TRUE;   
```
Ottenere ora le informazioni sulla stringa di connessione dell'account Cassandra per l'API:
- Accedere al portale di Azure e passare all'account Azure Cosmos DB.
- Aprire il riquadro Stringa di connessione. Qui vengono visualizzate tutte le informazioni necessarie per connettersi all'account API per Cassandra da cqlsh.
Accedere a cqlsh usando le informazioni di connessione del portale.
Usare il comando CQLCOPY FROM per copiare data.csv (ancora presente nella directory radice dell'utente in cui è installato cqlsh):
```
COPY exampleks.tablename FROM 'data.csv' WITH HEADER = TRUE;
```

Nota

L'API per Cassandra supporta la versione 4 del protocollo fornita con Cassandra 3.11. Potrebbero verificarsi problemi con l'uso di versioni successive del protocollo con l'API. COPY FROM con una versione successiva del protocollo può entrare in un ciclo e restituire righe duplicate. Aggiungere la versione del protocollo al comando cqlsh.

cqlsh <USERNAME>.cassandra.cosmos.azure.com 10350 -u <USERNAME> -p <PASSWORD> --ssl --protocol-version=4

Aggiungere opzioni di limitazione della velocità effettiva al comando CQL Copy

Il comando COPY in cqlsh supporta vari parametri per controllare la frequenza di inserimento di documenti in Azure Cosmos DB.

La configurazione predefinita per il comando COPY tenta di inserire dati a un ritmo molto rapido e non tiene conto del comportamento di limitazione della frequenza di CosmosDB. È consigliabile ridurre CHUNKSIZE o INGESTRATE a seconda della velocità effettiva configurata nella raccolta.

È consigliabile usare almeno la configurazione seguente per una raccolta a 20.000 UR se la dimensione del documento o del record è di 1 KB.

CHUNKSIZE = 100
INGESTRATE = 500
MAXATTEMPTS = 10

Comandi di esempio

Copia dei dati dall'API per Cassandra al file CSV locale

COPY standard1 (key, "C0", "C1", "C2", "C3", "C4") TO 'backup.csv' WITH PAGESIZE=100 AND MAXREQUESTS=1 ;

Copia dei dati dal file CSV locale all'API per Cassandra

COPY standard2 (key, "C0", "C1", "C2", "C3", "C4") FROM 'backup.csv' WITH CHUNKSIZE=100 AND INGESTRATE=100 AND MAXATTEMPTS=10;

Importante

È supportata solo la versione open source di Apache Cassandra di CQLSH COPY. Le versioni Datastax Enterprise (DSE) di CQLSH possono riscontrare errori.

Eseguire la migrazione dei dati con Spark

Usare questa procedura per eseguire la migrazione dei dati nell'account dell'API per Cassandra con Spark:

Effettuare il provisioning di un cluster di Azure Databricks o un cluster Azure HDInsight.
Spostare i dati nell'API di destinazione per l'endpoint Cassandra. Vedere questa guida pratica per la migrazione con Azure Databricks.

La migrazione dei dati usando i processi Spark è un'opzione consigliata se i dati risiedono in un cluster esistente nelle macchine virtuali di Azure o in qualsiasi altro cloud. A tale scopo, è necessario configurare Spark come intermediario per l'inserimento una tantum o regolare. È possibile accelerare questa migrazione usando la connettività di Azure ExpressRoute tra l'ambiente locale e Azure.

Live Migration

Quando è necessaria una migrazione senza tempi di inattività da un cluster Apache Cassandra nativo, è consigliabile configurare operazioni di doppia scrittura e un carico di dati bulk separato per eseguire la migrazione dei dati cronologici. L'implementazione di questo modello è stata resa più semplice tramite un proxy open source a doppia scrittura per consentire modifiche minime al codice dell'applicazione. Per altre informazioni sull'implementazione di questo modello, vedere l'articolo sulle procedure per la migrazione in tempo reale tramite proxy a doppia scrittura e Apache Spark.

Pulire le risorse

Quando non servono più è possibile eliminare il gruppo di risorse, l'account Azure Cosmos DB e tutte le risorse correlate. A tale scopo, selezionare il gruppo di risorse per la macchina virtuale, selezionare Elimina e quindi confermare il nome del gruppo di risorse da eliminare.

Passaggi successivi

In questa esercitazione si è appreso come migrare i dati utente in un account dell'API per Cassandra in Azure Cosmos DB. È ora possibile ottenere informazioni su altri concetti in Azure Cosmos DB:

Livelli di coerenza dei dati ottimizzabili in Azure Cosmos DB