Dela via

Azure Cosmos DB-integrerad cache – Översikt

  • Artikel

GÄLLER FÖR: NoSQL

Azure Cosmos DB-integrerad cache är en minnesintern cache som hjälper dig att säkerställa hanterbara kostnader och låg svarstid när din begärandevolym växer. Den integrerade cachen är enkel att konfigurera och du behöver inte ägna tid åt att skriva anpassad kod för cacheintegrering eller hantering av serverdelsinfrastruktur. Den integrerade cachen använder den dedikerade gatewayen i ditt Azure Cosmos DB-konto. När du etablerar din dedikerade gateway kan du välja antalet noder och nodstorleken baserat på antalet kärnor och minne som behövs för din arbetsbelastning. Varje dedikerad gateway-nod har en separat integrerad cache från de andra.

En integrerad cache konfigureras automatiskt i den dedikerade gatewayen. Den integrerade cachen har två delar:

  • En objektcache för punktläsningar
  • En frågecachen för frågor

Den integrerade cachen är en genomläst, genomskrivningscachen med en borttagningsprincip för minst nyligen använda (LRU). Objektcache- och frågecachen delar samma kapacitet i den integrerade cachen och LRU-borttagningsprincipen gäller för båda. Data avlägsnas från cachen strikt baserat på när de senast användes, oavsett om det är en punktläsning eller fråga. Cachelagrade data inom varje nod beror på de data som nyligen har skrivits eller lästs igenom den specifika noden. Om ett objekt eller en fråga cachelagras på en nod cachelagras det inte nödvändigtvis på de andra.

Kommentar

Har du någon feedback om den integrerade cachen? Vi vill höra det! Dela gärna feedback direkt med Azure Cosmos DB-teknikteamet: cosmoscachefeedback@microsoft.com

Arbetsbelastningar som drar nytta av den integrerade cachen

Huvudmålet med den integrerade cachen är att minska kostnaderna för läsintensiva arbetsbelastningar. Låg svarstid, även om det är användbart, är inte den största fördelen med den integrerade cachen eftersom Azure Cosmos DB redan är snabbt utan cachelagring.

Punktläsningar och frågor som når det integrerade cacheminnet har en RU-avgift på 0. Cacheträffar har en mycket lägre kostnad per åtgärd än läsningar från serverdelsdatabasen.

Arbetsbelastningar som passar följande egenskaper bör utvärdera om den integrerade cachen hjälper till att sänka kostnaderna:

  • Läsintensiva arbetsbelastningar
  • Många upprepade punktläsningar på stora objekt
  • Många upprepade höga RU-frågor
  • Frekvent partitionsnyckel för läsningar

Den största faktorn i förväntade besparingar är i vilken grad läsningarna upprepar sig. Om din arbetsbelastning konsekvent kör samma punktläsningar eller frågor inom en kort tidsperiod är det en bra kandidat för den integrerade cachen. När du använder den integrerade cachen för upprepade läsningar använder du endast RU:er för den första läsningen. Efterföljande läsningar som dirigeras via samma dedikerade gatewaynod (i MaxIntegratedCacheStaleness fönstret och om data inte har avlägsnats) använder inte dataflödet.

Vissa arbetsbelastningar bör inte ta hänsyn till den integrerade cachen, inklusive:

  • Skrivintensiva arbetsbelastningar
  • Sällan upprepade punktläsningar eller frågor
  • Arbetsbelastningar som läser ändringsflödet

Objektcache

Objektcache används för punktläsningar (nyckel/värde-uppslag baserat på objekt-ID och partitionsnyckel).

Fylla i objektcachen

  • Nya skrivningar, uppdateringar och borttagningar fylls automatiskt i objektcachen för noden som begäran dirigeras genom
  • Objekt från punktläsningsbegäranden där objektet inte redan finns i cacheminnet (cachemiss) för noden som begäran dirigeras genom läggs till i objektcachen
  • Läs begäranden för flera objekt, till exempel ReadMany, fyller i frågecachen som en uppsättning i stället för objektcacheminnet som enskilda objekt
  • Begäranden som ingår i en transaktionsbatch eller i massläge fyller inte i objektcachen

Ogiltighet och borttagning av objektcache

Eftersom varje nod har en oberoende cache är det möjligt att objekt ogiltigförklaras eller avlägsnas i cacheminnet för en nod och inte de andra. Objekt i cacheminnet för en viss nod ogiltigförklaras och avlägsnas baserat på nedanstående villkor:

  • Uppdatera eller ta bort objekt
  • Minst nyligen använda (LRU)
  • Cachelagringstid (med andra ord MaxIntegratedCacheStaleness)

Frågecache

Frågecachen används för att cachelagrar frågor. Frågecachen omvandlar en fråga till en nyckel/värde-sökning där nyckeln är frågetexten och värdet är frågeresultatet. Den integrerade cachen har ingen frågemotor, den lagrar bara nyckel/värde-sökningen för varje fråga. Frågeresultat lagras som en uppsättning och cacheminnet håller inte reda på enskilda objekt. Ett visst objekt kan lagras i frågecachen flera gånger om det visas i resultatuppsättningen med flera frågor. Uppdateringar av underliggande objekt återspeglas inte i frågeresultat såvida inte den maximala inaktuella cachen för frågan nås och frågan hanteras från serverdelsdatabasen.

Fylla i frågecachen

  • Om cacheminnet inte har något resultat för den frågan (cachemiss) på den nod som den dirigerades genom skickas frågan till serverdelen. När frågan har körts lagrar cacheminnet resultatet för frågan
  • Frågor med samma form men olika parametrar eller alternativ för begäranden som påverkar resultatet (ex. max antal objekt) lagras som ett eget nyckel/värde-par
  • Läs begäranden för flera objekt, till exempel ReadMany, fyller i frågecachen. ReadMany-resultat lagras som en uppsättning och begäranden med olika indata lagras som ett eget nyckel/värde-par

Borttagning av frågecachen

Borttagning av frågecachen baseras på den nod som begäran dirigerades genom. Det är möjligt att frågor kan tas bort eller uppdateras på en nod och inte på de andra.

  • Minst nyligen använda (LRU)
  • Cachelagringstid (med andra ord MaxIntegratedCacheStaleness)

Arbeta med frågecachen

Du behöver inte särskild kod när du arbetar med frågecachen, även om dina frågor har flera sidor med resultat. Metodtipsen och koden för frågenumrering är desamma oavsett om frågan träffar den integrerade cachen eller körs på serverdelsfrågamotorn.

Frågecachen cachelagrar automatiskt frågefortsättningstoken där det är tillämpligt. Om du har en fråga med flera sidor med resultat har alla sidor som lagras i det integrerade cacheminnet en RU-avgift på 0. Om efterföljande sidor med frågeresultat kräver serverdelskörning har de en fortsättningstoken från föregående sida så att de kan undvika att duplicera tidigare arbete.

Viktigt!

Integrerade cacheinstanser i olika dedikerade gatewaynoder har oberoende cacheminnen från varandra. Om data cachelagras inom en nod cachelagras de inte nödvändigtvis i de andra. Flera sidor i samma fråga är inte garanterade att dirigeras till samma dedikerade gatewaynod.

Integrerad cachekonsekvens

Den integrerade cachen stöder skrivskyddade begäranden med endast session och slutlig konsekvens . Om en läsning har konsekvent prefix, begränsad inaktuellhet eller stark konsekvens kringgås den integrerade cachen och hanteras från serverdelen.

Det enklaste sättet att konfigurera antingen session eller slutlig konsekvens för alla läsningar är att ange den på kontonivå. Men om du bara vill att vissa av dina läsningar ska ha en specifik konsekvens kan du även konfigurera konsekvens på begärandenivå.

Kommentar

Skrivbegäranden med andra konsekvenser fyller fortfarande cacheminnet, men för att kunna läsa från cacheminnet måste begäran ha antingen session eller slutlig konsekvens.

Sessionskonsekvens

Sessionskonsekvens är den mest använda konsekvensnivån för både enskilda regioner och globalt distribuerade Azure Cosmos DB-konton. Med sessionskonsekvens kan enskilda klientsessioner läsa sina egna skrivningar. Alla läsningar med sessionskonsekvens som inte har en matchande sessionstoken medför RU-avgifter. Detta inkluderar den första begäran för ett visst objekt eller en fråga när klientprogrammet startas om eller startas om, såvida du inte uttryckligen skickar en giltig sessionstoken. Klienter utanför sessionen som utför skrivningar ser slutlig konsekvens när de använder den integrerade cachen.

MaxIntegratedCacheStaleness

MaxIntegratedCacheStaleness är den maximala godtagbara föråldring för cachelagrade punktläsningar och frågor, oavsett vald konsekvens. MaxIntegratedCacheStaleness Kan konfigureras på begärandenivå. Om du till exempel anger MaxIntegratedCacheStaleness 2 timmar returnerar din begäran endast cachelagrade data om data är mindre än 2 timmar gamla. För att öka sannolikheten för upprepade läsningar som använder den integrerade cachen bör du ange så MaxIntegratedCacheStaleness högt som dina affärskrav tillåter.

, MaxIntegratedCacheStalenessnär den konfigureras för en begäran som slutar fylla i cacheminnet, påverkar inte hur länge den begäran cachelagras. MaxIntegratedCacheStaleness framtvingar konsekvens när du försöker läsa cachelagrade data. Det finns ingen global TTL- eller cachekvarhållningsinställning, så data tas bara bort från cacheminnet om antingen den integrerade cachen är full eller om en ny läsning körs med en lägre MaxIntegratedCacheStaleness tid än den aktuella cachelagrade postens ålder.

Detta är en förbättring jämfört med hur de flesta cacheminnen fungerar och möjliggör följande andra anpassningar:

  • Du kan ange olika krav på inaktuellhet för varje punktläsning eller fråga
  • Olika klienter, även om de kör samma punktläsning eller fråga, kan konfigurera olika MaxIntegratedCacheStaleness värden
  • Om du vill ändra läskonsekvens för cachelagrade data har ändringar MaxIntegratedCacheStaleness en omedelbar effekt på läskonsekvensen

Kommentar

MaxIntegratedCacheStaleness Minimivärdet är 0 och det maximala värdet är 10 år. När den inte har konfigurerats uttryckligen MaxIntegratedCacheStaleness är standardvärdet 5 minuter.

Tänk på följande exempel för att bättre förstå parametern MaxIntegratedCacheStaleness :

Tid Begär Response
t = 0 sek Kör fråga A med MaxIntegratedCacheStaleness = 30 sekunder Returnera resultat från serverdelsdatabasen (normala RU-avgifter) och fyll i cacheminnet
t = 0 sek Kör fråga B med MaxIntegratedCacheStaleness = 60 sekunder Returnera resultat från serverdelsdatabasen (normala RU-avgifter) och fyll i cacheminnet
t = 20 sek Kör fråga A med MaxIntegratedCacheStaleness = 30 sekunder Returnera resultat från integrerad cache (0 RU-avgift)
t = 20 sek Kör fråga B med MaxIntegratedCacheStaleness = 60 sekunder Returnera resultat från integrerad cache (0 RU-avgift)
t = 40 sek Kör fråga A med MaxIntegratedCacheStaleness = 30 sekunder Returnera resultat från serverdelsdatabasen (normala RU-avgifter) och uppdateringscache
t = 40 sek Kör fråga B med MaxIntegratedCacheStaleness = 60 sekunder Returnera resultat från integrerad cache (0 RU-avgift)
t = 50 sek Kör fråga B med MaxIntegratedCacheStaleness = 20 sekunder Returnera resultat från serverdelsdatabasen (normala RU-avgifter) och uppdateringscache

Lär dig hur du konfigurerar MaxIntegratedCacheStaleness.

Kringgå den integrerade cachen

Den integrerade cachen har en begränsad lagringskapacitet som bestäms av den dedikerade gateway-SKU:n som etablerats. Som standard går alla begäranden från klienter som konfigurerats med den dedikerade gatewayen niska veze genom den integrerade cachen och tar upp cacheutrymme. Du kan styra vilka objekt och frågor som cachelagras med alternativet kringgå integrerad cachebegäran. Det här begärandealternativet är användbart för objektskrivningar eller läsbegäranden som inte förväntas upprepas ofta. Om du kringgår den integrerade cachen för objekt med sällan förekommande åtkomst sparas cacheutrymme för objekt med fler upprepningar, vilket ökar RU-lagringspotentialen och minskar borttagningen. Begäranden som kringgår cachen dirigeras fortfarande via den dedikerade gatewayen. Dessa begäranden hanteras från serverdelen och kostnads-RU:er.

Lär dig att kringgå den integrerade cachen.

Mått

Det är bra att övervaka vissa nyckel DedicatedGateway - och IntegratedCache mått för den integrerade cachen. Mer information om dessa mått finns i Mått som stöds för Microsoft.DocumentDB/DatabaseAccounts.

Alla befintliga mått är som standard tillgängliga från Mått i Azure-portalen (inte klassiska mått):

Skärmbild av Azure-portalen som visar platsen för integrerade cachemått.

Mått är antingen ett genomsnitt, maximalt eller en summa för alla dedikerade gatewaynoder. Om du till exempel etablerar ett dedikerat gatewaykluster med fem noder återspeglar måtten det aggregerade värdet för alla fem noderna. Det går inte att fastställa måttvärdena för varje enskild nod.

Felsök vanliga problem

I exemplen nedan visas hur du felsöker några vanliga scenarier:

Jag vet inte om mitt program använder den dedikerade gatewayen

DedicatedGatewayRequestsKontrollera . Det här måttet innehåller alla begäranden som använder den dedikerade gatewayen, oavsett om de når den integrerade cachen. Om ditt program använder standardgatewayen eller direktläget med din ursprungliga niska veze visas inget felmeddelande, men DedicatedGatewayRequests kommer att vara noll. Om ditt program använder direktläge med din dedikerade gateway niska veze kanske du fortfarande ser några DedicatedGatewayRequests.

Jag vet inte om mina begäranden når den integrerade cachen

IntegratedCacheItemHitRate Kontrollera och IntegratedCacheQueryHitRate. Om båda dessa värden är noll når begäranden inte den integrerade cachen. Kontrollera att du använder den dedikerade gatewayen niska veze, ansluter med gatewayläge och använder session eller eventuell konsekvens.

Jag vill veta om min dedikerade gateway är för liten

IntegratedCacheItemHitRate Kontrollera och IntegratedCacheQueryHitRate. Höga värden (till exempel över 0,7-0,8) är ett gott tecken på att den dedikerade gatewayen är tillräckligt stor.

Om eller IntegratedCacheItemHitRate IntegratedCacheQueryHitRateär låg kan du titta på IntegratedCacheEvictedEntriesSize. Om den IntegratedCacheEvictedEntriesSize är hög kan det innebära att en större dedikerad gatewaystorlek skulle vara fördelaktig. Du kan experimentera genom att öka storleken på den dedikerade gatewayen och jämföra den nya IntegratedCacheItemHitRate och IntegratedCacheQueryHitRate. Om en större dedikerad gateway inte förbättrar IntegratedCacheItemHitRate eller IntegratedCacheQueryHitRateär det möjligt att läsningar helt enkelt inte upprepar sig tillräckligt för att den integrerade cachen ska påverkas.

Jag vill veta om min dedikerade gateway är för stor

Det är svårare att mäta om en dedikerad gateway är för stor än den är för att mäta om en dedikerad gateway är för liten. I allmänhet bör du börja små och långsamt öka den dedikerade gatewaystorleken IntegratedCacheItemHitRate tills och IntegratedCacheQueryHitRate sluta förbättras. I vissa fall är endast ett av de två cacheträffarna viktiga, inte båda. Om din arbetsbelastning till exempel främst är frågor, snarare än punktläsningar, är det IntegratedCacheQueryHitRate mycket viktigare än IntegratedCacheItemHitRate.

Om de flesta data tas bort från cacheminnet på grund av att du överskrider MaxIntegratedCacheStaleness, i stället för LRU, kan cachen vara större än vad som krävs. Om IntegratedCacheItemExpirationCount och IntegratedCacheQueryExpirationCount tillsammans är nästan lika stora som IntegratedCacheEvictedEntriesSizekan du experimentera med en mindre dedikerad gatewaystorlek och jämföra prestanda.

Jag vill veta om jag behöver lägga till fler dedikerade gatewaynoder

I vissa fall kan du behöva fler dedikerade gatewaynoder i stället för större noder om svarstiden är oväntat hög. DedicatedGatewayCPUUsage Kontrollera och DedicatedGatewayMemoryUsage för att avgöra om fler dedikerade gatewaynoder skulle minska svarstiden. Det är bra att komma ihåg att eftersom alla instanser av den integrerade cachen är oberoende av varandra, minskar IntegratedCacheEvictedEntriesSizeinte tillägg av mer dedikerade gatewaynoder . Om du lägger till fler noder förbättras dock begärandevolymen som ditt dedikerade gatewaykluster kan hantera.

Nästa steg