Delen via

Aanvraagkosten optimaliseren in Azure Cosmos DB

  • Artikel

VAN TOEPASSING OP: NoSQL MongoDB Cassandra Gremlin Tafel

In dit artikel wordt beschreven hoe lees- en schrijfaanvragen worden omgezet in aanvraageenheden en hoe u de kosten van deze aanvragen kunt optimaliseren. Leesbewerkingen omvatten puntleesbewerkingen en query's. Schrijfbewerkingen zijn onder andere invoegen, vervangen, verwijderen en upsert van items.

Azure Cosmos DB biedt een uitgebreide set databasebewerkingen die worden uitgevoerd op de items in een container. De kosten die gepaard gaan met elke bewerking hangen af van de CPU, de IO en het geheugen, vereist om de bewerking uit te voeren. In plaats van aan hardwareresources te denken en te beheren, kunt u een aanvraageenheid (RU) beschouwen als één meting voor de resources die nodig zijn om verschillende databasebewerkingen uit te voeren om een aanvraag te verwerken.

De RU-kosten van een aanvraag meten

Het is belangrijk om de RU-kosten van uw aanvragen te meten om inzicht te hebben in de werkelijke kosten en om de effectiviteit van uw optimalisaties te evalueren. U kunt deze kosten ophalen met behulp van Azure Portal of het antwoord controleren dat vanuit Azure Cosmos DB is verzonden via een van de SDK's. Zie De kosten voor aanvraageenheden in Azure Cosmos DB vinden voor gedetailleerde instructies over hoe u dit kunt bereiken.

Gegevens lezen: punten lezen en query's

Leesbewerkingen in Azure Cosmos DB zijn doorgaans als volgt gerangschikt van snelste/meest efficiënte naar trager/minder efficiënt in termen van RU-verbruik:

  • Puntleesbewerkingen (sleutel/waarde opzoeken op één item-id en partitiesleutel).
  • Query's uitvoeren met een filtercomponent binnen één partitiesleutel.
  • Query's uitvoeren zonder gelijkheids- of bereikfiltercomponent voor een eigenschap.
  • Query zonder filters.

Rol van het consistentieniveau

Wanneer u de consistentieniveaus sterke of gebonden veroudering gebruikt, worden de RU-kosten van een leesbewerking (punt lezen of query) verdubbeld.

Puntleesbewerkingen

De enige factor die van invloed is op de RU-kosten van een puntlee (naast het gebruikte consistentieniveau) is de grootte van het opgehaalde item. In de volgende tabel ziet u de RU-kosten van puntleesbewerkingen voor items die 1 kB en 100 kB groot zijn.

Itemgrootte Kosten van één punt lezen
1 kB 1 RU
100 kB Tien aanvraageenheden

Omdat puntleesbewerkingen (sleutel/waardezoekacties op de item-id en partitiesleutel) het meest efficiënte type leesbewerking zijn, moet u ervoor zorgen dat uw item-id een zinvolle waarde heeft, zodat u uw items kunt ophalen met een puntlee (in plaats van een query) indien mogelijk.

Notitie

In de API voor NoSQL kunnen puntleesbewerkingen alleen worden gemaakt met behulp van de REST API of SDK's. Query's die filteren op de id en partitiesleutel van één item, worden niet beschouwd als een puntleesbewerking. Zie een item lezen in Azure Cosmos DB for NoSQL voor een voorbeeld met behulp van de .NET SDK.

Query's

Aanvraageenheden voor query's zijn afhankelijk van een aantal factoren. Bijvoorbeeld het aantal Azure Cosmos DB-items dat is geladen/geretourneerd, het aantal opzoekacties ten opzichte van de index, de tijd voor het compileren van query's, enzovoort. Azure Cosmos DB garandeert dat dezelfde query wanneer deze wordt uitgevoerd op dezelfde gegevens altijd hetzelfde aantal aanvraageenheden verbruikt, zelfs bij herhaalde uitvoeringen. Het queryprofiel met behulp van metrische gegevens over queryuitvoering geeft u een goed idee van hoe de aanvraageenheden worden besteed.

In sommige gevallen ziet u mogelijk een reeks van 200 en 429 antwoorden, en variabele aanvraageenheden in een gepaginade uitvoering van query's, namelijk omdat query's zo snel mogelijk worden uitgevoerd op basis van de beschikbare RU's. Mogelijk ziet u dat een queryuitvoering opsplitst in meerdere pagina's/retouren tussen de server en de client. Er kunnen bijvoorbeeld 10.000 items worden geretourneerd als meerdere pagina's, elke pagina wordt in rekening gebracht op basis van de berekening die voor die pagina wordt uitgevoerd. Wanneer u optelt op deze pagina's, moet u hetzelfde aantal RU's krijgen als voor de hele query.

Metrische gegevens voor het oplossen van problemen met query's

De prestaties en de doorvoer die wordt verbruikt door query's (inclusief door de gebruiker gedefinieerde functies) zijn meestal afhankelijk van de hoofdtekst van de functie. De eenvoudigste manier om erachter te komen hoeveel tijd de queryuitvoering wordt besteed in de UDF en het aantal verbruikte RU's, is door de metrische querygegevens in te schakelen. Als u de .NET SDK gebruikt, zijn hier voorbeelden van metrische querygegevens die worden geretourneerd door de SDK:

Retrieved Document Count                 :               1              
Retrieved Document Size                  :           9,963 bytes        
Output Document Count                    :               1              
Output Document Size                     :          10,012 bytes        
Index Utilization                        :          100.00 %            
Total Query Execution Time               :            0.48 milliseconds 
  Query Preparation Times 
    Query Compilation Time               :            0.07 milliseconds 
    Logical Plan Build Time              :            0.03 milliseconds 
    Physical Plan Build Time             :            0.05 milliseconds 
    Query Optimization Time              :            0.00 milliseconds 
  Index Lookup Time                      :            0.06 milliseconds 
  Document Load Time                     :            0.03 milliseconds 
  Runtime Execution Times 
    Query Engine Execution Time          :            0.03 milliseconds 
    System Function Execution Time       :            0.00 milliseconds 
    User-defined Function Execution Time :            0.00 milliseconds 
  Document Write Time                    :            0.00 milliseconds 
  Client Side Metrics 
    Retry Count                          :               1              
    Request Charge                       :            3.19 RUs  

Aanbevolen procedures voor het optimaliseren van query's

Houd rekening met de volgende aanbevolen procedures bij het optimaliseren van query's voor kosten:

  • Meerdere entiteitstypen colocate

    Probeer meerdere entiteitstypen binnen één of kleiner aantal containers te koppelen. Deze methode levert niet alleen voordelen op vanuit prijsperspectief, maar ook voor het uitvoeren van query's en transacties. Query's zijn gericht op één container; en atomische transacties via meerdere records via opgeslagen procedures/triggers zijn gericht op een partitiesleutel binnen één container. Door entiteiten binnen dezelfde container te coloceren, kan het aantal netwerkrondes worden verminderd om relaties tussen records op te lossen. Het verhoogt de end-to-end prestaties, maakt atomische transacties mogelijk via meerdere records voor een grotere gegevensset en verlaagt hierdoor de kosten. Als het verplaatsen van meerdere entiteitstypen binnen één of kleiner aantal containers moeilijk is voor uw scenario, meestal omdat u een bestaande toepassing migreert en u geen codewijzigingen wilt aanbrengen. Overweeg dan de doorvoer op databaseniveau in te richten.

  • Meten en afstemmen op lagere aanvraageenheden/tweede gebruik

    De complexiteit van een query heeft invloed op het aantal aanvraageenheden (RU's) dat wordt verbruikt voor een bewerking. Het aantal predicaten, de aard van de predicaten, het aantal UDF's en de grootte van de brongegevensset. Al deze factoren beïnvloeden de kosten van querybewerkingen.

Azure Cosmos DB biedt voorspelbare prestaties in termen van doorvoer en latentie met behulp van een ingericht doorvoermodel. De ingerichte doorvoer wordt weergegeven in termen van aanvraageenheden per seconde of RU/s. Een aanvraageenheid (RU) is een logische abstractie van rekenresources, zoals CPU, geheugen, IO, enzovoort, die nodig zijn om een aanvraag uit te voeren. De ingerichte doorvoer (RU's) wordt gereserveerd en toegewezen aan uw container of database om voorspelbare doorvoer en latentie te bieden. Met ingerichte doorvoer kan Azure Cosmos DB voorspelbare en consistente prestaties bieden, gegarandeerde lage latentie en hoge beschikbaarheid op elke schaal. Aanvraageenheden vertegenwoordigen de genormaliseerde valuta die de redenering vereenvoudigt over het aantal resources dat een toepassing nodig heeft.

De aanvraagkosten die in de aanvraagheader worden geretourneerd, geven de kosten van een bepaalde query aan. Als een query bijvoorbeeld 1000 1 KB-items retourneert, zijn de kosten van de bewerking 1000. Daarom eert de server binnen één seconde slechts twee dergelijke aanvragen voordat de frequentie van volgende aanvragen wordt beperkt. Zie het artikel aanvraageenheden en de rekenmachine voor aanvraageenheden voor meer informatie.

Gegevens schrijven

De RU-kosten voor het schrijven van een item zijn afhankelijk van:

  • De itemgrootte.
  • Het aantal eigenschappen dat wordt gedekt door het indexeringsbeleid en moet worden geïndexeerd.

Het invoegen van een item van 1 kB zonder indexeringskosten rond circa 5,5 RU's. Het vervangen van een artikel kost twee keer de kosten die nodig zijn om hetzelfde item in te voegen.

Schrijfbewerkingen optimaliseren

De beste manier om de RU-kosten van schrijfbewerkingen te optimaliseren, is door uw items en het aantal eigenschappen te beveiligen dat wordt geïndexeerd.

  • Het opslaan van zeer grote items in Azure Cosmos DB resulteert in hoge RU-kosten en kan worden beschouwd als een antipatroon. Sla met name geen binaire inhoud of grote stukken tekst op waarop u geen query hoeft uit te voeren. Een best practice is om dit soort gegevens in Azure Blob Storage op te slaan en een verwijzing (of koppeling) op te slaan naar de blob in het item dat u naar Azure Cosmos DB schrijft.
  • Door uw indexeringsbeleid te optimaliseren om alleen de eigenschappen te indexeren waarop uw query's filteren, kan dit een groot verschil maken in de RU's die door uw schrijfbewerkingen worden gebruikt. Wanneer u een nieuwe container maakt, worden met het standaardindexeringsbeleid elke en elke eigenschap in uw items geïndexeert. Hoewel dit een goede standaardinstelling is voor ontwikkelingsactiviteiten, wordt het ten zeerste aanbevolen om uw indexeringsbeleid opnieuw te evalueren en aan te passen wanneer u naar productie gaat of wanneer uw workload aanzienlijk verkeer begint te ontvangen.

Wanneer u bulkopname van gegevens uitvoert, wordt het ook aanbevolen om de Azure Cosmos DB-bibliotheek voor bulkexecutor te gebruiken, omdat deze is ontworpen om het RU-verbruik van dergelijke bewerkingen te optimaliseren. U kunt ook Azure Data Factory gebruiken die is gebouwd op dezelfde bibliotheek.

Volgende stappen

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