Aanvraagkosten optimaliseren in Azure Cosmos DB

VAN TOEPASSING OP: SQL API Cassandra API Gremlin API Table API Azure Cosmos DB-API voor MongoDB

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 omvatten het 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 is verzonden vanuit Azure Cosmos DB via een van de SDK's. Zie De kosten voor aanvraageenheden zoeken in Azure Cosmos DB voor gedetailleerde instructies over hoe u dit kunt bereiken.

Leesgegevens: lees- en query's van punten

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

  • Puntleesbewerkingen (sleutel/waardezoekactie 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's uitvoeren 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 puntgelezen (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) het meest efficiënte type leesbewerking zijn, moet u ervoor zorgen dat uw item-id een zinvolle waarde heeft, zodat u uw items indien mogelijk kunt ophalen met een puntleesteken (in plaats van een query).

Query's

Aanvraageenheden voor query's zijn afhankelijk van een aantal factoren. Bijvoorbeeld het aantal Azure Cosmos-items dat is geladen/geretourneerd, het aantal zoekopdrachten op basis 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 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, omdat query's zo snel mogelijk worden uitgevoerd op basis van de beschikbare RU's. Mogelijk ziet u dat een queryuitvoering inbreekt in meerdere pagina's/retouren tussen server en 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 deze pagina's optelt, krijgt u hetzelfde aantal RU's als voor de hele query.

Metrische gegevens voor het oplossen van problemen met query's

De prestaties en de doorvoer die worden 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, worden hier voorbeeldquerygegevens 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 op te nemen. Deze methode levert niet alleen voordelen op vanuit een 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 verplaatsen, kan het aantal retouren naar het netwerk verminderen om relaties tussen records op te lossen. Hierdoor worden de end-to-end-prestaties verhoogd, worden atomische transacties via meerdere records voor een grotere gegevensset mogelijk, waardoor de kosten worden verlaagd. Als het coloceren 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, moet u overwegen om 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 gebruikt voor een bewerking. Het aantal predicaten, de aard van de predicaten, het aantal UDF's en de grootte van de brongegevensset. Al deze factoren zijn van invloed op 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 items van 1000 kB retourneert, zijn de kosten van de bewerking 1000. Als zodanig, binnen één seconde, de server honoreert slechts twee dergelijke aanvragen voordat frequentiebeperking volgende aanvragen. 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 van ongeveer 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 beheren 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's 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 verbruikt. Bij het maken van een nieuwe container indexeert de standaardindexeringsbeleid elk en elke eigenschap in uw items. 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 gegevens bulksgewijs opneemt, wordt het ook aanbevolen om de Azure Cosmos DB-bibliotheek voor bulkuitvoering 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: