Delen via

Geïntegreerde Azure Cosmos DB-cache - Overzicht

  • Artikel

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 in de cache wordt opgeslagen, is het niet noodzakelijkerwijs in de cache opgeslagen op de andere knooppunten.

Notitie

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.

Puntlees- en query's die op de geïntegreerde cache drukken, hebben ru-kosten van 0. 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 puntleesbewerkingen of query's
  • 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 van puntleesaanvragen waarbij het item zich nog niet in de cache bevindt (cachemis) van het knooppunt waar de aanvraag wordt gerouteerd, worden toegevoegd aan de itemcache
  • Leesaanvragen voor meerdere items, zoals ReadMany, vullen de querycache in als een set in plaats van de itemcache als afzonderlijke items
  • Aanvragen die deel uitmaken van een transactionele batch of in de bulkmodus vullen de itemcache niet

Ongeldige en verwijdering van itemcache

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

  • Item bijwerken of verwijderen
  • Minst recent gebruikt (LRU)
  • 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, maar slaat alleen de sleutel-/waardezoekactie voor elke query op. 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 queryresultaten, tenzij de maximaal geïntegreerde caches voor de query worden bereikt en de query wordt uitgevoerd vanuit de back-enddatabase.

De querycache vullen

  • Als de cache geen resultaat heeft voor die query (cachemisser) op het knooppunt dat is gerouteerd, wordt de query verzonden naar de back-end. 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 (ex. max aantal items) worden opgeslagen als hun eigen sleutel/waardepaar
  • Leesaanvragen voor meerdere items, zoals ReadMany, vullen de querycache in. ReadMany-resultaten worden opgeslagen als een set en aanvragen met verschillende invoer worden opgeslagen als hun eigen sleutel/waardepaar

Verwijdering van querycache

Verwijdering van querycache is gebaseerd op het knooppunt dat de aanvraag is doorgestuurd. Het is mogelijk dat query's worden verwijderd of vernieuwd op één knooppunt en niet op de andere knooppunten.

  • Minst recent gebruikt (LRU)
  • 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.

In de querycache worden queryvervolgtokens automatisch in de cache opgeslagen, 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 0. 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.

Belangrijk

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 noodzakelijkerwijs 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.

Notitie

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.

Consistentie Sessie

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.

MaxIntegratedCacheStaleness

Het MaxIntegratedCacheStaleness is de maximaal acceptabele veroudering voor lees- en query's in de cache, ongeacht de geselecteerde consistentie. De MaxIntegratedCacheStaleness kan worden geconfigureerd op aanvraagniveau. Als u bijvoorbeeld een MaxIntegratedCacheStaleness van twee 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

Notitie

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:

Tijd Aanvragen Response
t = 0 sec Query A uitvoeren met MaxIntegratedCacheStaleness = 30 seconden Resultaten retourneren van back-enddatabase (normale RU-kosten) en cache vullen
t = 0 sec Query B uitvoeren met MaxIntegratedCacheStaleness = 60 seconden Resultaten retourneren van back-enddatabase (normale RU-kosten) en cache vullen
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

Meer informatie over het configureren van de MaxIntegratedCacheStaleness.

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 toegewezen gateway verbindingsreeks de geïntegreerde cache doorlopen en cacheruimte innemen. 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.

Meer informatie over het omzeilen van de geïntegreerde cache.

Metrische gegevens

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 onderstaande 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 de DedicatedGatewayRequests modus nul. Als uw toepassing gebruikmaakt van de directe modus met uw toegewezen gateway verbindingsreeks, ziet u mogelijk nog een paarDedicatedGatewayRequests.

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 boven 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 Als u meer knooppunten toevoegt, wordt het aanvraagvolume verbeterd dat uw toegewezen gatewaycluster wel kan verwerken.

Volgende stappen