Inleiding tot ingerichte doorvoer in Azure Cosmos DB

  • Artikel

VAN TOEPASSING OP: Nosql MongoDB Cassandra Gremlin Tabel

Met Azure Cosmos DB kunt u ingerichte doorvoer instellen voor uw databases en containers. Er zijn twee typen ingerichte doorvoer, standaard (handmatig) of automatisch schalen. Dit artikel bevat een overzicht van de werking van ingerichte doorvoer.

Een Azure Cosmos DB-database is een beheereenheid voor een set containers. Een database bestaat uit een set schema-agnostische containers. Een Azure Cosmos DB-container is de schaalbaarheidseenheid voor zowel doorvoer als opslag. Een container wordt horizontaal gepartitioneerd over een set machines binnen een Azure-regio en wordt verdeeld over alle Azure-regio's die zijn gekoppeld aan uw Azure Cosmos DB-account.

Met Azure Cosmos DB kunt u doorvoer inrichten op twee granulariteiten:

  • Azure Cosmos DB-containers
  • Azure Cosmos DB-databases

Doorvoer instellen voor een container

De doorvoer die is ingericht in een Azure Cosmos DB-container, is exclusief gereserveerd voor die container. De container ontvangt de ingerichte doorvoer altijd. De ingerichte doorvoer voor een container wordt financieel ondersteund door SLA's. Zie Doorvoer inrichten in een Azure Cosmos DB-container voor meer informatie over het configureren van standaarddoorvoer (handmatig) voor een container. Zie Doorvoer voor automatische schaalaanpassing inrichten voor meer informatie over het configureren van doorvoer voor automatische schaalaanpassing voor een container.

Het instellen van ingerichte doorvoer voor een container is de meest gebruikte optie. U kunt doorvoer voor een container elastisch schalen door elke hoeveelheid doorvoer in te richten met behulp van aanvraageenheden (RU's).

De doorvoer die is ingericht voor een container wordt gelijkmatig verdeeld over de fysieke partities en ervan uitgaande dat een goede partitiesleutel wordt gebruikt die de logische partities gelijkmatig over de fysieke partities distribueert, wordt de doorvoer ook gelijkmatig verdeeld over alle logische partities van de container. U kunt de doorvoer voor logische partities niet selectief opgeven. Omdat een of meer logische partities van een container worden gehost door een fysieke partitie, behoren de fysieke partities uitsluitend tot de container en ondersteunen ze de doorvoer die op de container is ingericht.

Als de werkbelasting die wordt uitgevoerd op een logische partitie meer verbruikt dan de doorvoer die is toegewezen aan de onderliggende fysieke partitie, is het mogelijk dat uw bewerkingen beperkt zijn. Wat een dynamische partitie wordt genoemd, treedt op wanneer één logische partitie onevenredig meer aanvragen heeft dan andere partitiesleutelwaarden.

Wanneer snelheidsbeperking optreedt, kunt u de ingerichte doorvoer voor de hele container verhogen of de bewerkingen opnieuw uitvoeren. U moet er ook voor zorgen dat u een partitiesleutel kiest die opslag gelijkmatig distribueert en het aanvraagvolume distribueert. Zie Partitioneren en horizontaal schalen in Azure Cosmos DB voor meer informatie over partitioneren.

U wordt aangeraden de doorvoer bij de containergranulariteit te configureren wanneer u voorspelbare prestaties voor de container wilt.

In de volgende afbeelding ziet u hoe een fysieke partitie als host fungeert voor een of meer logische partities van een container:

Physical partition that hosts one or more logical partitions of a container

Doorvoer instellen voor een database

Wanneer u doorvoer inricht voor een Azure Cosmos DB-database, wordt de doorvoer gedeeld tussen alle containers (gedeelde databasecontainers genoemd) in de database. Een uitzondering hierop is als u ingerichte doorvoer hebt opgegeven voor specifieke containers in de database. Het delen van de ingerichte doorvoer op databaseniveau tussen de containers is vergelijkbaar met het hosten van een database op een cluster van machines. Omdat alle containers in een database de resources delen die beschikbaar zijn op een computer, krijgt u natuurlijk geen voorspelbare prestaties voor een specifieke container. Zie Ingerichte doorvoer configureren in een Azure Cosmos DB-database voor meer informatie over het configureren van ingerichte doorvoer voor een database. Zie Doorvoer voor automatische schaalaanpassing inrichten voor meer informatie over het configureren van doorvoer voor automatische schaalaanpassing voor een database.

Omdat alle containers in de database de ingerichte doorvoer delen, biedt Azure Cosmos DB geen voorspelbare doorvoergaranties voor een bepaalde container in die database. Het gedeelte van de doorvoer dat een specifieke container kan ontvangen, is afhankelijk van:

  • Het aantal containers.
  • De keuze van partitiesleutels voor verschillende containers.
  • De verdeling van de workload over verschillende logische partities van de containers.

U wordt aangeraden de doorvoer voor een database te configureren wanneer u de doorvoer wilt delen tussen meerdere containers, maar de doorvoer niet wilt toewijzen aan een bepaalde container.

In de volgende voorbeelden ziet u waar de voorkeur wordt gegeven aan het inrichten van doorvoer op databaseniveau:

  • Het delen van de ingerichte doorvoer van een database in een set containers is handig voor een toepassing met meerdere tenants. Elke gebruiker kan worden vertegenwoordigd door een afzonderlijke Azure Cosmos DB-container.

  • Het delen van de ingerichte doorvoer van een database in een set containers is handig wanneer u een NoSQL-database, zoals MongoDB of Cassandra, migreert op een cluster met VIRTUELE machines of van on-premises fysieke servers naar Azure Cosmos DB. Denk aan de ingerichte doorvoer die is geconfigureerd in uw Azure Cosmos DB-database als een logisch equivalent, maar rendabeler en elastischer, met die van de rekencapaciteit van uw MongoDB- of Cassandra-cluster.

Alle containers die in een database met ingerichte doorvoer zijn gemaakt, moeten worden gemaakt met een partitiesleutel. Op een bepaald moment wordt de doorvoer die is toegewezen aan een container binnen een database verdeeld over alle logische partities van die container. Wanneer u containers hebt die ingerichte doorvoer hebben geconfigureerd voor een database, kunt u de doorvoer niet selectief toepassen op een specifieke container of een logische partitie.

Als de werkbelasting op een logische partitie meer verbruikt dan de doorvoer die is toegewezen aan een specifieke logische partitie, zijn uw bewerkingen beperkt. Wanneer snelheidsbeperking optreedt, kunt u de doorvoer voor de hele database verhogen of de bewerkingen opnieuw uitvoeren. Zie Logische partities voor meer informatie over partitioneren.

Containers in een gedeelde doorvoerdatabase delen de doorvoer (RU/s) die zijn toegewezen aan deze database. Met standaard (handmatig) ingerichte doorvoer kunt u maximaal 25 containers hebben met minimaal 400 RU/s in de database. Met ingerichte doorvoer voor automatische schaalaanpassing kunt u maximaal 25 containers in een database hebben met minimaal 1000 RU/s (schaalt tussen 100 en 1000 RU/s).

Notitie

In februari 2020 is een wijziging geïntroduceerd waarmee u maximaal 25 containers in een gedeelde doorvoerdatabase kunt hebben, waardoor het delen van de doorvoer voor de containers eenvoudiger wordt. Na de eerste 25 containers kunt u alleen meer containers aan de database toevoegen als ze zijn ingericht met toegewezen doorvoer, die gescheiden is van de gedeelde doorvoer van de database.
Als uw Azure Cosmos DB-account al een gedeelde doorvoerdatabase bevat met >=25 containers, worden het account en alle andere accounts in hetzelfde Azure-abonnement uitgesloten van deze wijziging. Neem contact op met productondersteuning als u feedback of vragen hebt.

Als uw workloads betrekking hebben op het verwijderen en opnieuw maken van alle verzamelingen in een database, wordt u aangeraden de lege database te verwijderen en een nieuwe database opnieuw te maken voordat u de verzameling maakt. In de volgende afbeelding ziet u hoe een fysieke partitie een of meer logische partities kan hosten die deel uitmaken van verschillende containers in een database:

Physical partition that hosts one or more logical partitions that belong to different containers

Doorvoer instellen voor een database en een container

U kunt de twee modellen combineren. Doorvoer inrichten voor zowel de database als de container is toegestaan. In het volgende voorbeeld ziet u hoe u standaard (handmatig) ingerichte doorvoer inricht in een Azure Cosmos DB-database en een container:

  • U kunt een Azure Cosmos DB-database maken met de naam Z met standaard (handmatig) ingerichte doorvoer van 'K' -RU's.

  • Maak vervolgens vijf containers met de naam A, B, C, D en E in de database. Zorg er bij het maken van container B voor dat u toegewezen doorvoer inrichten inschakelt voor deze containeroptie en expliciet P-RU's configureert van ingerichte doorvoer voor deze container. U kunt gedeelde en toegewezen doorvoer alleen configureren bij het maken van de database en container.

    Setting the throughput at the container-level

  • De RU/s-doorvoer van K wordt gedeeld tussen de vier containers A, C, D en E. De exacte hoeveelheid doorvoer die beschikbaar is voor A, C, D of E , varieert. Er zijn geen SLA's voor de doorvoer van elke afzonderlijke container.

  • De container met de naam B krijgt gegarandeerd de doorvoer van de 'P' RU/s altijd. Het wordt ondersteund door SLA's.

Notitie

Een container met ingerichte doorvoer kan niet worden geconverteerd naar een gedeelde databasecontainer. Omgekeerd kan een gedeelde databasecontainer niet worden geconverteerd naar een toegewezen doorvoer. U moet de gegevens verplaatsen naar een container met de gewenste doorvoerinstelling. (Container kopieertaken voor NoSQL-, MongoDB- en Cassandra-API's helpen bij dit proces.)

Doorvoer bijwerken in een database of een container

Nadat u een Azure Cosmos DB-container of een database hebt gemaakt, kunt u de ingerichte doorvoer bijwerken. Er is geen limiet voor de maximaal ingerichte doorvoer die u kunt configureren voor de database of de container.

Huidige ingerichte doorvoer

U kunt de ingerichte doorvoer van een container of database ophalen in Azure Portal of met behulp van de SDK's:

Het antwoord van deze methoden bevat ook de minimale ingerichte doorvoer voor de container of database:

De werkelijke minimale RU/s kunnen variëren, afhankelijk van uw accountconfiguratie. Zie de veelgestelde vragen over automatische schaalaanpassing voor meer informatie.

De ingerichte doorvoer wijzigen

U kunt de ingerichte doorvoer van een container of een database schalen via Azure Portal of met behulp van de SDK's:

Als u de ingerichte doorvoer verlaagt, kunt u dit tot het minimum doen.

Als u de ingerichte doorvoer verhoogt, wordt de bewerking meestal onmiddellijk uitgevoerd. Er zijn echter gevallen waarin de bewerking langer kan duren vanwege de systeemtaken om de vereiste resources in te richten. In dit geval levert een poging om de ingerichte doorvoer te wijzigen terwijl deze bewerking wordt uitgevoerd een HTTP 423-antwoord met een foutbericht waarin wordt uitgelegd dat er een andere schaalbewerking wordt uitgevoerd.

Meer informatie vindt u in het artikel Aanbevolen procedures voor het schalen van ingerichte doorvoer (RU/s).

Notitie

Als u van plan bent een zeer grote opnameworkload te plannen waarvoor een grote toename van de ingerichte doorvoer is vereist, moet u er rekening mee houden dat de schaalbewerking geen SLA heeft en, zoals vermeld in de vorige alinea, kan het lang duren wanneer de toename groot is. Mogelijk wilt u vooruit plannen en de schaal starten voordat de workload wordt gestart en de onderstaande methoden gebruiken om de voortgang te controleren.

U kunt de schaalvoortgang programmatisch controleren door de huidige ingerichte doorvoer te lezen en het volgende te gebruiken:

U kunt metrische gegevens van Azure Monitor gebruiken om de geschiedenis van ingerichte doorvoer (RU/s) en opslag op een resource weer te geven.

Vergelijking van modellen

In deze tabel ziet u een vergelijking tussen de standaarddoorvoer (handmatig) inrichten voor een database versus een container.

Parameter Standaarddoorvoer (handmatig) voor een database Standaarddoorvoer (handmatig) voor een container Doorvoer automatisch schalen voor een database Doorvoer automatisch schalen op een container
Toegangspunt (minimale RU/s) 400 RU/s. Kan maximaal 25 containers hebben zonder ru/s minimaal per container. 400 Automatische schaalaanpassing tussen 100 - 1000 RU/s. Kan maximaal 25 containers hebben zonder ru/s minimaal per container. Automatische schaalaanpassing tussen 100 - 1000 RU/s.
Minimale RU/s per container -- 400 -- Automatische schaalaanpassing tussen 100 - 1000 RU/s
Maximum aantal RU's Onbeperkt, op de database. Onbeperkt, op de container. Onbeperkt, op de database. Onbeperkt, op de container.
RU's die zijn toegewezen aan of beschikbaar zijn voor een specifieke container Geen garanties. RU's die zijn toegewezen aan een bepaalde container, zijn afhankelijk van de eigenschappen. Eigenschappen kunnen de keuze zijn van partitiesleutels van containers die de doorvoer delen, de distributie van de workload en het aantal containers. Alle RU's die op de container zijn geconfigureerd, zijn exclusief gereserveerd voor de container. Geen garanties. RU's die zijn toegewezen aan een bepaalde container, zijn afhankelijk van de eigenschappen. Eigenschappen kunnen de keuze zijn van partitiesleutels van containers die de doorvoer delen, de distributie van de workload en het aantal containers. Alle RU's die op de container zijn geconfigureerd, zijn exclusief gereserveerd voor de container.
Maximale opslag voor een container Onbeperkt. Onbeperkt Onbeperkt Onbeperkt
Maximale doorvoer per logische partitie van een container 10.000 RU/s 10.000 RU/s 10.000 RU/s 10.000 RU/s
Maximale opslag (gegevens en index) per logische partitie van een container 20 GB 20 GB 20 GB 20 GB

Volgende stappen