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à dei protocolli di collegamento 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 il sistema Apache Cassandra nativo, questo articolo può essere utile per 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 tuttavia sono supportate o presentano delle limitazioni. Prima di eseguire la migrazione, assicurarsi che siano supportate le funzionalità di Azure Cosmos DB per Apache Cassandra necessarie.

Replica

Quando si pianifica la replica, è importante prendere in considerazione sia la migrazione sia la coerenza.

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

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 di replica in Apache Cassandra e Azure Cosmos DB sono simili, è importante comprendere in che cosa differiscono. In un documento di mapping vengono messi a confronto gli approcci di Apache Cassandra e Azure Cosmos DB alla coerenza di 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 del codice alle applicazioni esistenti che eseguono Apache Cassandra. Per l'API per Cassandra in Azure Cosmos DB sono consigliabili alcuni approcci e impostazioni di configurazione. Vedere il post di blog Consigli per l’API per Cassandra per Java.

Esempi di codice

L'API per Cassandra è progettata per funzionare con il codice dell'applicazione esistente. Se si verificano errori correlati alla connettività, usare gli esempi di avvio rapido come punto di partenza per individuare 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 le configurazioni client consigliate.

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

Storage

L'API per Cassandra è supportata da Azure Cosmos DB, un motore di database NoSQL orientato ai documenti. Azure Cosmos DB gestisce i metadati, il che potrebbe comportare una modifica della quantità di archiviazione fisica necessaria per un carico di lavoro specifico.

La differenza dei requisiti di archiviazione tra Apache Cassandra nativo e Azure Cosmos DB è più evidente nelle dimensioni di riga di piccole dimensioni. In alcuni casi, la differenza potrebbe essere compensata perché Azure Cosmos DB non implementa la compattazione o la rimozione definitiva. Questo fattore dipende principalmente dal carico di lavoro. In caso di dubbi sui requisiti di archiviazione, è consigliabile creare prima un modello di verifica.

Distribuzione in più aree

Apache Cassandra nativo è un sistema multimaster per impostazione predefinita. Apache Cassandra non ha un'opzione per la replica a master singolo con più aree solo per le operazioni di lettura. 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. Al contrario, Azure Cosmos DB offre la possibilità predefinita di configurare aree a master singolo o multimaster per le operazioni di scrittura.

Uno dei vantaggi di avere un'area a master singolo per le operazioni di scrittura è quello di evitare scenari di conflitto tra aree. È possibile mantenere una coerenza Strong tra più aree mantenendo al contempo un livello di disponibilità elevata.

Nota

La coerenza Strong tra aree e un obiettivo del punto di ripristino (RPO) pari a zero non sono possibili per Apache Cassandra nativo perché tutti i nodi sono in grado di gestire operazioni di scrittura. È possibile configurare Azure Cosmos DB per una coerenza di alto livello tra aree in una configurazione con singola area di scrittura. Tuttavia, come con Apache Cassandra nativo, non è possibile configurare un account Azure Cosmos DB configurato con più aree di scrittura per coerenza di alto livello. Un sistema distribuito non può fornire un RPO pari a zero e un obiettivo del tempo di ripristino (RTO) pari a zero.

Per altre informazioni, vedere criteri di bilanciamento del carico nell'API per i consià di Cassandra per Java. Vedere anche Scenari di failover nell'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 è data dalla modalità di 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 PaaS (Platform-as-a-Service) multi-tenant. La capacità viene espressa con una singola metrica normalizzata denominata unità richiesta. Tutte le richieste inviate al database hanno un costo di unità richiesta (costo UR). Ogni richiesta può essere profilata per determinarne il costo.

Il vantaggio offerto dall'uso delle unità richiesta come metrica è dato dalla possibilità di effettuare il provisioning della capacità del database in modo deterministico per ottenere prestazioni ed 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 alla capacità di cui è necessario effettuare il provisioning. La sfida che pone questa modalità di provisioning della capacità consiste nella necessità di conoscere in maniera approfondita le caratteristiche della velocità effettiva del carico di lavoro.

È altamente consigliabile profilare le richieste. Usare queste informazioni per stimare il numero di unità richiesta di cui sarà necessario effettuare il provisioning. Ecco alcuni articoli che possono essere utili per effettuare la stima:

Modelli di provisioning della capacità

Nel provisioning di database tradizionale, per gestire la velocità effettiva prevista viene effettuato il provisioning di una capacità fissa. 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 sul consumo in modalità scalabilità automatica e in modalità serverless. La misura in cui un carico di lavoro può trarre vantaggio da uno di questi modelli di provisioning basati sul consumo dipende dalla prevedibilità della velocità effettiva per il carico di lavoro.

In generale, i carichi di lavoro con stato stabile e velocità effettiva prevedibile traggono vantaggio dalla velocità effettiva con provisioning. I carichi di lavoro con grandi periodi di inattività beneficiano della modalità serverless. I carichi di lavoro con un livello continuo di velocità effettiva minima, ma con picchi imprevedibili, si avvalgono principalmente della modalità di scalabilità automatica. Per una chiara comprensione del modello di capacità migliore per le proprie esigenze di velocità effettiva è consigliabile esaminare gli articoli seguenti:

Partizionamento

Il partizionamento in Azure Cosmos DB è simile a quello in Apache Cassandra. Una delle principali differenze è che Azure Cosmos DB è più ottimizzato per la scalabilità orizzontale. In Azure Cosmos DB vengono applicati limiti alla capacità di velocità effettiva verticale disponibile in qualsiasi partizione fisica. L'effetto di questa ottimizzazione è più evidente quando un modello di dati esistente presenta un'asimmetria significativa della velocità effettiva.

Adottare misure per assicurarsi che la progettazione delle chiavi di partizione preveda una distribuzione relativamente uniforme delle richieste. Per altre informazioni sul funzionamento del partizionamento logico e fisico e sui limiti della capacità di velocità 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 verifica che i nodi vengano aggiunti correttamente all'anello Cassandra. In Azure Cosmos DB l'aggiunta di nodi è trasparente e automatica. Il ridimensionamento è una funzione del numero di unità richiesta 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 del provisioning di unità richiesta, soprattutto se si usa velocità effettiva con provisioning, è data dalla limitazione della frequenza. Azure Cosmos DB restituisce errori di limitazione della frequenza se i client utilizzano 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 per il protocollo nativo di 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 propri dati per esigenze di analisi e di spostamento dei dati. È possibile connettersi all'API per Cassandra allo 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 soluzioni ai problemi comuni, vedere Risolvere i problemi comuni in Azure Cosmos DB per Apache Cassandra.

Passaggi successivi