Een account voor een Azure Cosmos DB Cassandra-API schalen

VAN TOEPASSING OP: Cassandra-API

Er zijn verschillende opties om de elastische aard van de Azure Cosmos DB API voor Cassandra te verkennen. Als u wilt weten hoe u effectief kunt schalen in Azure Cosmos DB, is het belangrijk om te begrijpen hoe u de juiste hoeveelheid aanvraageenheden (RU/s) inrichten om rekening te houden met de prestatievraag in uw systeem. Zie het artikel aanvraageenheden voor meer informatie over aanvraageenheden.

Voor de Cassandra-API kunt u de kosten voor aanvraageenheden voor afzonderlijke query's ophalen met behulp van de .NET- en Java-SDK's. Dit is handig bij het bepalen van de hoeveelheid RU/s die u in de service moet inrichten.

Databasebewerkingen verbruiken aanvraageenheden

Snelheidsbeperking verwerken (429-fouten)

Azure Cosmos DB retourneren fouten met een snelheidsbegrensde snelheid (429) als clients meer resources (RU/s) verbruiken dan de hoeveelheid die u hebt ingericht. Met de Cassandra-API in Azure Cosmos DB worden deze uitzonderingen vertaald in overbelastfouten in het systeemeigen Cassandra-protocol.

Als uw systeem niet gevoelig is voor latentie, is het mogelijk voldoende om de doorvoersnelheidsbeperking af te handelen door nieuwe proberen te gebruiken. Zie Java-codevoorbeelden voor versie 3 en versie 4 van de Apache Cassandra Java-stuurprogramma's voor informatie over het transparant afhandelen van snelheidsbeperking. Met deze voorbeelden wordt een aangepaste versie van het standaard cassandra-beleid voor opnieuw proberen geïmplementeerd in Java. U kunt ook de Spark-extensie gebruiken om snelheidsbeperking af te handelen. Wanneer u Spark gebruikt, moet u onze richtlijnen voor het optimaliseren van de doorvoerconfiguratie van de Spark-connector volgen.

Schalen beheren

Als u de latentie wilt minimaliseren, is er een scala aan opties voor het beheren van de schaal- en inrichtingsdoorvoer (RUs) in de Cassandra-API:

In de volgende secties worden de voor- en nadelen van elke benadering uitgelegd. Vervolgens kunt u beslissen over de beste strategie om een balans te vinden tussen de schaalbehoeften van uw systeem, de totale kosten en efficiëntiebehoeften voor uw oplossing.

Gebruik de Azure Portal

U kunt de resources in Azure Cosmos DB Cassandra-API account schalen met behulp van Azure Portal. Zie het artikel Over doorvoer inrichten voor containers en databases voor meer informatie. In dit artikel worden de relatieve voordelen van het instellen van doorvoer op database- of containerniveau in de Azure Portal. De termen 'database' en 'container' die in deze artikelen worden vermeld, worden respectievelijk voor de Cassandra-API.

Het voordeel van deze methode is dat het een eenvoudige, kant-en-klare manier is om de doorvoercapaciteit van de database te beheren. Het nadeel is echter dat in veel gevallen voor uw benadering van schalen bepaalde automatiseringsniveaus zowel rendabel als goed presterend kunnen zijn. In de volgende secties worden de relevante scenario's en methoden uitgelegd.

Het besturingsvlak gebruiken

De API Azure Cosmos DB cassandra van de Azure Cosmos DB biedt de mogelijkheid om de doorvoer programmatisch aan te passen met behulp van onze verschillende functies op het besturingsvlak. Zie de Azure Resource Manager, PowerShellen Azure CLI voor richtlijnen en voorbeelden.

Het voordeel van deze methode is dat u het omhoog of omlaag schalen van resources kunt automatiseren op basis van een timer om rekening te houden met piekactiviteit of perioden met weinig activiteit. Bekijk hier ons voorbeeld om te zien hoe u dit kunt doen met Azure Functions en PowerShell.

Een nadeel van deze benadering is mogelijk dat u niet in realtime kunt reageren op onvoorspelbare veranderende schaalbehoeften. In plaats daarvan moet u mogelijk gebruikmaken van de toepassingscontext in uw systeem, op client-/SDK-niveau of met behulp van Automatisch schalen.

CQL-query's gebruiken met een specifieke SDK

U kunt het systeem dynamisch schalen met code door de CQL ALTER-opdrachten voor de opgegeven database of container uit te voeren.

Het voordeel van deze benadering is dat u hiermee dynamisch en op een aangepaste manier kunt reageren op schaalbehoeften die bij uw toepassing passen. Met deze methode kunt u nog steeds gebruikmaken van de standaard RU/s-kosten en tarieven. Als de schaalbehoeften van uw systeem meestal voorspelbaar zijn (ongeveer 70% of meer), kan het gebruik van SDK met CQL een rendabeler methode zijn voor automatisch schalen dan automatisch schalen. Het nadeel van deze benadering is dat het heel complex kan zijn om nieuwe proberen te implementeren, terwijl een snelheidsbeperking de latentie kan verhogen.

Inrichtende doorvoer automatisch schalen gebruiken

Naast de standaard (handmatige) of programmatische manier van het inrichten van doorvoer, kunt u ook Azure Cosmos-containers configureren in automatisch inrichten van doorvoer. Automatisch schalen wordt automatisch en onmiddellijk geschaald naar uw verbruiksbehoeften binnen opgegeven RU-bereik, zonder dat dit ten koste gaat van SLA's. Zie het artikel Azure Cosmos-containers en -databases maken in automatisch schalen voor meer informatie.

Het voordeel van deze benadering is dat het de eenvoudigste manier is om de schaalbehoeften in uw systeem te beheren. Er wordt geen snelheidsbeperking toegepast binnen de geconfigureerde RU-bereik. Het nadeel is dat als de schaalbehoeften in uw systeem voorspelbaar zijn, automatische schaalbaarheid een minder rendabele manier kan zijn om uw schaalbehoeften af te handelen dan het gebruik van de hierboven genoemde benaderingen op het bespoke-besturingsvlak of SDK-niveau.

Als u de maximale doorvoer (RUs) wilt instellen of wijzigen voor automatisch schalen met behulp van CQL, gebruikt u het volgende (vervang de naam van de keyspace/tabel dienovereenkomstig):

# 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;

Volgende stappen