Een Azure Cosmos DB voor Apache Cassandra-account elastisch schalen

VAN TOEPASSING OP: Cassandra

Er zijn verschillende opties om de elastische aard van Azure Cosmos DB voor Apache 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) kunt inrichten om rekening te houden met de prestatievereisten in uw systeem. Zie het artikel aanvraageenheden voor meer informatie over aanvraageenheden .

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

Databasebewerkingen verbruiken aanvraageenheden

Snelheidsbeperking verwerken (429 fouten)

Azure Cosmos DB retourneert fouten met een snelheidsbeperking (429) als clients meer resources (RU/s) gebruiken dan de hoeveelheid die u hebt ingericht. De API voor Cassandra in Azure Cosmos DB vertaalt deze uitzonderingen naar overbelaste fouten in het systeemeigen Cassandra-protocol.

Als uw systeem niet gevoelig is voor latentie, kan het voldoende zijn om de doorvoersnelheidsbeperking af te handelen met behulp van nieuwe pogingen. Zie Java-codevoorbeelden voor versie 3 en versie 4 van de Apache Cassandra Java-stuurprogramma's voor informatie over het transparant omgaan met snelheidsbeperking. Met deze voorbeelden wordt een aangepaste versie van het standaardbeleid voor opnieuw proberen van Cassandra geïmplementeerd in Java. U kunt ook de Spark-extensie gebruiken om snelheidsbeperking af te handelen. Wanneer u Spark gebruikt, moet u ervoor zorgen dat u onze richtlijnen voor het optimaliseren van de doorvoerconfiguratie van Spark-connector volgt.

Schalen beheren

Als u de latentie wilt minimaliseren, is er een scala aan opties voor het beheren van schaal en het inrichten van doorvoer (RU's) in de API voor Cassandra:

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

De Azure-portal gebruiken

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

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

Het besturingsvlak gebruiken

De API van Azure Cosmos DB voor Cassandra biedt de mogelijkheid om de doorvoer programmatisch aan te passen met behulp van onze verschillende besturingsvlakfuncties. Zie de artikelen over Azure Resource Manager, PowerShell en 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 van lage activiteit. Bekijk hier ons voorbeeld voor informatie over hoe u dit kunt doen met behulp van Azure Functions en PowerShell.

Een nadeel van deze aanpak kan zijn 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 Automatische schaalaanpassing.

CQL-query's gebruiken met een specifieke SDK

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

Het voordeel van deze aanpak is dat u dynamisch en op een aangepaste manier kunt reageren op schaalbehoeften die bij uw toepassing passen. Met deze benadering 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), is het gebruik van SDK met CQL mogelijk een kosteneffectievere methode voor automatisch schalen dan het gebruik van automatische schaalaanpassing. Het nadeel van deze aanpak is dat het vrij complex kan zijn om nieuwe pogingen te implementeren, terwijl snelheidsbeperking de latentie kan verhogen.

Ingerichte doorvoer automatisch schalen gebruiken

Naast de standaard (handmatige) of programmatische manier om doorvoer in te richten, kunt u Azure Cosmos DB-containers ook configureren in automatisch ingerichte doorvoer. Automatisch schalen wordt automatisch en direct geschaald naar uw verbruiksbehoeften binnen opgegeven RU-bereiken zonder sla's in gevaar te brengen. Zie het artikel Azure Cosmos DB-containers en -databases maken in automatische schaalaanpassing voor meer informatie.

Het voordeel van deze aanpak is dat het de eenvoudigste manier is om de schaalbehoeften in uw systeem te beheren. Er wordt geen snelheidsbeperking toegepast binnen de geconfigureerde RU-bereiken. Het nadeel is dat, als de schaalbehoeften in uw systeem voorspelbaar zijn, automatisch schalen een minder kosteneffectieve manier kan zijn om uw schaalbehoeften aan te pakken dan het gebruik van de hierboven genoemde op maat gemaakte besturingsvlak- of SDK-benaderingen.

Als u de maximale doorvoer (RU's) voor automatische schaalaanpassing wilt instellen of wijzigen 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