Come adeguarsi ad Azure Cosmos DB for Apache Cassandra se si proviene da Apache Cassandra

  • Si applica a: ✅ Apache Cassandra

SI APPLICA A: Cassandra

Importante

Si sta cercando una soluzione di database per scenari su larga scala con un contratto di servizio di disponibilità 99.999%, scalabilità automatica immediata e failover automatico in più aree? Prendere in considerazione Azure Cosmos DB per NoSQL.

Si sta cercando di eseguire la migrazione di un'applicazione Apache Cassandra esistente? Prendere in considerazione Azure Istanza gestita per Apache Cassandra.

Azure Cosmos DB for 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 for Apache Cassandra.

Supporto delle funzionalità

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

Duplicazione

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 collegamento binario CQL (Cassandra Query Language) v4, in Azure Cosmos DB viene implementato un protocollo di replica interno. Non è possibile usare il protocollo gossip di 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 for Apache Cassandra usando Azure Databricks.

Sebbene gli approcci alla coerenza di replica in Apache Cassandra e in Azure Cosmos DB siano simili, è importante comprenderne le differenze. In un documento di mapping vengono messi a confronto gli approcci di Apache Cassandra e di Azure Cosmos DB alla coerenza di replica. È tuttavia consigliabile esaminare in modo specifico le impostazioni di coerenza di Azure Cosmos DB o guardare un breve 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 si consigliano alcuni approcci e impostazioni di configurazione. Vedere il post di blog Consigli per l'API per Cassandra in Java.

Esempi di codice

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

Sono disponibili anche esempi più approfonditi per i driver Java v3 e Java v4. Tali 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, operazione che potrebbe comportare una modifica della quantità di archiviazione fisica necessaria per un carico di lavoro specifico.

La differenza nei requisiti di archiviazione tra Apache Cassandra nativo e Azure Cosmos DB è più evidente nelle dimensioni ridotte delle righe. In alcuni casi, la differenza potrebbe essere compensata perché in Azure Cosmos DB non vengono implementate né la compattazione né 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 il master singolo con la replica in 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 della presenza di un'area a master singolo per le operazioni di scrittura è la possibilità di evitare scenari di conflitto tra aree. È infatti possibile avere una coerenza assoluta tra più aree mantenendo al contempo un livello di disponibilità elevata.

Annotazioni

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

Per altre informazioni, vedere criteri di bilanciamento del carico nel blog sulle raccomandazioni per API per Cassandra in Java. Vedere anche gli scenari di failover nell'esempio di codice ufficiale per il driver Cassandra Java v4.

Unità richiesta

Una delle differenze principali tra l'esecuzione di un cluster Apache Cassandra nativo e il provisioning di un account Azure Cosmos DB è la 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. Ogni richiesta inviata al database ha 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 è la possibilità di effettuare il provisioning della capacità del database in modo deterministico al fine di 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. Il problema legato a questa modalità di provisioning della capacità è la necessità di conoscere in maniera approfondita le caratteristiche della velocità effettiva del carico di lavoro.

È 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 in anticipo il provisioning di una capacità fissa. In Azure Cosmos DB è disponibile 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à di scalabilità automatica e in modalità serverless. La misura in cui un carico di lavoro può trarre vantaggio da uno dei 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. Per i carichi di lavoro con grandi periodi di inattività è preferibile la modalità serverless. I carichi di lavoro con un livello continuo di velocità effettiva minima, ma con picchi imprevedibili, traggono vantaggio principalmente della modalità di scalabilità automatica. Per comprendere meglio il modello di capacità più adatto alle proprie esigenze di velocità effettiva, è consigliabile vedere gli articoli seguenti:

Partitioning

In Azure Cosmos DB il partizionamento è analogo a quello in Apache Cassandra. Una delle differenze principali consiste nel fatto che Azure Cosmos DB è ottimizzato meglio 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 le misure necessarie per garantire 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 for Apache Cassandra.

Scaling

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. Nei computer fisici, il ridimensionamento viene applicato 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 for Apache Cassandra.

Limitazione del tasso

Una problematica legata al provisioning di unità richiesta, soprattutto se si usa la 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 al valore 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 for 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 dati. È possibile connettersi all'API per Cassandra in modo analogo e usando lo stesso connettore. Prima di connettersi all'API per Cassandra, vedere Connettersi ad Azure Cosmos DB for 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 for Apache Cassandra.

Passaggi successivi

  • Last updated on