Elastisk skalning av ett Azure Cosmos DB API för Cassandra konto

  • Artikel
  • 4 minuter för att läsa

GÄLLER för: API för Cassandra

Det finns en mängd olika alternativ för att utforska den elastiska Azure Cosmos DB API:et för 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 begäran (RU/s) för att ta hänsyn till prestandakraven i systemet. Mer information om enheter för begäran finns i artikeln enheter för begäran.

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

Databasåtgärder förbrukar enheter för begäran

Hanteringsfrekvensbegrä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. Den API för Cassandra i Azure Cosmos DB översätter dessa undantag till överbelastade fel i det interna Cassandra-protokollet.

Om systemet inte är känsligt för svarstider 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 transparent hantering av hastighetsbegränsning. De här exemplen implementerar en anpassad version av standardprincipen för cassandra-å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 bör du följa våra riktlinjer för att optimera dataflödeskonfigurationen för Spark-anslutningsappen.

Hantera skalning

Om du behöver minimera svarstiden finns det ett spektrum av alternativ för att hantera skalning och etablering av dataflöde (RU:er) i API för Cassandra:

I följande avsnitt beskrivs 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änd Azure Portal

Du kan skala resurserna i Azure Cosmos DB API för Cassandra med hjälp av Azure Portal. Mer information finns i artikeln om att etablera dataflöde på 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 "databas" och "container" som anges i dessa artiklar mappar till "nyckelutrymme" respektive "tabell" för API för Cassandra.

Fördelen med den här metoden är att det är ett enkelt nyckelfärdigt sätt att hantera dataflödeskapacitet på 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 API för Cassandra kan du justera dataflödet programmatiskt med hjälp av våra olika kontrollplansfunktioner. Se artiklarna Azure Resource Manager, PowerShelloch Azure CLI för vägledning och exempel.

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 aktivitetstoppar 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 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 en specifik SDK

Du kan skala systemet dynamiskt med kod genom att köra CQL ALTER-kommandona 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 dra nytta av standardavgifter och -priser för RU/s. Om systemets skalningsbehov främst är 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 autoskalning av etablerat dataflöde

Förutom standard (manuellt) eller programmatiskt sätt att etablera dataflöde kan du även konfigurera Azure Cosmos-containrar i automatiskt etablerat dataflöde. Autoskalning skalas automatiskt och omedelbart efter dina förbrukningsbehov inom angivna RU-intervall utan att serviceavtalen äventyras. Mer information finns i artikeln Skapa Azure Cosmos-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 de metoder för kontrollplan eller SDK-nivå 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ätter nyckelutrymme/tabellnamn enligt 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