Delen via

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 dat u rekening moet houden met verschillen tussen Apache Cassandra en Azure Cosmos DB. Als u bekend bent met systeemeigen Apache Cassandra, kan dit artikel u helpen de Azure Cosmos DB voor Apache Cassandra te gebruiken.

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 (Cassandra Query Language) v4 wire protocol, implementeert Azure Cosmos DB een eigen intern replicatieprotocol. U kunt het Cassandra-gossip-protocol niet gebruiken voor livemigratie of replicatie. Zie Live-migrate van Apache Cassandra naar de API voor Cassandra met behulp van dubbele schrijfbewerkingen voor meer informatie.

Zie Gegevens van Cassandra migreren 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. Een toewijzingsdocument vergelijkt Apache Cassandra en Azure Cosmos DB-benaderingen voor replicatieconsistentie. We raden u echter ten zeerste aan om de consistentie-instellingen van Azure Cosmos DB specifiek te bekijken of een korte videogids te bekijken voor informatie over 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 de blogpost-API voor Cassandra-aanbevelingen voor Java.

Codevoorbeelden

De API voor Cassandra is ontworpen om te werken met uw bestaande toepassingscode. Als u connectiviteitsgerelateerde fouten ondervindt, gebruikt u de quickstartvoorbeelden als uitgangspunt om kleine installatiewijzigingen 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 documentgeoriënteerde 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 replicatie van éé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 master of meerdere masters te configureren voor schrijfbewerkingen.

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

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 verwerken. U kunt Azure Cosmos DB configureren voor sterke consistentie tussen regio's in één configuratie van één schrijfregio . 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 API voor Cassandra-aanbevelingen voor Java-blog 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 de capaciteit uitgedrukt in CPU-kernen, RAM en IOPS. Azure Cosmos DB is een platform-as-a-service-database met meerdere tenants. De capaciteit wordt uitgedrukt met behulp van één genormaliseerde metriek die aanvraageenheden wordt genoemd. Elke aanvraag die naar de database wordt verzonden, heeft een kosten voor aanvraageenheden (RU-kosten). Elke aanvraag kan worden geprofileerd om de kosten te bepalen.

Het voordeel van het gebruik van aanvraageenheden als metrische waarde 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 met deze manier van inrichten van capaciteit is dat u een goed beeld moet hebben van de doorvoerkenmerken van uw workload.

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

Modellen voor capaciteitsinrichting

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

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

Partitionering

Partitionering in Azure Cosmos DB is vergelijkbaar met partitionering in Apache Cassandra. Een van de belangrijkste verschillen is dat Azure Cosmos DB beter is geoptimaliseerd voor horizontale schaalaanpassing. In Azure Cosmos DB worden limieten geplaatst voor de hoeveelheid verticale doorvoercapaciteit die beschikbaar is in elke fysieke partitie. Het effect van deze optimalisatie is het meest merkbaar wanneer een bestaand gegevensmodel aanzienlijke scheeftrekken van doorvoer heeft.

Voer stappen uit 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 u nieuwe knooppunten toevoegen aan een cluster en ervoor 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 op fysieke machines vindt plaats wanneer fysieke opslag of vereiste doorvoer limieten bereikt die zijn toegestaan voor een logische of fysieke partitie. Zie Partitionering in Azure Cosmos DB voor Apache Cassandra voor meer informatie.

Snelheidsbeperking

Een uitdaging van het inrichten van aanvraageenheden, met name als u ingerichte doorvoer gebruikt, is snelheidsbeperking. Azure Cosmos DB retourneert frequentiebeperkingen als clients meer resources verbruiken dan de hoeveelheid die u hebt ingericht. De API voor Cassandra in Azure Cosmos DB vertaalt deze uitzonderingen op overbelaste fouten in het systeemeigen Cassandra-protocol. Zie Frequentiebeperkingsfouten 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 hun gegevens op te vragen voor analytische en gegevensverplaatsingsbehoeften. U kunt op dezelfde manier verbinding maken met de API voor Cassandra en met dezelfde connector. Voordat u verbinding maakt met de API voor Cassandra, raadpleegt u Verbinding maken met Azure Cosmos DB voor Apache Cassandra vanuit Spark. Zie in het bijzonder 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