Skala ett Azure Cosmos DB för Apache Cassandra-konto elastiskt

  • Artikel

GÄLLER FÖR: Cassandra

Det finns en mängd olika alternativ för att utforska den elastiska karaktären hos Azure Cosmos DB för Apache Cassandra. För att förstå hur du skalar effektivt i Azure Cosmos DB är det viktigt att förstå hur du etablerar rätt mängd enheter för programbegäran (RU/s) för att ta hänsyn till systemets prestandakrav. Mer information om enheter för programbegäran finns i artikeln enheter för programbegäran .

För API:et för Cassandra kan du hämta avgiften för enhet för programbegäran för enskilda frågor med hjälp av .NET- och Java-SDK:erna. Det här är användbart när du ska fastställa hur mycket RU/s du behöver etablera i tjänsten.

Databasåtgärder använder enheter för programbegäran

Hantering av hastighetsbegränsning (429-fel)

Azure Cosmos DB returnerar hastighetsbegränsade (429) fel om klienter förbrukar mer resurser (RU/s) än det belopp som du har etablerat. API:et för Cassandra i Azure Cosmos DB översätter dessa undantag till överbelastade fel i det inbyggda Cassandra-protokollet.

Om systemet inte är känsligt för svarstid kan det vara tillräckligt för att hantera dataflödesbegränsningen med hjälp av återförsök. Se Java-kodexempel för version 3 och version 4 av Apache Cassandra Java-drivrutiner för att hantera hastighetsbegränsning transparent. De här exemplen implementerar en anpassad version av cassandra-standardprincipen för återförsök i Java. Du kan också använda Spark-tillägget för att hantera hastighetsbegränsning. När du använder Spark följer du vår vägledning om hur du optimerar dataflödeskonfigurationen för Spark-anslutningsappen.

Hantera skalning

Om du behöver minimera svarstiden finns det ett spektrum av alternativ för att hantera skalnings- och etableringsdataflöde (RU:er) i API:et för Cassandra:

I följande avsnitt förklaras för- och nackdelarna med varje metod. Du kan sedan välja den bästa strategin för att balansera systemets skalningsbehov, den totala kostnaden och effektivitetsbehoven för din lösning.

Använda Azure-portalen

Du kan skala resurserna i Azure Cosmos DB för Apache Cassandra-kontot med hjälp av Azure Portal. Mer information finns i artikeln Om att etablera dataflöde för containrar och databaser. Den här artikeln förklarar de relativa fördelarna med att ange dataflöde på databas- eller containernivå i Azure Portal. Termerna "database" och "container" som nämns i de här artiklarna mappar till "keyspace" respektive "table" för API:et för Cassandra.

Fördelen med den här metoden är att det är ett enkelt nyckelfärdigt sätt att hantera dataflödeskapacitet i databasen. Nackdelen är dock att din skalningsmetod i många fall kan kräva att vissa automatiseringsnivåer är både kostnadseffektiva och högpresterande. I nästa avsnitt beskrivs relevanta scenarier och metoder.

Använda kontrollplanet

Med Azure Cosmos DB:s API för Cassandra kan du justera dataflödet programmatiskt med hjälp av våra olika kontrollplansfunktioner. Vägledning och exempel finns i artiklarna om Azure Resource Manager, PowerShell och Azure CLI.

Fördelen med den här metoden är att du kan automatisera upp- eller nedskalningen av resurser baserat på en timer för att ta hänsyn till hög aktivitet eller perioder med låg aktivitet. Ta en titt på vårt exempel här för hur du gör detta med hjälp av Azure Functions och PowerShell.

En nackdel med den här metoden kan vara att du inte kan svara på oförutsägbara föränderliga skalningsbehov i realtid. I stället kan du behöva använda programkontexten i systemet, på klient-/SDK-nivå eller med autoskalning.

Använda CQL-frågor med ett specifikt SDK

Du kan skala systemet dynamiskt med kod genom att köra CQL ALTER-kommandon för den angivna databasen eller containern.

Fördelen med den här metoden är att du kan svara på skalningsbehov dynamiskt och på ett anpassat sätt som passar ditt program. Med den här metoden kan du fortfarande använda standardavgifter och ru/s-avgifter. Om systemets skalningsbehov är mest förutsägbara (cirka 70 % eller mer) kan användning av SDK med CQL vara en mer kostnadseffektiv metod för automatisk skalning än att använda autoskalning. Nackdelen med den här metoden är att det kan vara ganska komplicerat att implementera återförsök medan hastighetsbegränsning kan öka svarstiden.

Använda etablerat dataflöde för automatisk skalning

Förutom standard (manuellt) eller programmatiskt sätt att etablera dataflöde kan du även konfigurera Azure Cosmos DB-containrar i etablerat dataflöde för automatisk skalning. Autoskalning skalas automatiskt och omedelbart efter dina förbrukningsbehov inom angivna RU-intervall utan att kompromissa med serviceavtalen. Mer information finns i artikeln Skapa Azure Cosmos DB-containrar och databaser i autoskalning .

Fördelen med den här metoden är att det är det enklaste sättet att hantera skalningsbehoven i systemet. Den tillämpar inte hastighetsbegränsning inom de konfigurerade RU-intervallen. Nackdelen är att om skalningsbehoven i systemet är förutsägbara kan autoskalning vara ett mindre kostnadseffektivt sätt att hantera dina skalningsbehov än att använda det skräddarsydda kontrollplanet eller SDK-nivåmetoderna som nämns ovan.

Om du vill ange eller ändra maximalt dataflöde (RU:er) för autoskalning med hjälp av CQL använder du följande (ersätt keyspace/table name i enlighet med detta):

# to set max throughput (RUs) for autoscale at keyspace level:
create keyspace <keyspace name> WITH cosmosdb_autoscale_max_throughput=5000;

# to alter max throughput (RUs) for autoscale at keyspace level:
alter keyspace <keyspace name> WITH cosmosdb_autoscale_max_throughput=4000;

# to set max throughput (RUs) for autoscale at table level:
create table <keyspace name>.<table name> (pk int PRIMARY KEY, ck int) WITH cosmosdb_autoscale_max_throughput=5000;

# to alter max throughput (RUs) for autoscale at table level:
alter table <keyspace name>.<table name> WITH cosmosdb_autoscale_max_throughput=4000;

Nästa steg