Geïntegreerde Azure Cosmos DB-cache - Overzicht

  • Van toepassing op: ✅ NoSQL

De geïntegreerde Cache van Azure Cosmos DB is een in-memory cache waarmee u beheerbare kosten en lage latentie kunt garanderen wanneer uw aanvraagvolume groeit. De geïntegreerde cache is eenvoudig in te stellen en u hoeft geen tijd te besteden aan het schrijven van aangepaste code voor het ongeldig maken van de cache of het beheren van back-endinfrastructuur.

De geïntegreerde cache maakt gebruik van de toegewezen gateway binnen uw Azure Cosmos DB-account. Wanneer u uw toegewezen gateway inricht, kunt u het aantal knooppunten en de knooppuntgrootte kiezen op basis van het aantal kernen en geheugen dat nodig is voor uw workload. Elk toegewezen gatewayknooppunt heeft een afzonderlijke geïntegreerde cache van de andere.

Een geïntegreerde cache wordt automatisch geconfigureerd in de toegewezen gateway. De geïntegreerde cache heeft twee onderdelen:

  • Een itemcache voor puntleesbewerkingen
  • Een querycache voor query's

De geïntegreerde cache is een read-through-, write-through-cache met een LRU-verwijderingsbeleid (Least Recently Used). De itemcache en querycaches delen dezelfde capaciteit binnen de geïntegreerde cache en het LRU-verwijderingsbeleid is van toepassing op beide. Gegevens worden strikt uit de cache verwijderd op basis van wanneer ze het laatst zijn gebruikt, ongeacht of het een puntlees- of query is. De gegevens in de cache binnen elk knooppunt zijn afhankelijk van de gegevens die onlangs zijn geschreven of gelezen door dat specifieke knooppunt. Als een item of query op één knooppunt is gecached, is het niet automatisch gecached op de andere knooppunten.

Opmerking

Hebt u feedback over de geïntegreerde cache? We willen het horen! U kunt feedback rechtstreeks delen met het technische team van Azure Cosmos DB: cosmoscachefeedback@microsoft.com

Workloads die profiteren van de geïntegreerde cache

Het belangrijkste doel van de geïntegreerde cache is om de kosten voor leesintensieve workloads te verlagen. Lage latentie, hoewel nuttig, is niet het belangrijkste voordeel van de geïntegreerde cache, omdat Azure Cosmos DB al snel is zonder caching.

Puntlezingen en opvragen die de geïntegreerde cache raken, hebben een verbruik van Request Units (RU) van nul. Cachetreffers hebben een veel lagere kosten per bewerking dan leesbewerkingen uit de back-enddatabase.

Workloads die aan de volgende kenmerken voldoen, moeten evalueren of de geïntegreerde cache de kosten verlaagt:

  • Leesintensieve workloads
  • Veel herhaalde punten lezen over grote items
  • Veel herhaalde hoge RU-query's
  • Dynamische partitiesleutel voor leesbewerkingen

De grootste factor in verwachte besparingen is de mate waarin leesbewerkingen zich herhalen. Als uw workload binnen een korte periode consistent hetzelfde punt leest of query's uitvoert, is dit een uitstekende kandidaat voor de geïntegreerde cache. Wanneer u de geïntegreerde cache gebruikt voor herhaalde leesbewerkingen, gebruikt u alleen RU's voor de eerste leesbewerking. Daaropvolgende leesbewerkingen die worden gerouteerd via hetzelfde toegewezen gatewayknooppunt (binnen het MaxIntegratedCacheStaleness venster en als de gegevens niet zijn verwijderd) gebruiken geen doorvoer.

Sommige workloads moeten niet rekening houden met de geïntegreerde cache, waaronder:

  • Schrijfintensieve workloads
  • Zelden herhaalde puntsgewijze leesoperaties of opvragingen
  • Workloads die de wijzigingenfeed lezen

Itemcache

Itemcache wordt gebruikt voor puntleesbewerkingen (sleutel/waarde opzoeken op basis van de item-id en partitiesleutel).

De itemcache vullen

  • Nieuwe schrijfbewerkingen, updates en verwijderingen worden automatisch ingevuld in de itemcache van het knooppunt waar de aanvraag doorheen wordt gerouteerd.
  • Items uit punt-leesverzoeken waarin het item nog niet in de cache zit (cache-miss) van het knooppunt waar de aanvraag doorheen is geleid, worden toegevoegd aan de itemcache.
  • Leesaanvragen voor meerdere items, zoals ReadMany, zouden de querycache als een set moeten vullen in plaats van de itemcache met afzonderlijke items.
  • Aanvragen die deel uitmaken van een transactionele batch of in de bulkmodus , vullen de itemcache niet in.

Invalidatie en verwijdering van itemcache

Omdat elk knooppunt een onafhankelijke cache heeft, is het mogelijk dat items ongeldig of verwijderd zijn in de cache van één knooppunt en niet de andere. Items in de cache van een bepaald knooppunt worden ongeldig en verwijderd op basis van de volgende criteria:

  • Item bijwerken of verwijderen
  • Minst recent gebruikt (LRU)
  • De cacheretentietijd (met andere woorden, de MaxIntegratedCacheStaleness)

Querycache

De querycache wordt gebruikt om query's in de cache op te cachen. De querycache transformeert een query in een sleutel-/waardezoekactie waarbij de sleutel de querytekst is en de waarde de queryresultaten is. De geïntegreerde cache heeft geen query-engine; alleen de sleutel-/waardezoekfunctie voor elke query wordt opgeslagen. Queryresultaten worden opgeslagen als een set en de cache houdt afzonderlijke items niet bij. Een bepaald item kan meerdere keren worden opgeslagen in de querycache als dit wordt weergegeven in de resultatenset van meerdere query's. Updates voor de onderliggende items worden niet weergegeven in de queryresultaten, tenzij de maximale veroudering van de geïntegreerde cache voor de query is bereikt en de query wordt uitgevoerd vanuit de back-end-database.

De querycache vullen

  • Als de cache geen resultaat heeft voor die query (cache-miss) op het knooppunt waar het doorheen is gerouteerd, wordt de query naar de backend verzonden. Nadat de query is uitgevoerd, worden de resultaten voor die query opgeslagen in de cache.
  • Query's met dezelfde shape, maar verschillende parameters of aanvraagopties die van invloed zijn op de resultaten (bijvoorbeeld het maximum aantal items) worden opgeslagen als hun eigen sleutel/waardepaar.
  • Leesaanvragen voor meerdere items, zoals ReadMany, vullen de querycache. ReadMany resultaten worden opgeslagen als een set en aanvragen met verschillende invoer worden opgeslagen als hun eigen sleutel/waardepaar.

Verwijdering van querycache

Query-cache-verwijdering is gebaseerd op het knooppunt waar de aanvraag doorheen is geleid. Het is mogelijk dat query's kunnen worden verwijderd of vernieuwd op één knooppunt en niet op de andere knooppunten.

  • Minst recent gebruikt (LRU)
  • De cacheretentietijd (met andere woorden, de MaxIntegratedCacheStaleness)

Werken met de querycache

U hebt geen speciale code nodig bij het werken met de querycache, zelfs als uw query's meerdere pagina's met resultaten hebben. De aanbevolen procedures en code voor het paginering van query's zijn hetzelfde, ongeacht of uw query de geïntegreerde cache bereikt of wordt uitgevoerd op de back-endquery-engine.

De querycache slaat doorgaantokens voor queries automatisch op, indien van toepassing. Als u een query met meerdere pagina's met resultaten hebt, hebben alle pagina's die zijn opgeslagen in de geïntegreerde cache een RU-kosten van nul. Als voor volgende pagina's met queryresultaten back-enduitvoering is vereist, hebben ze een vervolgtoken van de vorige pagina, zodat ze het dupliceren van eerder werk kunnen voorkomen.

Important

Geïntegreerde cache-exemplaren binnen verschillende toegewezen gatewayknooppunten hebben onafhankelijke caches van elkaar. Als gegevens in de cache worden opgeslagen in één knooppunt, worden deze niet per se in de cache opgeslagen in de andere knooppunten. Meerdere pagina's van dezelfde query worden niet gegarandeerd doorgestuurd naar hetzelfde toegewezen gatewayknooppunt.

Geïntegreerde cacheconsistentie

De geïntegreerde cache ondersteunt alleen leesaanvragen met sessie- en uiteindelijke consistentie . Als een leesbewerking consistent voorvoegsel, gebonden veroudering of sterke consistentie heeft, wordt de geïntegreerde cache omzeild en wordt deze geleverd vanuit de back-end.

De eenvoudigste manier om sessie- of uiteindelijke consistentie voor alle leesbewerkingen te configureren, is door deze in te stellen op accountniveau. Als u echter alleen wilt dat sommige leesbewerkingen een specifieke consistentie hebben, kunt u ook consistentie op aanvraagniveau configureren.

Opmerking

Schrijfaanvragen met andere consistenties vullen de cache nog steeds in, maar als u wilt lezen uit de cache, moet de aanvraag sessie of uiteindelijke consistentie hebben.

Sessieconsistentie

Sessieconsistentie is het meest gebruikte consistentieniveau voor zowel één regio als wereldwijd gedistribueerde Azure Cosmos DB-accounts. Met sessieconsistentie kunnen individuele clientsessies hun eigen schrijfbewerkingen lezen. Leesbewerkingen met sessieconsistentie die geen overeenkomend sessietoken hebben, brengen RU-kosten in rekening. Dit omvat de eerste aanvraag voor een bepaald item of een bepaalde query wanneer de clienttoepassing wordt gestart of opnieuw wordt gestart, tenzij u expliciet een geldig sessietoken doorgeeft. Clients buiten de sessie die schrijfbewerkingen uitvoeren, zien uiteindelijke consistentie wanneer ze de geïntegreerde cache gebruiken.

MaxGeïntegreerdeCacheVeroudering

Het MaxIntegratedCacheStaleness is de maximaal acceptabele veroudering voor gecachte puntlezingen en query's, ongeacht de geselecteerde consistentie. De MaxIntegratedCacheStaleness kan worden geconfigureerd op aanvraagniveau. Als u bijvoorbeeld een MaxIntegratedCacheStaleness van 2 uur instelt, retourneert uw aanvraag alleen gegevens in de cache als de gegevens minder dan 2 uur oud zijn. Als u de kans wilt vergroten dat herhaalde leesbewerkingen gebruikmaken van de geïntegreerde cache, moet u het MaxIntegratedCacheStaleness zo hoog instellen als uw bedrijfsvereisten toestaan.

De MaxIntegratedCacheStaleness, wanneer deze is geconfigureerd voor een aanvraag die uiteindelijk de cache invult, heeft geen invloed op hoelang die aanvraag in de cache wordt opgeslagen. MaxIntegratedCacheStaleness dwingt consistentie af wanneer u probeert gegevens in de cache te lezen. Er is geen algemene TTL- of cacheretentie-instelling, dus gegevens worden alleen uit de cache verwijderd als de geïntegreerde cache vol is of als een nieuwe leesbewerking wordt uitgevoerd met een lagere MaxIntegratedCacheStaleness leeftijd dan de leeftijd van de huidige vermelding in de cache.

Dit is een verbetering van de werking van de meeste caches en biedt de volgende andere aanpassingen:

  • U kunt verschillende verouderingsvereisten instellen voor elk lees- of querypunt
  • Verschillende clients, zelfs als ze hetzelfde punt lezen of query uitvoeren, kunnen verschillende MaxIntegratedCacheStaleness waarden configureren
  • Als u leesconsistentie voor gegevens in de cache wilt wijzigen, heeft het wijzigen MaxIntegratedCacheStaleness direct invloed op leesconsistentie

Opmerking

De minimumwaarde MaxIntegratedCacheStaleness is 0 en de maximumwaarde is 10 jaar. Wanneer deze niet expliciet is geconfigureerd, wordt de MaxIntegratedCacheStaleness standaardwaarde ingesteld op 5 minuten.

Bekijk het volgende voorbeeld om meer inzicht te krijgen in de MaxIntegratedCacheStaleness parameter:

Time Request Antwoord
t = 0 sec Query A uitvoeren met MaxIntegratedCacheStaleness = 30 seconden Resultaten retourneren van back-end database (normale RU-kosten) en cache invullen
t = 0 sec Query B uitvoeren met MaxIntegratedCacheStaleness = 60 seconden Resultaten retourneren van back-end database (normale RU-kosten) en cache invullen
t = 20 sec. Query A uitvoeren met MaxIntegratedCacheStaleness = 30 seconden Resultaten retourneren van geïntegreerde cache (0 RU-kosten)
t = 20 sec. Query B uitvoeren met MaxIntegratedCacheStaleness = 60 seconden Resultaten retourneren van geïntegreerde cache (0 RU-kosten)
t = 40 sec. Query A uitvoeren met MaxIntegratedCacheStaleness = 30 seconden Resultaten retourneren van back-enddatabase (normale RU-kosten) en cache vernieuwen
t = 40 sec. Query B uitvoeren met MaxIntegratedCacheStaleness = 60 seconden Resultaten retourneren van geïntegreerde cache (0 RU-kosten)
t = 50 sec. Query B uitvoeren met MaxIntegratedCacheStaleness = 20 seconden Resultaten retourneren van back-enddatabase (normale RU-kosten) en cache vernieuwen

Zie MaxIntegratedCacheStaleness voor meer informatie over het configureren.

De geïntegreerde cache omzeilen

De geïntegreerde cache heeft een beperkte opslagcapaciteit die wordt bepaald door de toegewezen gateway-SKU die is ingericht. Standaard worden alle aanvragen van clients die zijn geconfigureerd met de specifieke gateway-verbindingstekst via de geïntegreerde cache geleid en nemen zij cacheruimte in. U kunt bepalen welke items en query's in de cache worden opgeslagen met de optie voor het overslaan van geïntegreerde cacheaanvragen. Deze aanvraagoptie is handig voor schrijf- of leesaanvragen die naar verwachting niet regelmatig worden herhaald.

Door de geïntegreerde cache voor items met onregelmatige toegang te omzeilen, bespaart u de cacheruimte voor items met meer herhalingen, waardoor ru-besparingspotentieel toeneemt en verwijderingen worden verminderd. Aanvragen die de cache omzeilen, worden nog steeds gerouteerd via de toegewezen gateway. Deze aanvragen worden verwerkt vanuit de back-end en kosten-RU's.

Zie De geïntegreerde cache omzeilen voor meer informatie over het omzeilen van de geïntegreerde cache.

Metrics

Het is handig om enkele belangrijke DedicatedGateway en IntegratedCache metrische gegevens voor de geïntegreerde cache te bewaken. Zie Ondersteunde metrische gegevens voor Microsoft.DocumentDB/DatabaseAccounts voor meer informatie over deze metrische gegevens.

Alle bestaande metrische gegevens zijn standaard beschikbaar vanuit metrische gegevens in De Azure-portal (niet de klassieke metrische gegevens):

Schermopname van Azure Portal met de locatie van metrische gegevens van geïntegreerde cache.

Metrische gegevens zijn een gemiddelde, maximum of som voor alle toegewezen gatewayknooppunten. Als u bijvoorbeeld een toegewezen gatewaycluster met vijf knooppunten inricht, weerspiegelen de metrische gegevens de geaggregeerde waarde voor alle vijf knooppunten. Het is niet mogelijk om de metrische waarden voor elk afzonderlijk knooppunt te bepalen.

Veelvoorkomende problemen oplossen

In de volgende voorbeelden ziet u hoe u fouten kunt opsporen in enkele veelvoorkomende scenario's:

Ik kan niet zien of mijn toepassing gebruikmaakt van de toegewezen gateway

Controleer de DedicatedGatewayRequests. Deze metrische waarde omvat alle aanvragen die gebruikmaken van de toegewezen gateway, ongeacht of ze de geïntegreerde cache bereiken. Als uw toepassing gebruikmaakt van de standaardgateway of de directe modus met uw oorspronkelijke verbindingsreeks, ziet u geen foutbericht, maar is het DedicatedGatewayRequests nul. Als uw toepassing gebruikmaakt van de directe modus met uw toegewezen gatewayverbindingsreeks, ziet u er mogelijk nog een paar DedicatedGatewayRequests.

Ik kan niet zien of mijn aanvragen de geïntegreerde cache raken

Controleer de IntegratedCacheItemHitRate en IntegratedCacheQueryHitRate. Als beide waarden nul zijn, raken aanvragen niet op de geïntegreerde cache. Controleer of u de toegewezen gateway gebruikt verbindingsreeks, verbinding maakt met de gatewaymodus en of u sessie- of uiteindelijke consistentie gebruikt.

Ik wil weten of mijn toegewezen gateway te klein is

Controleer de IntegratedCacheItemHitRate en IntegratedCacheQueryHitRate. Hoge waarden (bijvoorbeeld voorgaande 0.7-0.8) zijn een goed teken dat de toegewezen gateway groot genoeg is.

Als de IntegratedCacheItemHitRate of IntegratedCacheQueryHitRatelaag is, kijk dan naar de IntegratedCacheEvictedEntriesSize. Als de waarde IntegratedCacheEvictedEntriesSize hoog is, kan dit betekenen dat een grotere toegewezen gateway nuttig zou zijn. U kunt experimenteren door de toegewezen gateway groter te maken en de nieuwe IntegratedCacheItemHitRate en IntegratedCacheQueryHitRate. Als een grotere toegewezen gateway de IntegratedCacheItemHitRate of IntegratedCacheQueryHitRateniet verbetert, is het mogelijk dat leesbewerkingen zichzelf niet genoeg herhalen om de geïntegreerde cache te beïnvloeden.

Ik wil weten of mijn toegewezen gateway te groot is

Het is moeilijker om te meten of een toegewezen gateway te groot is dan om te meten of een toegewezen gateway te klein is. Over het algemeen moet u klein beginnen en langzaam de toegewezen gatewaygrootte vergroten totdat de IntegratedCacheItemHitRate verbetering IntegratedCacheQueryHitRate wordt gestopt. In sommige gevallen is slechts één van de twee metrische gegevens voor cachetreffers belangrijk, niet beide. Als uw workload bijvoorbeeld voornamelijk query's is, in plaats van puntleesbewerkingen, is het IntegratedCacheQueryHitRate veel belangrijker dan de IntegratedCacheItemHitRate.

Als de meeste gegevens uit de cache worden verwijderd vanwege het overschrijden van de MaxIntegratedCacheStaleness, in plaats van LRU, is uw cache mogelijk groter dan vereist. Als IntegratedCacheItemExpirationCount en IntegratedCacheQueryExpirationCount gecombineerd bijna zo groot zijn als IntegratedCacheEvictedEntriesSize, kunt u experimenteren met een kleinere toegewezen gatewaygrootte en prestaties vergelijken.

Ik wil weten of ik meer toegewezen gatewayknooppunten moet toevoegen

Als latentie onverwacht hoog is, hebt u mogelijk meer toegewezen gatewayknooppunten nodig in plaats van grotere knooppunten. Controleer het DedicatedGatewayCPUUsage en DedicatedGatewayMemoryUsage om te bepalen of het toevoegen van meer toegewezen gatewayknooppunten de latentie zou verminderen. Het is goed om er rekening mee te houden dat omdat alle exemplaren van de geïntegreerde cache onafhankelijk zijn van elkaar, het toevoegen van meer toegewezen gatewayknooppunten de .IntegratedCacheEvictedEntriesSize Het toevoegen van meer knooppunten verbetert echter het aanvraagvolume dat uw toegewezen gatewaycluster kan verwerken.

Volgende stappen 

  • Last updated on