Aanvraagkosten optimaliseren in Azure Cosmos DB

  • Artikel

VAN TOEPASSING OP: Nosql MongoDB Cassandra Gremlin Tabel

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 na te denken over en het beheren van hardwareresources, kunt u een aanvraageenheid (RU) zien 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 ook de effectiviteit van uw optimalisaties te evalueren. U kunt deze kosten ophalen met behulp van de Azure Portal of door het antwoord te inspecteren dat vanuit Azure Cosmos DB is teruggestuurd via een van de SDK's. Zie De kosten voor de aanvraageenheid zoeken in Azure Cosmos DB voor gedetailleerde instructies over hoe u dit kunt bereiken.

Gegevens lezen: puntlees- en query's

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

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

Rol van het consistentieniveau

Wanneer u de consistentieniveausstrong of bounded 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 leespunt
1 kB 1 RU
100 kB Tien aanvraageenheden

Omdat puntleesbewerkingen (sleutel-/waardezoekacties voor 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 indien mogelijk kunt ophalen met een puntgelezen (in plaats van een query).

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 puntgelezen. Zie Een item lezen in Azure Cosmos DB voor 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 zoekopdrachten voor de index, de compilatietijd van de query, enzovoort. Details. Azure Cosmos DB garandeert dat dezelfde query bij uitvoering op dezelfde gegevens altijd hetzelfde aantal aanvraageenheden verbruikt, zelfs bij herhaalde uitvoeringen. Het queryprofiel met behulp van metrische gegevens voor 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, dat komt omdat query's zo snel mogelijk worden uitgevoerd op basis van de beschikbare RU's. Mogelijk ziet u dat een query wordt uitgevoerd in meerdere pagina's/retouren tussen server en client. 10.000 items kunnen bijvoorbeeld worden geretourneerd als meerdere pagina's, die elk in rekening worden gebracht op basis van de berekening die voor die pagina is 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 query wordt uitgevoerd in de UDF en het aantal verbruikte RU's, is door de metrische querygegevens in te schakelen. Als u de .NET SDK gebruikt, vindt u hier metrische voorbeeldgegevens voor query's die door de SDK worden geretourneerd:

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  

Best practices voor het optimaliseren van kosten van query's

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

  • Meerdere entiteitstypen colocate

    Probeer meerdere entiteitstypen in één of kleiner aantal containers te koppelen. 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 in dezelfde container te plaatsen, kan het aantal retouren naar het netwerk verminderen om relaties tussen records op te lossen. Het verhoogt dus de end-to-end-prestaties, maakt atomische transacties via meerdere records mogelijk voor een grotere gegevensset en verlaagt als gevolg hiervan de kosten. Als het lastig is om meerdere entiteitstypen te verplaatsen binnen een enkel of kleiner aantal containers, meestal omdat u een bestaande toepassing migreert en u geen codewijzigingen wilt aanbrengen, kunt u overwegen om doorvoer op databaseniveau in te richten.

  • Meten en afstemmen voor lagere aanvraageenheden/tweede gebruik

    De complexiteit van een query is van invloed op het aantal aanvraageenheden (RU's) dat voor een bewerking wordt verbruikt. 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 ingerichte 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 vereist 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, gegarandeerde lage latentie en hoge beschikbaarheid op elke schaal bieden. Aanvraageenheden vertegenwoordigen de genormaliseerde valuta die de redenering vereenvoudigt over het aantal resources dat een toepassing nodig heeft.

Aanvraagkosten die in de aanvraagheader worden geretourneerd, geven de kosten van een bepaalde query aan. Als een query bijvoorbeeld 1000 items van 1 kB retourneert, zijn de kosten van de bewerking 1000. Daarom honoreert de server binnen één seconde slechts twee van 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 grootte van het item.
  • Het aantal eigenschappen dat wordt gedekt door het indexeringsbeleid en dat moet worden geïndexeerd.

Het invoegen van een item van 1 kB zonder indexering kost 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 dat wordt geïndexeerd, te rechten te geven.

  • 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 te plaatsen en een verwijzing (of koppeling) naar de blob op te slaan in het item dat u naar Azure Cosmos DB schrijft.
  • Het optimaliseren van uw indexeringsbeleid om alleen de eigenschappen te indexeren waarop uw query's filteren, kan een enorm verschil maken in de RU's die worden gebruikt door uw schrijfbewerkingen. Wanneer u een nieuwe container maakt, indexeert het standaardindexeringsbeleid elke eigenschap die in uw items wordt gevonden. 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.

Bij het uitvoeren van bulkopname van gegevens wordt 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 desgewenst ook Azure Data Factory gebruiken die op dezelfde bibliotheek is gebouwd.

Volgende stappen

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