Delen via

Kosten voor ingerichte doorvoer optimaliseren in Azure Cosmos DB

  • Artikel

VAN TOEPASSING OP: NoSQL MongoDB Cassandra Gremlin Tafel

Door het ingerichte doorvoermodel aan te bieden, biedt Azure Cosmos DB voorspelbare prestaties op elke schaal. Als u doorvoer van tevoren reserveert of inricht, elimineert u het 'lawaaierige buureffect' op uw prestaties. U geeft de exacte hoeveelheid doorvoer op die u nodig hebt en Azure Cosmos DB garandeert de geconfigureerde doorvoer, ondersteund door een SLA.

U kunt beginnen met een minimale doorvoer van 400 RU/sec en omhoog schalen tot tientallen miljoenen aanvragen per seconde of nog meer. Elke aanvraag die u opgeeft voor uw Azure Cosmos DB-container of -database, zoals een leesaanvraag, schrijfaanvraag, queryaanvraag, opgeslagen procedures hebben een overeenkomstige kosten die worden afgetrokken van de ingerichte doorvoer. Als u 400 RU/s inricht en een query uitvoert die 40 RU's kost, kunt u 10 dergelijke query's per seconde uitgeven. Elke aanvraag daarbuiten krijgt een frequentielimiet en u moet de aanvraag opnieuw proberen. Als u clientstuurprogramma's gebruikt, ondersteunen ze de logica voor automatisch opnieuw proberen.

U kunt doorvoer inrichten in databases of containers, en elke strategie kan helpen kosten te besparen, afhankelijk van het scenario.

Optimaliseren door doorvoer op verschillende niveaus in te richten

  • Als u doorvoer inricht voor een database, kunnen alle containers, bijvoorbeeld verzamelingen/tabellen/grafieken in die database, de doorvoer delen op basis van de belasting. De doorvoer die op databaseniveau is gereserveerd, wordt ongelijk verdeeld, afhankelijk van de workload van een specifieke set containers.

  • Als u doorvoer inricht voor een container, wordt de doorvoer gegarandeerd voor die container, ondersteund door de SLA. De keuze van een logische partitiesleutel is van cruciaal belang voor gelijkmatige verdeling van belasting over alle logische partities van een container. Zie Artikelen over partitioneren en horizontaal schalen voor meer informatie.

Hier volgen enkele richtlijnen voor het bepalen van een ingerichte doorvoerstrategie:

Overweeg om doorvoer in te richten op een Azure Cosmos DB-database (met een set containers) als:

  1. U hebt enkele tientallen Azure Cosmos DB-containers en u wilt doorvoer delen in sommige of allemaal containers.

  2. U migreert van een database met één tenant die is ontworpen voor uitvoering op virtuele IaaS-machines of on-premises, bijvoorbeeld NoSQL- of relationele databases naar Azure Cosmos DB. En als u veel verzamelingen/tabellen/grafieken hebt en u geen wijzigingen wilt aanbrengen in uw gegevensmodel. Houd er rekening mee dat u mogelijk een aantal voordelen van Azure Cosmos DB moet in gevaar komen als u uw gegevensmodel niet bijwerkt wanneer u migreert vanuit een on-premises database. Het is raadzaam dat u uw gegevensmodel altijd opnieuw evalueert om optimaal te profiteren van de prestaties en om te optimaliseren voor kosten.

  3. U wilt ongeplande pieken in werkbelastingen absorberen vanwege pooldoorvoer op databaseniveau, afhankelijk van onverwachte pieken in de werkbelasting.

  4. In plaats van specifieke doorvoer in te stellen voor afzonderlijke containers, is het belangrijk dat u de geaggregeerde doorvoer over een set containers in de database krijgt.

Overweeg de doorvoer voor een afzonderlijke container in te richten als:

  1. U hebt enkele Azure Cosmos DB-containers. Omdat Azure Cosmos DB schemaneutraal is, kan een container items bevatten met heterogene schema's en hoeven klanten niet meerdere containertypen te maken, één voor elke entiteit. Het is altijd een optie om te overwegen of het groeperen van afzonderlijke containers 10-20 in één container zinvol is. Met een minimum van 400 RU's voor containers is het groeperen van alle 10-20 containers in één mogelijk rendabeler.

  2. U wilt de doorvoer voor een specifieke container beheren en de gegarandeerde doorvoer ophalen voor een bepaalde container die wordt ondersteund door een SLA.

Overweeg een hybride van de bovenstaande twee strategieën:

  1. Zoals eerder vermeld, kunt u met Azure Cosmos DB de bovenstaande twee strategieën combineren en vergelijken, zodat u nu enkele containers in de Azure Cosmos DB-database kunt hebben, die mogelijk de doorvoer deelt die is ingericht voor de database, evenals sommige containers binnen dezelfde database, die mogelijk toegewezen hoeveelheden ingerichte doorvoer hebben.

  2. U kunt de bovenstaande strategieën toepassen om te komen met een hybride configuratie, waarbij u beide doorvoer op databaseniveau hebt ingericht met sommige containers met toegewezen doorvoer.

Zoals wordt weergegeven in de volgende tabel, kunt u, afhankelijk van de keuze van de API, doorvoer inrichten op verschillende granulariteiten.

API Voor gedeelde doorvoer configureert u Voor toegewezen doorvoer configureert u
API voor NoSQL Database Container
Azure Cosmos DB-API voor MongoDB Database Verzameling
API voor Cassandra Keyspace Tabel
API voor Gremlin Databaseaccount Grafiek
API voor Table Databaseaccount Tabel

Door doorvoer op verschillende niveaus in te richten, kunt u uw kosten optimaliseren op basis van de kenmerken van uw workload. Zoals eerder vermeld, kunt u programmatisch en op elk gewenst moment de ingerichte doorvoer verhogen of verlagen voor afzonderlijke containers of gezamenlijk in een set containers. Door de doorvoer elastisch te schalen wanneer uw workload verandert, betaalt u alleen voor de doorvoer die u hebt geconfigureerd. Als uw container of een set containers wordt verdeeld over meerdere regio's, is de doorvoer die u configureert voor de container of een set containers gegarandeerd beschikbaar in alle regio's.

Optimaliseren door snelheidsbeperking toe te passen op aanvragen

Voor workloads die niet gevoelig zijn voor latentie, kunt u minder doorvoer inrichten en de toepassing frequentiebeperking laten verwerken wanneer de werkelijke doorvoer de ingerichte doorvoer overschrijdt. De server beëindigt de aanvraag RequestRateTooLarge met (HTTP-statuscode 429) en retourneert de header die de x-ms-retry-after-ms hoeveelheid tijd aangeeft, in milliseconden, dat de gebruiker moet wachten voordat de aanvraag opnieuw wordt geprobeerd.

HTTP Status 429, 
 Status Line: RequestRateTooLarge 
 x-ms-retry-after-ms :100

Logica voor opnieuw proberen in SDK's

De systeemeigen SDK's (.NET/.NET Core, Java, Node.js en Python) vangen dit antwoord impliciet op, respecteren de server opgegeven nieuwe poging na header en voer de aanvraag opnieuw uit. Tenzij uw account gelijktijdig wordt geopend door meerdere clients, slaagt de volgende nieuwe poging.

Als u meerdere clients cumulatief boven de aanvraagsnelheid hebt, is het standaardaantal nieuwe pogingen, dat momenteel is ingesteld op 9, mogelijk niet voldoende. In dergelijke gevallen genereert de client een RequestRateTooLargeException met statuscode 429 aan de toepassing. Het standaardaantal nieuwe pogingen kan worden gewijzigd door het RetryOptions in te stellen op het ConnectionPolicy-exemplaar. Standaard wordt de RequestRateTooLargeException met statuscode 429 geretourneerd na een cumulatieve wachttijd van 30 seconden als de aanvraag blijft werken boven de aanvraagsnelheid. Dit gebeurt zelfs wanneer het huidige aantal nieuwe pogingen kleiner is dan het maximumaantal nieuwe pogingen, of het nu de standaardwaarde is van 9 of een door de gebruiker gedefinieerde waarde.

MaxRetryAttemptsOnThrottledRequests is ingesteld op 3, dus als een aanvraagbewerking wordt beperkt door de gereserveerde doorvoer voor de container te overschrijden, wordt de aanvraagbewerking drie keer opnieuw uitgevoerd voordat de uitzondering op de toepassing wordt gegenereerd. MaxRetryWaitTimeInSeconds is ingesteld op 60, dus in dit geval als de cumulatieve wachttijd voor opnieuw proberen in seconden sinds de eerste aanvraag langer is dan 60 seconden, wordt de uitzondering gegenereerd.

ConnectionPolicy connectionPolicy = new ConnectionPolicy(); 
connectionPolicy.RetryOptions.MaxRetryAttemptsOnThrottledRequests = 3; 
connectionPolicy.RetryOptions.MaxRetryWaitTimeInSeconds = 60;

Partitioneringsstrategie en kosten van ingerichte doorvoer

Een goede partitioneringsstrategie is belangrijk voor het optimaliseren van kosten in Azure Cosmos DB. Zorg ervoor dat er geen scheeftrekken van partities zijn, die worden weergegeven via metrische opslaggegevens. Zorg ervoor dat er geen scheeftrekken van doorvoer is voor een partitie, die wordt weergegeven met metrische gegevens over doorvoer. Zorg ervoor dat er geen scheefheid is ten opzichte van bepaalde partitiesleutels. Dominante sleutels in de opslag worden weergegeven via metrische gegevens, maar de sleutel is afhankelijk van het toegangspatroon van uw toepassing. Het is raadzaam om na te denken over de juiste logische partitiesleutel. Naar verwachting heeft een goede partitiesleutel de volgende kenmerken:

  • Kies een partitiesleutel waarmee de werkbelasting gelijkmatig over alle partities en gelijkmatig in de loop van de tijd wordt verdeeld. Met andere woorden, u moet geen enkele sleutels hebben voor het merendeel van de gegevens en sommige sleutels met minder of geen gegevens.

  • Kies een partitiesleutel waarmee toegangspatronen gelijkmatig over logische partities kunnen worden verdeeld. De workload is redelijk gelijkmatig over alle sleutels. Met andere woorden, het merendeel van de workload moet niet gericht zijn op een paar specifieke sleutels.

  • Kies een partitiesleutel met een breed scala aan waarden.

Het basisidee is het verspreiden van de gegevens en de activiteit in uw container over de set logische partities, zodat resources voor gegevensopslag en doorvoer kunnen worden gedistribueerd over de logische partities. Kandidaten voor partitiesleutels kunnen de eigenschappen bevatten die vaak worden weergegeven als filter in uw query's. Query's kunnen efficiënt worden gerouteerd door de partitiesleutel op te nemen in het filterpredicaat. Met een dergelijke partitioneringsstrategie is het optimaliseren van ingerichte doorvoer veel eenvoudiger.

Kleinere items ontwerpen voor hogere doorvoer

De aanvraagkosten of de verwerkingskosten van een bepaalde bewerking worden rechtstreeks gecorreleerd aan de grootte van het item. Bewerkingen op grote items kosten meer dan bewerkingen op kleinere items.

Patronen voor gegevenstoegang

Het is altijd een goede gewoonte om uw gegevens logisch te scheiden in logische categorieën op basis van hoe vaak u toegang hebt tot de gegevens. Door deze te categoriseren als dynamische, gemiddelde of koude gegevens, kunt u de verbruikte opslag en de vereiste doorvoer verfijnen. Afhankelijk van de frequentie van toegang kunt u de gegevens in afzonderlijke containers plaatsen (bijvoorbeeld tabellen, grafieken en verzamelingen) en de ingerichte doorvoer afstemmen om tegemoet te komen aan de behoeften van dat segment van gegevens.

Als u Azure Cosmos DB gebruikt en u weet dat u niet wilt zoeken op bepaalde gegevenswaarden of deze zelden opent, moet u de gecomprimeerde waarden van deze kenmerken opslaan. Met deze methode bespaart u op opslagruimte, indexruimte en ingerichte doorvoer en leidt dit tot lagere kosten.

Optimaliseren door indexeringsbeleid te wijzigen

Standaard wordt in Azure Cosmos DB elke eigenschap van elke record automatisch geïndexeerd. Dit is bedoeld om de ontwikkeling te vereenvoudigen en uitstekende prestaties te garanderen voor veel verschillende typen ad-hocquery's. Als u grote records met duizenden eigenschappen hebt, zijn de doorvoerkosten voor het indexeren van elke eigenschap mogelijk niet nuttig, vooral als u alleen query's uitvoert op 10 of 20 van deze eigenschappen. Naarmate u dichter bij uw specifieke workload komt, is het onze richtlijnen om uw indexbeleid af te stemmen. Hier vindt u de volledige informatie over het indexeringsbeleid van Azure Cosmos DB.

Ingerichte en verbruikte doorvoer bewaken

U kunt het totale aantal ingerichte RU's, het aantal aanvragen met een frequentielimiet en het aantal RU's dat u hebt verbruikt in Azure Portal controleren. In de volgende afbeelding ziet u een voorbeeld van een metrische gegevens over gebruik:

Aanvraageenheden bewaken in Azure Portal

U kunt ook waarschuwingen instellen om te controleren of het aantal aanvragen met een frequentielimiet een specifieke drempelwaarde overschrijdt. Zie Het artikel Over het bewaken van Azure Cosmos DB voor meer informatie. Deze waarschuwingen kunnen een e-mail verzenden naar de accountbeheerders of een aangepaste HTTP-webhook of een Azure-functie aanroepen om de ingerichte doorvoer automatisch te verhogen.

Uw doorvoer elastisch en on-demand schalen

Omdat u wordt gefactureerd voor de ingerichte doorvoer, kunt u de kosten voor de ongebruikte doorvoer vermijden door de ingerichte doorvoer aan uw behoeften te koppelen. U kunt de ingerichte doorvoer naar behoefte op elk gewenst moment omhoog of omlaag schalen. Als uw doorvoerbehoeften zeer voorspelbaar zijn, kunt u Azure Functions gebruiken en een timertrigger gebruiken om de doorvoer volgens een schema te verhogen of te verlagen.

  • Het controleren van het verbruik van uw RU's en de verhouding van aanvragen met een frequentielimiet kan aantonen dat u niet gedurende de hele dag of de week hoeft te worden ingericht. U ontvangt mogelijk minder verkeer 's nachts of in het weekend. Met behulp van Azure Portal of systeemeigen SDK's van Azure Cosmos DB of REST API kunt u uw ingerichte doorvoer op elk gewenst moment schalen. De REST API van Azure Cosmos DB biedt eindpunten voor het programmatisch bijwerken van het prestatieniveau van uw containers, waardoor het eenvoudig is om de doorvoer van uw code aan te passen, afhankelijk van het tijdstip van de dag of de dag van de week. De bewerking wordt uitgevoerd zonder uitvaltijd en wordt doorgaans in minder dan een minuut van kracht.

  • Een van de gebieden waar u doorvoer moet schalen, is wanneer u gegevens opneemt in Azure Cosmos DB, bijvoorbeeld tijdens gegevensmigratie. Zodra u de migratie hebt voltooid, kunt u de ingerichte doorvoer omlaag schalen om de stabiele status van de oplossing af te handelen.

  • Houd er rekening mee dat de facturering een granulariteit van één uur heeft, dus u bespaart geen geld als u de ingerichte doorvoer vaker dan één uur tegelijk wijzigt.

De doorvoer bepalen die nodig is voor een nieuwe workload

Als u de ingerichte doorvoer voor een nieuwe workload wilt bepalen, kunt u de volgende stappen uitvoeren:

  1. Voer een eerste, ruwe evaluatie uit met behulp van de capaciteitsplanner en pas uw schattingen aan met behulp van Azure Cosmos DB Explorer in Azure Portal.

  2. Het is raadzaam om de containers met een hogere doorvoer te maken dan verwacht en vervolgens naar behoefte omlaag te schalen.

  3. Het is raadzaam om een van de systeemeigen Azure Cosmos DB SDK's te gebruiken om te profiteren van automatische nieuwe pogingen wanneer aanvragen een frequentielimiet krijgen. Als u werkt aan een platform dat niet wordt ondersteund en de REST API van Azure Cosmos DB gebruikt, implementeert u uw eigen beleid voor opnieuw proberen met behulp van de x-ms-retry-after-ms header.

  4. Zorg ervoor dat uw toepassingscode de case correct ondersteunt wanneer alle nieuwe pogingen mislukken.

  5. U kunt waarschuwingen vanuit Azure Portal configureren om meldingen te ontvangen voor snelheidsbeperking. U kunt beginnen met conservatieve limieten, zoals 10 aanvragen met een frequentielimiet in de afgelopen 15 minuten en overschakelen naar meer gretig regels zodra u uw werkelijke verbruik hebt bepaald. Af en toe zijn frequentielimieten prima, ze laten zien dat u speelt met de limieten die u hebt ingesteld en dat is precies wat u wilt doen.

  6. Gebruik bewaking om inzicht te hebben in uw verkeerspatroon, zodat u rekening kunt houden met de noodzaak om uw doorvoerinrichting dynamisch aan te passen gedurende de dag of een week.

  7. Bewaak uw ingerichte versus verbruikte doorvoerverhouding regelmatig om ervoor te zorgen dat u niet meer hebt ingericht dan het vereiste aantal containers en databases. Een beetje te veel ingerichte doorvoer is een goede veiligheidscontrole.

Aanbevolen procedures voor het optimaliseren van ingerichte doorvoer

Met de volgende stappen kunt u uw oplossingen zeer schaalbaar en rendabel maken bij het gebruik van Azure Cosmos DB.

  1. Als u de doorvoer voor containers en databases aanzienlijk hebt overschreden, moet u ru's controleren die zijn ingericht versus verbruikte RU's en de workloads verfijnen.

  2. Een methode voor het schatten van de hoeveelheid gereserveerde doorvoer die door uw toepassing is vereist, is het vastleggen van de ru-kosten voor aanvraageenheden die zijn gekoppeld aan het uitvoeren van typische bewerkingen voor een representatieve Azure Cosmos DB-container of -database die door uw toepassing wordt gebruikt en vervolgens het aantal bewerkingen dat u verwacht elke seconde uit te voeren. Zorg ervoor dat u ook typische query's en hun gebruik meet en opneemt. Zie De kosten van query's optimaliseren voor query's voor meer informatie over het programmatisch schatten van RU-kosten van query's of het gebruik van de portal.

  3. Een andere manier om bewerkingen en hun kosten in RU's op te halen, is door Azure Monitor-logboeken in te schakelen, zodat u de bewerking/duur en de aanvraagkosten kunt uitsplitsen. Azure Cosmos DB biedt aanvraagkosten voor elke bewerking, zodat elke bewerkingskosten kunnen worden opgeslagen vanuit het antwoord en vervolgens worden gebruikt voor analyse.

  4. U kunt de ingerichte doorvoer elastisch omhoog en omlaag schalen, omdat u aan uw workloadbehoeften moet voldoen.

  5. U kunt regio's toevoegen en verwijderen die zijn gekoppeld aan uw Azure Cosmos DB-account wanneer u dat nodig hebt en kosten beheert.

  6. Zorg ervoor dat u zelfs gegevens en workloads over logische partities van uw containers hebt gedistribueerd. Als u een ongelijke partitieverdeling hebt, kan dit leiden tot een hogere hoeveelheid doorvoer dan de waarde die nodig is. Als u vaststelt dat u een scheve distributie hebt, raden we u aan de workload gelijkmatig over de partities te distribueren of de gegevens opnieuw te partitioneren.

  7. Als u veel containers hebt en deze containers geen SLA's nodig hebben, kunt u de aanbieding op basis van de database gebruiken voor de gevallen waarin de SLA's per containerdoorvoer niet van toepassing zijn. U moet bepalen welke Azure Cosmos DB-containers u wilt migreren naar de doorvoeraanbieding op databaseniveau en deze vervolgens migreren met behulp van een oplossing op basis van een wijzigingenfeed.

  8. Overweeg het gebruik van de gratis laag van Azure Cosmos DB (gratis voor één jaar), Probeer Azure Cosmos DB (maximaal drie regio's) of downloadbare Azure Cosmos DB-emulator voor ontwikkel-/testscenario's. Door deze opties voor test-dev te gebruiken, kunt u uw kosten aanzienlijk verlagen.

  9. U kunt nog meer workloadspecifieke kostenoptimalisaties uitvoeren, bijvoorbeeld het vergroten van batchgrootte, taakverdelingsleesbewerkingen in meerdere regio's en het ontdubbelen van gegevens, indien van toepassing.

  10. Met gereserveerde azure Cosmos DB-capaciteit kunt u gedurende drie jaar aanzienlijke kortingen krijgen voor maximaal 65%. Het gereserveerde capaciteitsmodel van Azure Cosmos DB is een toezegging vooraf voor aanvraageenheden die in de loop van de tijd nodig zijn. De kortingen worden gelaagd, zodat hoe meer aanvraageenheden u gedurende een langere periode gebruikt, hoe meer uw korting is. Deze kortingen worden onmiddellijk toegepast. Alle RU's die boven uw ingerichte waarden worden gebruikt, worden in rekening gebracht op basis van de niet-gereserveerde capaciteitskosten. Zie gereserveerde azure Cosmos DB-capaciteit) voor meer informatie. Overweeg gereserveerde capaciteit aan te schaffen om de ingerichte doorvoerkosten verder te verlagen.

Volgende stappen

Vervolgens kunt u verdergaan met meer informatie over kostenoptimalisatie in Azure Cosmos DB met de volgende artikelen: