VAN TOEPASSING OP: NoSQL MongoDB Cassandra Gremlin Tafel
Azure Cosmos DB maakt gebruik van ingerichte doorvoer voor automatisch schalen om de aanvraageenheden per seconde (RU/s) van uw database of container automatisch te beheren en te schalen op basis van gebruik. In dit artikel vindt u antwoorden op veelgestelde vragen over automatische schaalaanpassing in Azure Cosmos DB.
Wat is het verschil tussen automatische schaalaanpassing en dynamische automatische schaalaanpassing in Azure Cosmos DB?
Met automatische schaalaanpassing of automatische schaalaanpassing van ingerichte doorvoer worden workloads geschaald op basis van de meest actieve regio en partitie. Met dynamische automatische schaalaanpassing kunnen de regio's en partities van uw workloads daarentegen onafhankelijk worden geschaald op basis van gebruik. We raden dynamische automatische schaalaanpassing aan voor alle klanten die automatisch schalen willen gebruiken.
Hoe kan ik dynamische automatische schaalaanpassing op een account programmatisch inschakelen?
U kunt een Resource Manager-sjabloon met API-versie 2023-11-15-preview
of latere preview-versie gebruiken om de eigenschap enablePerRegionPerPartitionAutoscale
in te stellen op true. U kunt deze eigenschap in de JSON-weergave zien met behulp van preview-versie 2023-11-15-preview of een latere preview-versie.
U kunt ook de Azure CLI of PowerShell gebruiken.
// Add Azure Cosmos DB extension 2.0.6-preview for PowerShell
Install-Module -Name Az.CosmosDB -RequiredVersion 2.0.6-preview -AllowPrerelease -AllowClobber -Force
// update the account using this command to enable or disable the property
Update-AzCosmosDBAccount -EnablePerRegionPerPartitionAutoscale $true -ResourceGroupName "<resource-group-name>" -Name "<cosmos-account-name>"
// Run this command to see the enablement or disablement status:
Get-AzCosmosDBAccount -ResourceGroupName "<resource-group-name>" -Name "<cosmos-account-name>"
Wat gebeurt er met databases of containers die zijn gemaakt in het eerdere autopilot-laagmodel?
Resources die in het eerdere laagmodel zijn gemaakt, worden automatisch ondersteund in het nieuwe aangepaste ru/s-model voor automatisch schalen. De bovengrens van de laag wordt de nieuwe maximum-RU/s, wat resulteert in hetzelfde schaalbereik.
Als u bijvoorbeeld eerder de laag hebt geselecteerd die is geschaald tussen 400 RU/s en 4000 RU/s, wordt in de database of container nu een maximum van 4000 RU/s weergegeven. Deze schaalt tussen 400 RU/s en 4000 RU/s. Vervolgens kunt u de maximale RU/s wijzigen in een aangepaste waarde op basis van uw workload.
Wat is de ingangspunt-RU/s voor automatische schaalaanpassing?
Vanaf april 2022 kunt u automatische schaalaanpassing instellen met maximaal 1000 RU/s (schaalt tussen 100 RU/s en 1000 RU/s). U kunt ook een schaalbereik van 200 RU/s instellen op 2000 RU/s of 300 RU/s tot 3000 RU/s. Voorheen was het toegangspunt 400 RU/s tot 4000 RU/s.
We raden deze configuratie aan voor workloads met lage doorvoervereisten, maar die nog steeds kunnen worden geschaald naar de maximale RU/s.
Hoe snel schaalt automatisch schalen op basis van toenames in het verkeer?
Met automatische schaalaanpassing schaalt het systeem de doorvoer (RU/s) T
omhoog of T
omlaag binnen het bereik van 0,1 × Tmax
op Tmax
basis van inkomend verkeer. Omdat de schaal automatisch en onmiddellijk is, kunt u op elk moment verbruiken tot de inrichting Tmax
zonder vertraging.
Hoe kan ik bepalen naar hoeveel RU/s het systeem momenteel wordt geschaald?
Gebruik metrische gegevens van Azure Monitor om zowel de ingerichte ru/s voor automatische schaalaanpassing als de huidige doorvoer (RU/s) te bewaken waarnaar het systeem wordt geschaald.
Wat zijn de prijzen voor automatische schaalaanpassing?
Elk uur wordt u gefactureerd voor de hoogste doorvoer T
die het systeem binnen dat uur heeft geschaald. Als uw resource tijdens het uur geen aanvragen had of niet groter was dan 0,1 × Tmax
, wordt u gefactureerd voor minimaal 0,1 × Tmax
. Zie de pagina met prijzen van Azure Cosmos DB voor meer informatie.
Hoe wordt automatische schaalaanpassing op de factuur aangegeven?
In regioaccounts met één schrijfbewerking is de snelheid van automatische schaalaanpassing per 100 RU/s 1,5 keer zo hoog als de standaard (handmatige) ingerichte doorvoer. Uw factuur toont de bestaande standaard ingerichte doorvoermeter. De hoeveelheid van deze meter wordt vermenigvuldigd met 1,5. Als de hoogste RU/s die het systeem binnen een uur schaalt bijvoorbeeld 6.000 RU/s was, worden er 60 × 1,5 = 90 eenheden van de meter gefactureerd voor dat uur.
In accounts met meerdere schrijfregio's is de automatische schaalaanpassingssnelheid per 100 RU/s hetzelfde als de snelheid voor standaard (handmatig) ingerichte doorvoer van meerdere schrijfregio's. Uw factuur toont de bestaande meter met meerdere schrijfregio's. Omdat de tarieven hetzelfde zijn, ziet u, als u automatische schaalaanpassing gebruikt, dezelfde hoeveelheid als voor standaarddoorvoer.
Werkt automatische schaalaanpassing met gereserveerde capaciteit?
Ja. Met gereserveerde capaciteit voor accounts met regio's met één schrijfbewerking wordt de reserveringskorting voor resources voor automatische schaalaanpassing toegepast op het metergebruik met een verhouding van 1,5 keer de verhouding van de specifieke regio. Als u bijvoorbeeld gereserveerde capaciteit wilt gebruiken om 10.000 RU/s automatisch schalen te dekken, moet u 15.000 RU/s van gereserveerde capaciteit in totaal aanschaffen.
Gereserveerde capaciteit voor meerdere schrijfregio's werkt hetzelfde voor automatische schaalaanpassing en standaard (handmatige) ingerichte doorvoer. Zie gereserveerde capaciteit van Azure Cosmos DB voor meer informatie.
Werkt automatische schaalaanpassing met de gratis laag van Azure Cosmos DB?
Ja. In de gratis laag kunt u doorvoer automatisch schalen voor een database of in een container. Meer informatie over hoe facturering in de gratis laag werkt met automatische schaalaanpassing.
Wordt automatische schaalaanpassing ondersteund voor alle API's?
Ja. Automatische schaalaanpassing wordt ondersteund voor alle API's: NoSQL, Gremlin, Table, Cassandra en MongoDB.
Wordt automatische schaalaanpassing ondersteund voor schrijfaccounts in meerdere regio's?
Ja. De maximale RU/s zijn beschikbaar in elke regio die u toevoegt aan het Azure Cosmos DB-account.
Hoe kan ik automatische schaalaanpassing inschakelen voor nieuwe databases of containers?
Meer informatie over Automatische schaalaanpassing inschakelen.
Kan ik automatische schaalaanpassing inschakelen voor een bestaande database of container?
Ja. U kunt ook schakelen tussen automatische schaalaanpassing en standaard (handmatige) ingerichte doorvoer. Op dit moment kunt u voor alle API's de Azure-portal, de Azure CLI of PowerShell gebruiken om deze bewerkingen uit te voeren. Standaard kunt u de SDK's van de Azure Cosmos DB-client of een Azure Resource Manager-sjabloon niet gebruiken om te migreren tussen handmatig ingerichte doorvoer en automatische schaalaanpassing. U kunt echter client-SDK's of een Azure Resource Manager-sjabloon gebruiken om nieuwe resources voor automatisch schalen te maken en de maximale RU/s op een bestaande resource voor automatisch schalen te wijzigen.
Hoe gaat migratie tussen automatische schaalaanpassing en standaard (handmatig) ingerichte doorvoer in zijn werk?
Conceptueel is het wijzigen van het doorvoertype een proces in twee fasen. Eerst verzendt u een aanvraag om de doorvoerinstellingen te wijzigen om automatische schaalaanpassing of handmatig ingerichte doorvoer te gebruiken. In beide gevallen bepaalt en stelt het systeem automatisch een initiële RU/s-waarde in op basis van de huidige doorvoerinstellingen en opslag. Tijdens deze stap wordt er geen door de gebruiker opgegeven RU/s-waarde geaccepteerd. Nadat de update is voltooid, kunt u de RU/s wijzigen zodat deze geschikt zijn voor uw workload.
Migreren van standaard (handmatige) ingerichte doorvoer naar automatische schaalaanpassing
Gebruik voor een container de volgende formule om een schatting te maken van de initiële maximale RU/s voor automatische schaalaanpassing:
MAX(1,000, current manual provisioned RU/s, maximum RU/s ever provisioned / 10, storage in GB × 10)
afgerond op de dichtstbijzijnde 1000 RU/s.
Het werkelijke maximum aantal RU/s voor automatisch schalen kan variëren, afhankelijk van uw accountconfiguratie.
Voorbeeld 1: U hebt een container met een handmatig ingerichte doorvoer van 10.000 RU/s en 25 GB opslagruimte. Wanneer u automatische schaalaanpassing inschakelt, is de eerste maximale RU/s voor automatisch schalen 10.000 RU/s, die tussen 1000 RU/s en 10.000 RU/s kunnen worden geschaald.
Voorbeeld 2: U hebt een container met een handmatig ingerichte doorvoer van 50.000 RU/s en 25.000 GB opslagruimte. Wanneer u automatische schaalaanpassing inschakelt, is de initiële maximale RU/s voor automatisch schalen 250.000 RU/s, die kunnen worden geschaald tussen 25.000 RU/s en 250.000 RU/s.
Migreren van automatische schaalaanpassing naar standaard (handmatige) ingerichte doorvoer
De eerste handmatig ingerichte doorvoer is gelijk aan de huidige maximale RU/s voor automatische schaalaanpassing.
Voorbeeld: U hebt een database of container met automatische schaalaanpassing met een maximum van 20.000 RU/s (schaalt tussen 2000 RU/s en 20.000 RU/s). Wanneer u bijwerkt voor het gebruik van handmatig ingerichte doorvoer, is de initiële doorvoer 20.000 RU/s.
Als u een groot aantal doorvoerbronnen wilt migreren, kunt u overwegen azure CLI-script te gebruiken : converteren naar automatische schaalaanpassing.
Kan ik de Azure CLI, PowerShell of Azure Resource Manager gebruiken voor het beheren van databases of containers die gebruikmaken van automatische schaalaanpassing?
Ja. Als u automatisch schalen wilt inschakelen voor een bestaande database of container, kunt u de Azure CLI of PowerShell gebruiken.
Als u een nieuwe database of container wilt maken die gebruikmaakt van automatische schaalaanpassing, kunt u de Azure CLI, PowerShell of een Azure Resource Manager-sjabloon gebruiken.
Wordt automatische schaalaanpassing ondersteund voor gedeelde doorvoerdatabases?
Ja. Als u automatische schaalaanpassing wilt inschakelen voor een gedeelde doorvoerdatabase, selecteert u automatisch schalen en de optie Doorvoer inrichten wanneer u de database maakt.
Hoeveel containers zijn toegestaan per gedeelde doorvoerdatabase wanneer automatische schaalaanpassing is ingeschakeld?
Azure Cosmos DB dwingt maximaal 25 containers af in een gedeelde doorvoerdatabase. Het maximum is van toepassing op databases met automatische schaalaanpassing of standaarddoorvoer (handmatig).
Wat is de invloed van automatische schaalaanpassing op het consistentieniveau van de database?
Automatische schaalaanpassing heeft geen invloed op het consistentieniveau van een database.
Zie Consistentieniveaus voor meer informatie.
Welke opslaglimiet is gekoppeld aan elke maximale aantal RU/s-optie?
De opslaglimiet in GB voor elke maximale RU/s is de maximale RU/s van de database of container gedeeld door 10. Als de maximale RU/s bijvoorbeeld 20.000 RU/s is, kan de resource 2000 GB aan opslag ondersteunen.
Zie Limieten voor automatische schaalaanpassing voor doorvoer inrichten voor beschikbare maximale RU/s en opslagopties.
Wat gebeurt er als ik de opslaglimiet overschrijd die is gekoppeld aan mijn maximale doorvoer?
Als de opslaglimiet die is gekoppeld aan de maximale doorvoer van de database of container wordt overschreden, verhoogt Azure Cosmos DB automatisch de maximale doorvoer naar de eerstvolgende hoogste RU/s die ondersteuning kunnen bieden voor dat opslagniveau.
Als u bijvoorbeeld begint met een maximale RU/s van 50.000 RU/s (schaalt tussen 5.000 RU/s en 50.000 RU/s), kunt u maximaal 5000 GB aan gegevens opslaan. Als uw opslaggrootte toeneemt tot 5.001 GB, is de opslag nu 6.000 GB en is de nieuwe maximale RU/s 60.000 RU/s (schaalt tussen 6.000 RU/s en 60.000 RU/s).
Kan ik het maximale aantal RU/s voor een database of container wijzigen?
Ja. Zie Doorvoer voor automatische schaalaanpassing inrichten voor meer informatie.
Wanneer u de maximale RU/s wijzigt, afhankelijk van de aangevraagde waarde, kan het 4 tot 6 uur duren voordat de asynchrone bewerking is voltooid. Meer informatie.
Hoe kan ik het maximale aantal RU/s verhogen?
Wanneer u een aanvraag verzendt om het maximum aantal RU/s Tmax
te verhogen, afhankelijk van het maximum aantal RU/s dat is geselecteerd, richt de service meer resources in om de hogere maximale RU/s te ondersteunen. Hoewel dit gebeurt, worden uw bestaande workload en bewerkingen niet beïnvloed. Het systeem blijft uw database of container schalen tussen de vorige 0.1 × Tmax
en totdat Tmax
het nieuwe schaalbereik van 0.1 × Tmax_new
Tmax_new
gereed is.
Hoe kan ik het maximale aantal RU/s verlagen?
Wanneer u de maximale RU/s verlaagt, kunt u de minimumwaarde instellen op MAX(1,000, highest maximum RU/s ever provisioned / 10, current storage in GB × 10)
afgerond op de dichtstbijzijnde 1000 RU/s.
Voorbeeld 1: U hebt een container voor automatisch schalen met een maximum van 20.000 RU/s (schaalt tussen 20.000 RU/s en 20.000 RU/s) en 1500 GB aan opslag. De laagste minimumwaarde die u kunt instellen op maximale RU/s is MAX(1,000, 20,000 / 10, 1,500 × 10)
= 15.000 RU/s (schaalt tussen 1500 RU/s en 15.000 RU/s).
Voorbeeld 2: U hebt een container voor automatisch schalen met een maximale RU/s van 100.000 RU/s en 100 GB aan opslag. Nu schaalt u maximaal 150.000 RU/s (schaalt tussen 15.000 RU/s en 150.000 RU/s). De laagste minimumwaarde die u nu kunt instellen op maximale RU/s is MAX(1,000, 150,000 / 10, 100 × 10)
= 15.000 RU/s (schaalt tussen 1500 RU/s en 15.000 RU/s).
Wanneer u voor een gedeelde doorvoerdatabase de maximale RU/s verlaagt, kunt u de minimumwaarde instellen op MAX(1,000, highest maximum RU/s ever provisioned / 10, current storage in GB × 10, 1,000 + (MAX(Container count - 25, 0) × 1,000))
afgerond op de dichtstbijzijnde 1000 RU/s.
Deze formules en voorbeelden zijn van toepassing op de minimale ru/s voor automatische schaalaanpassing die u kunt instellen. Ze staan los van de 0.1-× Tmax
om te Tmax
variëren waarnaar het systeem automatisch wordt geschaald. Ongeacht de maximale RU/s schaalt het systeem altijd tussen 0,1 × Tmax
en Tmax
.
Hoe werkt TTL met automatische schaalaanpassing?
TTL-bewerkingen (Time to Live) hebben geen invloed op het schalen van RU/s in automatische schaalaanpassing. Ru's die worden gebruikt als gevolg van TTL, maken geen deel uit van de gefactureerde RU/s van de container voor automatische schaalaanpassing.
Bijvoorbeeld voor een container voor automatische schaalaanpassing met 400 RU/s tot 4000 RU/s:
- Uur 1: T=0: De container heeft geen gebruik (geen TTL- of workloadaanvragen). De factureerbare RU/s zijn 400 RU/s.
- Uur 1: T=1: TTL is ingeschakeld.
- Uur 1: T=2: De container begint aanvragen te krijgen. De aanvragen verbruiken 1000 RU/s in 1 seconde. Er worden 200 RU/s aan TTL gebruikt. De factureerbare RU/s zijn nog steeds 1000 RU/s. Ongeacht wanneer de TTL wordt verwijderd, hebben ze geen invloed op de logica voor automatisch schalen.
Hoe wordt het maximale aantal RU/s toegewezen aan fysieke partities?
Wanneer u voor het eerst de maximale RU/s selecteert, wordt azure Cosmos DB ingericht door het maximum aantal RU/s te delen met 10.000 RU/s om het aantal fysieke partities op te halen dat vereist is. Elke fysieke partitie kan maximaal 10.000 RU/s en 50 GB aan opslag ondersteunen. Naarmate de opslaggrootte toeneemt, splitst Azure Cosmos DB automatisch partities om meer fysieke partities toe te voegen om de opslagtoename af te handelen. Als de opslag de bijbehorende limiet overschrijdt, verhoogt Azure Cosmos DB de maximale RU/s.
De maximale RU/s van de database of container worden gelijkmatig verdeeld over alle fysieke partities. De totale doorvoer waarnaar elke fysieke partitie kan worden geschaald, is de maximale RU/s van de database of container gedeeld door het aantal fysieke partities.
Wat gebeurt er als binnenkomende aanvragen het maximale aantal RU/s van de database of container overschrijden?
Als de totale verbruikte RU/s de maximale RU/s van de database of container overschrijdt, worden aanvragen die groter zijn dan het maximum aantal RU/s, beperkt en retourneert u een code 429-status. Aanvragen die resulteren in meer dan 100 procent genormaliseerd gebruik, worden beperkt. Genormaliseerd gebruik wordt gedefinieerd als het maximum van het RU/s-gebruik voor alle fysieke partities.
Uw maximale doorvoer is bijvoorbeeld 20.000 RU/s en u hebt twee fysieke partities, P_1 en P_2. Elke partitie kan worden geschaald naar 10.000 RU/s. Als P_1 in een bepaalde seconde 6.000 RU's gebruikt en P_2 8.000 RU's gebruikt, is MAX(6,000 RU / 10,000 RU, 8,000 RU / 10,000 RU)
het genormaliseerde gebruik = 0,8.
Notitie
De SDK's van de Azure Cosmos DB-client en hulpprogramma's voor het importeren van gegevens (Azure Data Factory, de bulkexecutorbibliotheek) proberen automatisch opnieuw nadat een code 429-fout is geretourneerd, dus incidentele code 429-fouten zijn niet problematisch. Een langdurig groot aantal code 429-fouten kan erop wijzen dat u het maximum aantal RU/s moet verhogen of uw partitioneringsstrategie moet controleren om een dynamische partitie op te nemen.
Kunnen er bandbreedtebeperkings- of snelheidsbeperkingsfouten optreden wanneer automatische schaalaanpassing is ingeschakeld?
Ja. Het is mogelijk om code 429-fouten in twee scenario's te zien.
Als de totale verbruikte RU/s de maximale RU/s van de database of container overschrijdt, beperkt de service aanvragen dienovereenkomstig.
Ten tweede, als een waarde voor een logische partitiesleutel een onevenredig hoger aantal aanvragen heeft dan andere partitiesleutelwaarden, zoals in een dynamische partitie, kan de onderliggende fysieke partitie het RU/s-budget overschrijden. Als best practice om dynamische partities te voorkomen, kiest u een goede partitiesleutel die resulteert in een gelijkmatige verdeling van zowel opslag als doorvoer.
Als u bijvoorbeeld de maximale doorvoeroptie 20.000 RU/s selecteert en u 200 GB opslagruimte hebt, kan elke fysieke partitie automatisch worden geschaald tot 5000 RU/s als u vier fysieke partities hebt. Als een dynamische partitie zich op een specifieke logische partitiesleutel bevindt, ziet u code 429-fouten wanneer de onderliggende fysieke partitie waarin deze zich bevindt, groter is dan 5000 RU/s of 100 procent genormaliseerd gebruik.
Code 429-fouten zien wanneer u automatische schaalaanpassing gebruikt, duidt niet noodzakelijkerwijs op een probleem met uw database of container. Over het algemeen geldt voor een productieworkload, als tussen 1 en 5 procent van de aanvragen code 429-fouten bevatten en uw end-to-endlatentie acceptabel is, zijn de fouten een goed teken dat de RU/s volledig worden gebruikt. Er is geen actie vereist.
Meer informatie over het interpreteren en opsporen van fouten in code 429-frequentiebeperking.
Kan het genormaliseerde RU/s-verbruik 100 procent zijn als automatisch schalen niet wordt geschaald naar het maximale aantal RU/s?
Ja. Zie Genormaliseerde RU/s bewaken voor meer informatie.