Aanpassen aan Azure Cosmos DB voor Apache Cassandra als u afkomstig bent van Apache Cassandra

  • Artikel

VAN TOEPASSING OP: Cassandra

Azure Cosmos DB voor Apache Cassandra biedt compatibiliteit met wire-protocollen met bestaande Cassandra-SDK's en hulpprogramma's. U kunt toepassingen uitvoeren die zijn ontworpen om verbinding te maken met Apache Cassandra met behulp van de API voor Cassandra met minimale wijzigingen.

Wanneer u de API voor Cassandra gebruikt, is het belangrijk om rekening te houden met de verschillen tussen Apache Cassandra en Azure Cosmos DB. Als u bekend bent met systeemeigen Apache Cassandra, kan dit artikel u helpen bij het gebruik van Azure Cosmos DB voor Apache Cassandra.

Functieondersteuning

De API voor Cassandra ondersteunt een groot aantal Apache Cassandra-functies. Sommige functies worden niet ondersteund of ze hebben beperkingen. Voordat u migreert, moet u ervoor zorgen dat de azure Cosmos DB voor Apache Cassandra-functies die u nodig hebt, worden ondersteund.

Replicatie

Wanneer u replicatie plant, is het belangrijk om te kijken naar zowel migratie als consistentie.

Hoewel u kunt communiceren met de API voor Cassandra via het binaire CQL-protocol v4-wire-protocol (Cassandra Query Language), implementeert Azure Cosmos DB een eigen intern replicatieprotocol. U kunt het Cassandra Gossip-protocol niet gebruiken voor livemigratie of replicatie. Zie Live migreren van Apache Cassandra naar de API voor Cassandra met behulp van dubbele schrijfbewerkingen voor meer informatie.

Zie Gegevens migreren van Cassandra naar een Azure Cosmos DB voor Apache Cassandra-account met behulp van Azure Databricks voor informatie over offlinemigratie.

Hoewel de benaderingen voor replicatieconsistentie in Apache Cassandra en Azure Cosmos DB vergelijkbaar zijn, is het belangrijk om te begrijpen hoe ze verschillen. In een toewijzingsdocument worden Apache Cassandra- en Azure Cosmos DB-benaderingen voor replicatieconsistentie vergeleken. We raden u echter ten zeerste aan om de consistentie-instellingen van Azure Cosmos DB specifiek te bekijken of een korte videogids te bekijken om inzicht te krijgen in de consistentie-instellingen in het Azure Cosmos DB-platform.

Wanneer u de API voor Cassandra gebruikt, hoeft u geen aanzienlijke codewijzigingen aan te brengen in bestaande toepassingen waarop Apache Cassandra wordt uitgevoerd. We raden enkele benaderingen en configuratie-instellingen aan voor de API voor Cassandra in Azure Cosmos DB. Bekijk het blogbericht API voor Cassandra-aanbevelingen voor Java.

Codevoorbeelden

De API voor Cassandra is ontworpen om te werken met uw bestaande toepassingscode. Als er connectiviteitsfouten optreden, gebruikt u de quickstart-voorbeelden als uitgangspunt om kleine configuratiewijzigingen te detecteren die u mogelijk moet aanbrengen in uw bestaande code.

We hebben ook uitgebreidere voorbeelden voor Java v3 - en Java v4-stuurprogramma's . Deze codevoorbeelden implementeren aangepaste extensies, die op hun beurt aanbevolen clientconfiguraties implementeren.

U kunt ook voorbeelden gebruiken voor Java Spring Boot (v3-stuurprogramma) en Java Spring Boot (v4-stuurprogramma).

Storage

De API voor Cassandra wordt ondersteund door Azure Cosmos DB, een documentgerichte NoSQL-database-engine. Azure Cosmos DB onderhoudt metagegevens, wat kan leiden tot een wijziging in de hoeveelheid fysieke opslag die nodig is voor een specifieke workload.

Het verschil in opslagvereisten tussen systeemeigen Apache Cassandra en Azure Cosmos DB is het meest merkbaar in kleine rijen. In sommige gevallen kan het verschil worden verschoven omdat Azure Cosmos DB geen compressie of tombstones implementeert. Deze factor is aanzienlijk afhankelijk van de workload. Als u niet zeker weet wat de opslagvereisten zijn, raden we u aan eerst een proof-of-concept te maken.

Implementatie in meerdere regio's

Systeemeigen Apache Cassandra is standaard een systeem met meerdere masters. Apache Cassandra heeft geen optie voor één master met replicatie in meerdere regio's voor alleen-lezen. Het concept van failover op toepassingsniveau naar een andere regio voor schrijfbewerkingen is redundant in Apache Cassandra. Alle knooppunten zijn onafhankelijk en er is geen Single Point of Failure. Azure Cosmos DB biedt echter de out-of-box mogelijkheid om regio's met één of meerdere masters te configureren voor schrijfbewerkingen.

Een voordeel van een regio met één hoofd voor schrijfbewerkingen is het voorkomen van conflictscenario's tussen regio's. Het biedt u de mogelijkheid om sterke consistentie in meerdere regio's te behouden met behoud van een niveau van hoge beschikbaarheid.

Notitie

Sterke consistentie tussen regio's en een RPO (Recovery Point Objective) van nul is niet mogelijk voor systeemeigen Apache Cassandra omdat alle knooppunten schrijfbewerkingen kunnen uitvoeren. U kunt Azure Cosmos DB configureren voor sterke consistentie tussen regio's in één schrijfregioconfiguratie . Net als bij systeemeigen Apache Cassandra kunt u echter geen Azure Cosmos DB-account configureren dat is geconfigureerd met meerdere schrijfregio's voor sterke consistentie. Een gedistribueerd systeem kan geen RPO van nul en een RTO (Recovery Time Objective) van nul bieden.

Zie Taakverdelingsbeleid in onze blog API voor Cassandra-aanbevelingen voor Java voor meer informatie. Zie ook Failoverscenario's in ons officiële codevoorbeeld voor het Cassandra Java v4-stuurprogramma.

Aanvraageenheden

Een van de belangrijkste verschillen tussen het uitvoeren van een systeemeigen Apache Cassandra-cluster en het inrichten van een Azure Cosmos DB-account is hoe databasecapaciteit wordt ingericht. In traditionele databases wordt capaciteit uitgedrukt in CPU-kernen, RAM en IOPS. Azure Cosmos DB is een platform-as-a-service-database met meerdere tenants. Capaciteit wordt uitgedrukt met behulp van één genormaliseerd metrisch gegeven, aanvraageenheden genoemd. Elke aanvraag die naar de database wordt verzonden, heeft een aanvraageenheid (RU-kosten). Elke aanvraag kan worden geprofileerd om de kosten te bepalen.

Het voordeel van het gebruik van aanvraageenheden als metrisch gegeven is dat databasecapaciteit deterministisch kan worden ingericht voor zeer voorspelbare prestaties en efficiëntie. Nadat u de kosten van elke aanvraag hebt geprofilleerd, kunt u aanvraageenheden gebruiken om het aantal aanvragen dat naar de database wordt verzonden, rechtstreeks te koppelen aan de capaciteit die u moet inrichten. De uitdaging bij deze manier van het inrichten van capaciteit is dat u een goed begrip moet hebben van de doorvoerkenmerken van uw workload.

We raden u ten zeerste aan uw aanvragen te profilen. Gebruik deze informatie om een schatting te maken van het aantal aanvraageenheden dat u moet inrichten. Hier volgen enkele artikelen die u kunnen helpen bij het maken van een schatting:

Modellen voor capaciteitsinrichting

Bij traditionele database-inrichting wordt vooraf een vaste capaciteit ingericht om de verwachte doorvoer te verwerken. Azure Cosmos DB biedt een model op basis van capaciteit met de naam ingerichte doorvoer. Als een service met meerdere tenants biedt Azure Cosmos DB ook modellen op basis van verbruik in de modus voor automatisch schalen en de serverloze modus. De mate waarin een workload kan profiteren van een van deze op verbruik gebaseerde inrichtingsmodellen, is afhankelijk van de voorspelbaarheid van de doorvoer voor de workload.

Over het algemeen profiteren werkbelastingen met een vaste status met voorspelbare doorvoer het meest van ingerichte doorvoer. Workloads met grote perioden van ruststand profiteren van de serverloze modus. Workloads met een continu niveau van minimale doorvoer, maar met onvoorspelbare pieken, profiteren het meest van de modus voor automatisch schalen. We raden u aan de volgende artikelen te lezen voor een duidelijk inzicht in het beste capaciteitsmodel voor uw doorvoerbehoeften:

Partitionering

Partitioneren in Azure Cosmos DB is vergelijkbaar met partitioneren in Apache Cassandra. Een van de belangrijkste verschillen is dat Azure Cosmos DB beter is geoptimaliseerd voor horizontale schaal. In Azure Cosmos DB worden limieten gesteld voor de hoeveelheid verticale doorvoercapaciteit die beschikbaar is in een fysieke partitie. Het effect van deze optimalisatie is het meest merkbaar wanneer een bestaand gegevensmodel aanzienlijke doorvoerscheefheid heeft.

Neem stappen om ervoor te zorgen dat het ontwerp van uw partitiesleutel resulteert in een relatief uniforme distributie van aanvragen. Zie Partitionering in Azure Cosmos DB voor Apache Cassandra voor meer informatie over hoe logische en fysieke partitionering werkt en limieten voor doorvoercapaciteit per partitie.

Schalen

In systeemeigen Apache Cassandra moet de capaciteit en schaal worden verhoogd door nieuwe knooppunten aan een cluster toe te voegen en ervoor te zorgen dat de knooppunten correct worden toegevoegd aan de Cassandra-ring. In Azure Cosmos DB is het toevoegen van knooppunten transparant en automatisch. Schalen is een functie van het aantal aanvraageenheden dat is ingericht voor uw keyspace of tabel. Schalen van fysieke machines vindt plaats wanneer fysieke opslag of vereiste doorvoer de limieten bereikt die zijn toegestaan voor een logische of een fysieke partitie. Zie Partitionering in Azure Cosmos DB voor Apache Cassandra voor meer informatie.

Snelheidsbeperking

Een uitdaging bij het inrichten van aanvraageenheden, met name als u ingerichte doorvoer gebruikt, is snelheidsbeperking. Azure Cosmos DB retourneert fouten met een frequentielimiet als clients meer resources verbruiken dan de hoeveelheid die u hebt ingericht. De API voor Cassandra in Azure Cosmos DB vertaalt deze uitzonderingen naar overbelaste fouten in het systeemeigen Cassandra-protocol. Zie Fouten met snelheidsbeperking voorkomen voor Azure Cosmos DB voor Apache Cassandra-bewerkingen voor informatie over het voorkomen van snelheidsbeperking in uw toepassing.

Apache Spark-connector

Veel Apache Cassandra-gebruikers gebruiken de Apache Spark Cassandra-connector om query's uit te voeren op hun gegevens voor analytische en gegevensverplaatsingsbehoeften. U kunt op dezelfde manier en met dezelfde connector verbinding maken met de API voor Cassandra. Voordat u verbinding maakt met de API voor Cassandra, raadpleegt u Verbinding maken met Azure Cosmos DB voor Apache Cassandra vanuit Spark. Zie met name de sectie Doorvoerconfiguratie van Spark-connector optimaliseren.

Algemene problemen

Zie Veelvoorkomende problemen in Azure Cosmos DB voor Apache Cassandra oplossen voor oplossingen voor veelvoorkomende problemen.

Volgende stappen