Share via

Come adattarsi ad Azure Cosmos DB per Apache Cassandra se si proviene da Apache Cassandra

  • Articolo

SI APPLICA A: Cassandra

Azure Cosmos DB per Apache Cassandra offre la compatibilità del protocollo di rete con gli SDK e gli strumenti Cassandra esistenti. È possibile eseguire applicazioni progettate per connettersi ad Apache Cassandra usando l'API per Cassandra con modifiche minime.

Quando si usa l'API per Cassandra, è importante tenere presente le differenze tra Apache Cassandra e Azure Cosmos DB. Se si ha familiarità con Apache Cassandra nativo, questo articolo consente di iniziare a usare Azure Cosmos DB per Apache Cassandra.

Supporto funzionalità

L'API per Cassandra supporta un numero elevato di funzionalità di Apache Cassandra. Alcune funzionalità non sono supportate o hanno limitazioni. Prima di eseguire la migrazione, assicurarsi che siano supportate le funzionalità di Azure Cosmos DB per Apache Cassandra .

Replica

Quando si pianifica la replica, è importante esaminare sia la migrazione che la coerenza.

Anche se è possibile comunicare con l'API per Cassandra tramite il protocollo binario Cassandra Query Language (CQL) v4 wire protocol, Azure Cosmos DB implementa il proprio protocollo di replica interno. Non è possibile usare il protocollo gossip Cassandra per la migrazione in tempo reale o la replica. Per altre informazioni, vedere Live-migrate da Apache Cassandra all'API per Cassandra usando due scritture.

Per informazioni sulla migrazione offline, vedere Eseguire la migrazione dei dati da Cassandra a un account Azure Cosmos DB per Apache Cassandra usando Azure Databricks.

Anche se gli approcci alla coerenza della replica in Apache Cassandra e Azure Cosmos DB sono simili, è importante comprendere come sono diversi. Un documento di mapping confronta gli approcci di Apache Cassandra e Azure Cosmos DB alla coerenza della replica. È tuttavia consigliabile esaminare in modo specifico le impostazioni di coerenza di Azure Cosmos DB o guardare una breve guida video per comprendere le impostazioni di coerenza nella piattaforma Azure Cosmos DB.

Quando si usa l'API per Cassandra, non è necessario apportare modifiche sostanziali al codice alle applicazioni esistenti che eseguono Apache Cassandra. È consigliabile usare alcuni approcci e impostazioni di configurazione per l'API per Cassandra in Azure Cosmos DB. Esaminare l'API del post di blog per le raccomandazioni cassandra per Java.

Esempi di codice

L'API per Cassandra è progettata per usare il codice dell'applicazione esistente. Se si verificano errori correlati alla connettività, usare gli esempi di avvio rapido come punto di partenza per individuare le modifiche di configurazione secondarie che potrebbe essere necessario apportare nel codice esistente.

Sono disponibili anche esempi più approfonditi per i driver Java v3 e Java v4. Questi esempi di codice implementano estensioni personalizzate, che a loro volta implementano configurazioni client consigliate.

È anche possibile usare esempi per Java Spring Boot (driver v3) e Java Spring Boot (driver v4).

Archiviazione

L'API per Cassandra è supportata da Azure Cosmos DB, che è un motore di database NoSQL orientato al documento. Azure Cosmos DB gestisce i metadati, che potrebbero causare una modifica della quantità di archiviazione fisica necessaria per un carico di lavoro specifico.

La differenza tra i requisiti di archiviazione tra Apache Cassandra nativo e Azure Cosmos DB è più evidente nelle dimensioni di riga ridotte. In alcuni casi, la differenza potrebbe essere offset perché Azure Cosmos DB non implementa la compattazione o le pietre tombali. Questo fattore dipende in modo significativo dal carico di lavoro. Se si è incerti sui requisiti di archiviazione, è consigliabile prima creare una prova del concetto.

Distribuzione in più aree

Native Apache Cassandra è un sistema multi master per impostazione predefinita. Apache Cassandra non dispone di un'opzione per la replica single-master con replica a più aree solo per le letture. Il concetto di failover a livello di applicazione in un'altra area per le scritture è ridondante in Apache Cassandra. Tutti i nodi sono indipendenti e non esiste un singolo punto di errore. Azure Cosmos DB offre tuttavia la possibilità di configurare aree a master singolo o multi master per le scritture.

Un vantaggio di avere un'area master singola per le scritture evita scenari di conflitto tra aree. Offre l'opzione per mantenere una coerenza forte tra più aree mantenendo un livello di disponibilità elevata.

Nota

La coerenza forte tra aree e un obiettivo del punto di ripristino (RPO) di zero non è possibile per Apache Cassandra nativo perché tutti i nodi sono in grado di gestire le scritture. È possibile configurare Azure Cosmos DB per una coerenza forte tra aree in una singola configurazione dell'area di scrittura . Tuttavia, come con Apache Cassandra nativo, non è possibile configurare un account Azure Cosmos DB configurato con più aree di scrittura per una coerenza complessa. Un sistema distribuito non può fornire un RPO pari a zero e un RTO (Recovery Time Objective) pari a zero.

Per altre informazioni, vedere Criteri di bilanciamento del cariconell'API per i consigli di Cassandra per Java. Vedere anche scenari di failovernell'esempio di codice ufficiale per il driver Cassandra Java v4.

Unità richiesta

Una delle principali differenze tra l'esecuzione di un cluster Apache Cassandra nativo e il provisioning di un account Azure Cosmos DB è il provisioning della capacità del database. Nei database tradizionali la capacità è espressa in termini di core CPU, RAM e operazioni di I/O al secondo. Azure Cosmos DB è un database multi-tenant come servizio. La capacità viene espressa usando una singola metrica normalizzata denominata unità richiesta. Ogni richiesta inviata al database ha un costo dell'unità richiesta (costo UR). Ogni richiesta può essere profilata per determinare il costo.

Il vantaggio dell'uso di unità richiesta come metrica è che la capacità del database può essere eseguita deterministicamente per prestazioni e efficienza altamente prevedibili. Dopo aver profilato il costo di ogni richiesta, è possibile usare le unità richiesta per associare direttamente il numero di richieste inviate al database con la capacità di cui è necessario effettuare il provisioning. La sfida con questo modo di provisioning della capacità è che è necessario avere una solida comprensione delle caratteristiche della velocità effettiva del carico di lavoro.

È consigliabile profilarti le tue richieste. Usare queste informazioni per stimare il numero di unità di richiesta che sarà necessario effettuare il provisioning. Ecco alcuni articoli che possono aiutare a fare la stima:

Modelli di provisioning della capacità

Nel provisioning del database tradizionale viene effettuato il provisioning di una capacità fissa per gestire la velocità effettiva prevista. Azure Cosmos DB offre un modello basato sulla capacità denominato velocità effettiva con provisioning. Come servizio multi-tenant, Azure Cosmos DB offre anche modelli basati su consumo in modalità di scalabilità automatica e modalità serverless . La misura in cui un carico di lavoro può trarre vantaggio da uno di questi modelli di provisioning basati su consumo dipende dalla stima della velocità effettiva per il carico di lavoro.

In generale, i carichi di lavoro a stato costante con velocità effettiva prevedibile possono trarre vantaggio dalla velocità effettiva di cui è stato effettuato il provisioning. I carichi di lavoro con grandi periodi di dormancy possono trarre vantaggio dalla modalità serverless. I carichi di lavoro con un livello continuo di velocità effettiva minima, ma con picchi imprevedibili, traggono vantaggio dalla modalità di scalabilità automatica. È consigliabile esaminare gli articoli seguenti per una chiara comprensione del modello di capacità migliore per le esigenze di velocità effettiva:

Partizionamento

Il partizionamento in Azure Cosmos DB è simile al partizionamento in Apache Cassandra. Una delle principali differenze è che Azure Cosmos DB è più ottimizzato per la scalabilità orizzontale. In Azure Cosmos DB i limiti vengono inseriti nella quantità di capacità di velocità effettiva verticale disponibile in qualsiasi partizione fisica. L'effetto di questa ottimizzazione è più evidente quando un modello di dati esistente ha una notevole deviazione della velocità effettiva.

Seguire questa procedura per assicurarsi che la progettazione della chiave di partizione comporti una distribuzione relativamente uniforme delle richieste. Per altre informazioni sul funzionamento del partizionamento logico e fisico e sui limiti della capacità effettiva per partizione, vedere Partizionamento in Azure Cosmos DB per Apache Cassandra.

Scalabilità

In Apache Cassandra nativo, l'aumento della capacità e della scalabilità comporta l'aggiunta di nuovi nodi a un cluster e la garanzia che i nodi vengano aggiunti correttamente all'anello Cassandra. In Azure Cosmos DB aggiungere nodi è trasparente e automatico. Il ridimensionamento è una funzione del numero di unità richieste di cui viene effettuato il provisioning per il keyspace o la tabella. Il ridimensionamento nei computer fisici si verifica quando l'archiviazione fisica o la velocità effettiva necessaria raggiunge i limiti consentiti per una partizione logica o fisica. Per altre informazioni, vedere Partizionamento in Azure Cosmos DB per Apache Cassandra.

Limitazione della frequenza

Una sfida di provisioning delle unità richieste, in particolare se si usa la velocità effettiva con provisioning, è la limitazione della velocità. Azure Cosmos DB restituisce errori limitati alla frequenza se i client usano più risorse rispetto alla quantità di cui è stato effettuato il provisioning. L'API per Cassandra in Azure Cosmos DB converte queste eccezioni in errori di overload nel protocollo nativo cassandra. Per informazioni su come evitare la limitazione della frequenza nell'applicazione, vedere Impedire errori di limitazione della frequenza per le operazioni di Azure Cosmos DB per Apache Cassandra.

Connettore Apache Spark

Molti utenti di Apache Cassandra usano il connettore Apache Spark Cassandra per eseguire query sui dati per le esigenze di spostamento di dati e analitici. È possibile connettersi all'API per Cassandra nello stesso modo e usando lo stesso connettore. Prima di connettersi all'API per Cassandra, vedere Connettersi ad Azure Cosmos DB per Apache Cassandra da Spark. In particolare, vedere la sezione Ottimizzare la configurazione della velocità effettiva del connettore Spark.

Risolvere i problemi comuni

Per le soluzioni ai problemi comuni, vedere Risolvere i problemi comuni in Azure Cosmos DB per Apache Cassandra.

Passaggi successivi