Dela via

Så här anpassar du dig till Azure Cosmos DB för Apache Cassandra om du kommer från Apache Cassandra

  • Artikel

GÄLLER FÖR: Kassandra

Azure Cosmos DB för Apache Cassandra tillhandahåller trådprotokollkompatibilitet med befintliga Cassandra-SDK:er och verktyg. Du kan köra program som är utformade för att ansluta till Apache Cassandra med hjälp av API:et för Cassandra med minimala ändringar.

När du använder API:et för Cassandra är det viktigt att vara medveten om skillnaderna mellan Apache Cassandra och Azure Cosmos DB. Om du är bekant med den inbyggda Apache Cassandra kan den här artikeln hjälpa dig att börja använda Azure Cosmos DB för Apache Cassandra.

Funktionsstöd

API:et för Cassandra stöder ett stort antal Apache Cassandra-funktioner. Vissa funktioner stöds inte eller har begränsningar. Innan du migrerar måste du se till att funktionerna i Azure Cosmos DB för Apache Cassandra som du behöver stöds.

Replikering

När du planerar för replikering är det viktigt att titta på både migrering och konsekvens.

Även om du kan kommunicera med API:et för Cassandra via CQL-protokollet (Cassandra Query Language) v4 wire protocol implementerar Azure Cosmos DB ett eget internt replikeringsprotokoll. Du kan inte använda Cassandra-skvallerprotokollet för direktmigrering eller replikering. Mer information finns i Live-migrering från Apache Cassandra till API:et för Cassandra med hjälp av dubbla skrivningar.

Information om offlinemigrering finns i Migrera data från Cassandra till ett Azure Cosmos DB för Apache Cassandra-konto med hjälp av Azure Databricks.

Även om metoderna för replikeringskonsekvens i Apache Cassandra och Azure Cosmos DB är liknande är det viktigt att förstå hur de skiljer sig åt. Ett mappningsdokument jämför Apache Cassandra- och Azure Cosmos DB-metoder med replikeringskonsekvens. Vi rekommenderar dock starkt att du specifikt granskar konsekvensinställningarna för Azure Cosmos DB eller tittar på en kort videoguide för att förstå konsekvensinställningar på Azure Cosmos DB-plattformen.

När du använder API:et för Cassandra behöver du inte göra några större kodändringar i befintliga program som kör Apache Cassandra. Vi rekommenderar några metoder och konfigurationsinställningar för API:et för Cassandra i Azure Cosmos DB. Granska blogginläggs-API :et för Cassandra-rekommendationer för Java.

Kodexempel

API:et för Cassandra är utformat för att fungera med din befintliga programkod. Om du får anslutningsrelaterade fel använder du snabbstartsexemplen som utgångspunkt för att identifiera mindre installationsändringar som du kan behöva göra i din befintliga kod.

Vi har också mer djupgående exempel för Java v3 - och Java v4-drivrutiner . Dessa kodexempel implementerar anpassade tillägg, som i sin tur implementerar rekommenderade klientkonfigurationer.

Du kan också använda exempel för Java Spring Boot (v3-drivrutin) och Java Spring Boot (v4-drivrutin).

Storage

API:et för Cassandra backas upp av Azure Cosmos DB, som är en dokumentorienterad NoSQL-databasmotor. Azure Cosmos DB underhåller metadata, vilket kan leda till en ändring av mängden fysisk lagring som krävs för en viss arbetsbelastning.

Skillnaden i lagringskrav mellan inbyggda Apache Cassandra och Azure Cosmos DB är mest märkbar i små radstorlekar. I vissa fall kan skillnaden förskjutas eftersom Azure Cosmos DB inte implementerar komprimering eller gravstenar. Den här faktorn beror avsevärt på arbetsbelastningen. Om du är osäker på lagringskraven rekommenderar vi att du först skapar ett konceptbevis.

Distribution i flera regioner

Native Apache Cassandra är ett system med flera original som standard. Apache Cassandra har inte något alternativ för replikering med en enda huvudserver med replikering i flera regioner för skrivskyddade filer. Begreppet redundans på programnivå till en annan region för skrivningar är redundant i Apache Cassandra. Alla noder är oberoende och det finns ingen enskild felpunkt. Azure Cosmos DB ger dock den färdiga möjligheten att konfigurera antingen en master- eller flera huvudregioner för skrivningar.

En fördel med att ha en enda huvudregion för skrivningar är att undvika konfliktscenarier mellan regioner. Det ger dig möjlighet att upprätthålla stark konsekvens i flera regioner samtidigt som en hög tillgänglighetsnivå bibehålls.

Kommentar

Stark konsekvens mellan regioner och ett mål för återställningspunkt (RPO) med noll är inte möjligt för inbyggda Apache Cassandra eftersom alla noder kan hantera skrivningar. Du kan konfigurera Azure Cosmos DB för stark konsekvens mellan regioner i en enda konfiguration av skrivregionen . Men precis som med inbyggda Apache Cassandra kan du inte konfigurera ett Azure Cosmos DB-konto som har konfigurerats med flera skrivregioner för stark konsekvens. Ett distribuerat system kan inte tillhandahålla ett RPO på noll och ett mål för återställningstid (RTO) på noll.

Mer information finns i Belastningsutjämningsprincip i vår API för Cassandra-rekommendationer för Java-bloggen. Se även redundansscenarier i vårt officiella kodexempel för Cassandra Java v4-drivrutinen.

Enheter för programbegäran

En av de största skillnaderna mellan att köra ett inbyggt Apache Cassandra-kluster och etablera ett Azure Cosmos DB-konto är hur databaskapacitet etableras. I traditionella databaser uttrycks kapaciteten i termer av CPU-kärnor, RAM-minne och IOPS. Azure Cosmos DB är en plattform som en tjänstdatabas för flera klientorganisationer. Kapaciteten uttrycks med hjälp av ett enda normaliserat mått som kallas enheter för begäranden. Varje begäran som skickas till databasen har en enhetskostnad för begäran (RU-kostnad). Varje begäran kan profileras för att fastställa kostnaden.

Fördelen med att använda enheter för begäranden som mått är att databaskapaciteten kan etableras deterministiskt för mycket förutsägbara prestanda och effektivitet. När du har profilerar kostnaden för varje begäran kan du använda enheter för begäran för att direkt associera antalet begäranden som skickas till databasen med den kapacitet som du behöver etablera. Utmaningen med det här sättet att etablera kapacitet är att du måste ha en gedigen förståelse för arbetsbelastningens dataflödesegenskaper.

Vi rekommenderar starkt att du profilerar dina begäranden. Använd den informationen för att beräkna antalet enheter för begäranden som du behöver etablera. Här följer några artiklar som kan hjälpa dig att göra uppskattningen:

Kapacitetsetableringsmodeller

I traditionell databasetablering etableras en fast kapacitet i förväg för att hantera det förväntade dataflödet. Azure Cosmos DB erbjuder en kapacitetsbaserad modell som kallas etablerat dataflöde. Som en tjänst för flera innehavare erbjuder Azure Cosmos DB även förbrukningsbaserade modeller i autoskalningsläge och serverlöst läge. I vilken utsträckning en arbetsbelastning kan dra nytta av någon av dessa förbrukningsbaserade etableringsmodeller beror på arbetsbelastningens förutsägbarhet för dataflödet.

I allmänhet drar steady state-arbetsbelastningar som har förutsägbart dataflöde mest nytta av etablerat dataflöde. Arbetsbelastningar som har stora vilande perioder drar nytta av serverlöst läge. Arbetsbelastningar som har en kontinuerlig nivå av minimalt dataflöde, men med oförutsägbara toppar, drar mest nytta av autoskalningsläget. Vi rekommenderar att du läser följande artiklar för att få en tydlig förståelse för den bästa kapacitetsmodellen för dina dataflödesbehov:

Partitionering

Partitionering i Azure Cosmos DB liknar partitionering i Apache Cassandra. En av de största skillnaderna är att Azure Cosmos DB är mer optimerat för horisontell skalning. I Azure Cosmos DB begränsas mängden vertikal dataflödeskapacitet som är tillgänglig i alla fysiska partitioner. Effekten av den här optimeringen är mest märkbar när en befintlig datamodell har betydande skevt dataflöde.

Vidta åtgärder för att säkerställa att partitionsnyckeldesignen resulterar i en relativt enhetlig distribution av begäranden. Mer information om hur logisk och fysisk partitionering fungerar och gränser för dataflödeskapacitet per partition finns i Partitionering i Azure Cosmos DB för Apache Cassandra.

Skalning

I den interna Apache Cassandra innebär ökad kapacitet och skala att nya noder läggs till i ett kluster och att noderna läggs till korrekt i Cassandra-ringen. I Azure Cosmos DB är det transparent och automatiskt att lägga till noder. Skalning är en funktion av hur många enheter för begärande som etableras för nyckelområdet eller tabellen. Skalning i fysiska datorer sker när fysisk lagring eller nödvändigt dataflöde når de gränser som tillåts för en logisk eller fysisk partition. Mer information finns i Partitionering i Azure Cosmos DB för Apache Cassandra.

Frekvensbegränsning

En utmaning med att etablera enheter för begäranden, särskilt om du använder etablerat dataflöde, är hastighetsbegränsning. Azure Cosmos DB returnerar hastighetsbegränsade fel om klienter använder mer resurser än det belopp som du etablerade. API:et för Cassandra i Azure Cosmos DB översätter dessa undantag till överlagrade fel i det interna Cassandra-protokollet. Information om hur du undviker hastighetsbegränsning i ditt program finns i Förhindra hastighetsbegränsningsfel för Azure Cosmos DB för Apache Cassandra-åtgärder.

Apache Spark-anslutningsapp

Många Apache Cassandra-användare använder Apache Spark Cassandra-anslutningsappen för att fråga efter analys- och dataförflyttningsbehov. Du kan ansluta till API:et för Cassandra på samma sätt och med hjälp av samma anslutningsapp. Innan du ansluter till API:et för Cassandra läser du Anslut till Azure Cosmos DB för Apache Cassandra från Spark. Mer information finns i avsnittet Optimera konfiguration av Spark-anslutningsappens dataflöde.

Felsök vanliga problem

Lösningar på vanliga problem finns i Felsöka vanliga problem i Azure Cosmos DB för Apache Cassandra.

Nästa steg