Integrovaná mezipaměť Azure Cosmos DB – přehled

PLATÍ PRO: NoSQL

Integrovaná mezipaměť Azure Cosmos DB je mezipaměť v paměti, která pomáhá zajistit spravovatelné náklady a nízkou latenci při růstu svazku požadavků. Integrovaná mezipaměť se snadno nastavuje a nemusíte trávit čas psaním vlastního kódu pro zneplatnění mezipaměti nebo správou back-endové infrastruktury. Integrovaná mezipaměť používá vyhrazenou bránu v rámci vašeho účtu služby Azure Cosmos DB. Při zřizování vyhrazené brány můžete zvolit počet uzlů a velikost uzlu na základě počtu jader a paměti potřebných pro vaši úlohu. Každý vyhrazený uzel brány má samostatnou integrovanou mezipaměť od ostatních.

Integrovaná mezipaměť se automaticky konfiguruje v rámci vyhrazené brány. Integrovaná mezipaměť má dvě části:

• Mezipaměť položek pro čtení bodů
• Mezipaměť dotazů pro dotazy

Integrovaná mezipaměť je mezipaměť pro čtení prostřednictvím zápisu se zásadou vyřazení nejméně naposledy použité mezipaměti (LRU). Mezipaměť položek a mezipaměti dotazů sdílejí stejnou kapacitu v rámci integrované mezipaměti a zásady vyřazení LRU platí pro obě. Data se z mezipaměti vyřadí výhradně na základě toho, kdy byla naposledy použita, bez ohledu na to, jestli se jedná o bod čtení nebo dotaz. Data uložená v mezipaměti v rámci každého uzlu závisí na datech, která byla nedávno zapsána nebo přečtená prostřednictvím daného uzlu. Pokud je položka nebo dotaz uloženy v mezipaměti na jednom uzlu, nemusí se nutně ukládat do mezipaměti na ostatních uzlech.

Úlohy, které využívají integrovanou mezipaměť

Hlavním cílem integrované mezipaměti je snížit náklady na úlohy náročné na čtení. Nízká latence, i když je užitečná, není hlavní výhodou integrované mezipaměti, protože Služba Azure Cosmos DB je už rychlá bez ukládání do mezipaměti.

Čtení bodů a dotazy, které narazily na integrovanou mezipaměť, mají poplatky za RU 0. Přístupy do mezipaměti mají mnohem nižší náklady na operace než čtení z back-endové databáze.

Úlohy, které odpovídají následujícím charakteristikám, by se měly vyhodnotit, jestli integrovaná mezipaměť pomáhá snížit náklady:

• Úlohy náročné na čtení
• Mnohoopakovaných
• Mnoho opakovaných dotazů s vysokým počtem RU
• Klíč horkého oddílu pro čtení

Největším faktorem očekávaných úspor je stupeň opakování čtení. Pokud vaše úloha během krátkého časového období konzistentně provádí stejné čtení bodů nebo dotazy, je to skvělý kandidát na integrovanou mezipaměť. Při použití integrované mezipaměti pro opakované čtení používáte pouze ru pro první čtení. Následné čtení směrované přes stejný vyhrazený uzel brány (v MaxIntegratedCacheStaleness okně a pokud se data nevyřadila) nepoužívají propustnost.

Některé úlohy by neměly zvážit integrovanou mezipaměť, včetně následujících:

• Úlohy náročné na zápis
• Zřídka opakované čtení bodů nebo dotazy
• Úlohy, které čtou kanál změn

Mezipaměť položek

Mezipaměť položek se používá pro čtení bodů (vyhledávání klíč/hodnota na základě ID položky a klíče oddílu).

Naplnění mezipaměti položek

• Nové zápisy, aktualizace a odstranění se automaticky vyplní v mezipaměti položek uzlu, přes který se požadavek směruje.
• Položky z požadavků na čtení bodů, ve kterých položka ještě není v mezipaměti (chybí mezipaměti) uzlu, přes který se požadavek směruje, se přidají do mezipaměti položek.
• Čtení požadavků na více položek, jako je ReadMany, naplní mezipaměť dotazů jako sadu místo mezipaměti položek jako jednotlivé položky.
• Požadavky, které jsou součástí transakční dávky nebo v hromadném režimu , nenaplní mezipaměť položek.

Zneplatnění a vyřazení mezipaměti položek

Vzhledem k tomu, že každý uzel má nezávislou mezipaměť, je možné, že se položky zneplatní nebo vyřadí v mezipaměti jednoho uzlu a ne v ostatních uzlech. Položky v mezipaměti daného uzlu se zneplatní a vyřadí na základě následujících kritérií:

• Aktualizace nebo odstranění položky
• Nejméně naposledy použité (LRU)
• Doba uchovávání mezipaměti (jinými slovy)MaxIntegratedCacheStaleness

Mezipaměť dotazů

Mezipaměť dotazů se používá k ukládání dotazů do mezipaměti. Mezipaměť dotazů transformuje dotaz na vyhledávání klíč/hodnota, ve kterém je klíč textem dotazu a hodnotou jsou výsledky dotazu. Integrovaná mezipaměť nemá dotazovací modul, ukládá pouze vyhledávání klíče a hodnoty pro každý dotaz. Výsledky dotazů se ukládají jako sada a mezipaměť neudržuje přehled o jednotlivých položkách. Danou položku je možné uložit do mezipaměti dotazu několikrát, pokud se zobrazí v sadě výsledků více dotazů. Aktualizace podkladových položek se ve výsledcích dotazu neprojeví, pokud nedosáhnete maximální neautnosti integrované mezipaměti pro dotaz a dotaz se obsluhuje z back-endové databáze.

Naplnění mezipaměti dotazů

• Pokud mezipaměť nemá výsledek pro tento dotaz (zmeška mezipaměti) na uzlu, přes který byl směrován, odešle se dotaz do back-endu. Po spuštění dotazu uloží mezipaměť výsledky pro tento dotaz.
• Dotazy se stejným tvarem, ale s různými parametry nebo možnostmi požadavků, které ovlivňují výsledky (počet položek ex. max), se ukládají jako vlastní pár klíč/hodnota.
• Čtení požadavků na více položek, jako je ReadMany, naplní mezipaměť dotazů. Výsledky ReadMany se ukládají jako sada a požadavky s různými vstupy se uloží jako vlastní pár klíč/hodnota.

Vyřazení mezipaměti dotazů

Vyřazení mezipaměti dotazů je založeno na uzlu, přes který byl požadavek směrován. Je možné, že dotazy se dají vyřadit nebo aktualizovat na jednom uzlu, ne na ostatních uzlech.

• Nejméně naposledy použité (LRU)
• Doba uchovávání mezipaměti (jinými slovy)MaxIntegratedCacheStaleness

Práce s mezipamětí dotazů

Při práci s mezipamětí dotazů nepotřebujete speciální kód, a to ani v případě, že vaše dotazy mají více stránek výsledků. Osvědčené postupy a kód stránkování dotazů jsou stejné bez ohledu na to, jestli dotaz dosáhne integrované mezipaměti nebo se spustí v back-endovém dotazovacím stroji.

Mezipaměť dotazů automaticky ukládá do mezipaměti tokeny pokračování dotazu, pokud je to možné. Pokud máte dotaz s více stránkami výsledků, všechny stránky uložené v integrované mezipaměti mají poplatky za RU 0. Pokud další stránky výsledků dotazu vyžadují provedení back-endu, budou mít token pokračování z předchozí stránky, aby se zabránilo duplikování předchozí práce.

Konzistence integrované mezipaměti

Integrovaná mezipaměť podporuje žádosti o čtení pouze s relací a konečnou konzistencí . Pokud má čtení konzistentní předponu, ohraničenou nestarost nebo silnou konzistenci, předá integrovanou mezipaměť a bude obsluhována z back-endu.

Nejjednodušší způsob, jak nakonfigurovat relaci nebo konečnou konzistenci pro všechna čtení, je nastavit ji na úrovni účtu. Pokud ale chcete, aby některá čtení měla specifickou konzistenci, můžete také nakonfigurovat konzistenci na úrovni požadavku.

Konzistence Relace

Konzistence relací je nejrozšířenější úroveň konzistence pro účty Azure Cosmos DB v jedné i globálně distribuované oblasti. S konzistencí relace můžou jednotlivé klientské relace číst vlastní zápisy. Za všechna čtení s konzistencí relace, která nemají odpovídající token relace, se budou účtovat poplatky za RU. To zahrnuje první požadavek na danou položku nebo dotaz při spuštění nebo restartování klientské aplikace, pokud explicitně neprodáte platný token relace. Klienti mimo relaci, kteří provádějí zápisy, uvidí konečnou konzistenci při použití integrované mezipaměti.

MaxIntegratedCacheStaleness

Jedná se MaxIntegratedCacheStaleness o maximální přijatelnou neaktuálnost čtení a dotazů v mezipaměti bez ohledu na vybranou konzistenci. Tato MaxIntegratedCacheStaleness možnost je konfigurovatelná na úrovni požadavku. Pokud například nastavíte MaxIntegratedCacheStaleness 2 hodiny, vaše žádost vrátí data uložená v mezipaměti pouze v případě, že data jsou starší než 2 hodiny. Pokud chcete zvýšit pravděpodobnost opakovaných čtení využívajících integrovanou mezipaměť, měli byste nastavit MaxIntegratedCacheStaleness maximální hodnotu, jakou umožňují vaše obchodní požadavky.

Když MaxIntegratedCacheStalenessnakonfigurujete požadavek, který nakonec naplní mezipaměť, nemá vliv na dobu, po kterou se požadavek ukládá do mezipaměti. MaxIntegratedCacheStaleness vynucuje konzistenci při pokusu o čtení dat uložených v mezipaměti. Neexistuje žádné globální nastavení hodnoty TTL nebo uchovávání mezipaměti, takže data se z mezipaměti vyřadí jenom v případě, že je integrovaná mezipaměť plná nebo se spustí nové čtení s nižším MaxIntegratedCacheStaleness než věkem aktuální položky uložené v mezipaměti.

Toto je vylepšení z toho, jak většina mezipamětí funguje a umožňuje následující další přizpůsobení:

• Pro každý bod čtení nebo dotaz můžete nastavit různé požadavky na neakutnost.
• Různí klienti, i když spustí stejný bod čtení nebo dotaz, můžou nakonfigurovat různé MaxIntegratedCacheStaleness hodnoty.
• Pokud chcete upravit konzistenci čtení dat uložených v mezipaměti, má změna MaxIntegratedCacheStaleness okamžitý vliv na konzistenci čtení.

Pokud chcete lépe porozumět parametru MaxIntegratedCacheStaleness , zvažte následující příklad:

Naučte se konfigurovat MaxIntegratedCacheStaleness.

Obejití integrované mezipaměti

Integrovaná mezipaměť má omezenou kapacitu úložiště určenou zřízenou vyhrazenou skladovou položku brány. Ve výchozím nastavení všechny požadavky klientů nakonfigurované pomocí vyhrazené brány připojovací řetězec procházejí integrovanou mezipamětí a zabírají místo v mezipaměti. Pomocí možnosti vynechat integrovanou mezipaměť mezipaměti můžete určit, které položky a dotazy se ukládají do mezipaměti. Tato možnost požadavku je užitečná pro zápisy položek nebo žádosti o čtení, u kterých se neočekává, že se často opakují. Obejití integrované mezipaměti pro položky s občasným přístupem šetří místo v mezipaměti pro položky s více opakováními, což zvyšuje potenciál úspory RU a snižuje vyřazení. Žádosti o obejití mezipaměti se stále směrují přes vyhrazenou bránu. Tyto žádosti se obsluhují z back-endu a nákladových RU.

Zjistěte, jak obejít integrovanou mezipaměť.

Metriky

Je užitečné monitorovat některé klíčové DedicatedGateway a IntegratedCache metriky pro integrovanou mezipaměť. Další informace o těchto metrikách najdete v tématu Podporované metriky pro Microsoft.DocumentDB/DatabaseAccounts.

Všechny existující metriky jsou ve výchozím nastavení dostupné z metrik na webu Azure Portal (ne z klasických metrik):

Metriky jsou buď průměr, maximum, nebo součet ve všech vyhrazených uzlech brány. Pokud například zřídíte vyhrazený cluster brány s pěti uzly, metriky odrážejí agregovanou hodnotu ve všech pěti uzlech. Není možné určit hodnoty metriky pro každý jednotlivý uzel.

Řešení běžných problémů

Následující příklady ukazují, jak ladit některé běžné scénáře:

Nemůžu zjistit, jestli moje aplikace používá vyhrazenou bránu

Zkontrolujte .DedicatedGatewayRequests Tato metrika zahrnuje všechny požadavky, které používají vyhrazenou bránu, bez ohledu na to, jestli se dostanou do integrované mezipaměti. Pokud vaše aplikace používá standardní bránu nebo přímý režim s původním připojovací řetězec, nezobrazí se chybová zpráva, ale DedicatedGatewayRequests bude nulová. Pokud vaše aplikace používá přímý režim s vyhrazenou bránou připojovací řetězec, může se vám stále zobrazit několik DedicatedGatewayRequests.

Nemůžu zjistit, jestli moje požadavky nedosahují integrované mezipaměti

Zkontrolujte a IntegratedCacheItemHitRate IntegratedCacheQueryHitRate. Pokud jsou obě tyto hodnoty nulové, požadavky nedosahují integrované mezipaměti. Zkontrolujte, jestli používáte vyhrazenou bránu připojovací řetězec, připojujete se pomocí režimu brány a používáte relaci nebo konečnou konzistenci.

Chci pochopit, jestli je moje vyhrazená brána příliš malá

Zkontrolujte a IntegratedCacheItemHitRate IntegratedCacheQueryHitRate. Vysoké hodnoty (například vyšší než 0,7-0,8) jsou dobrým znamením, že vyhrazená brána je dostatečně velká.

IntegratedCacheItemHitRate Pokud je nebo IntegratedCacheQueryHitRateje nízká, podívejte se na IntegratedCacheEvictedEntriesSize. Pokud je vysoká IntegratedCacheEvictedEntriesSize , může to znamenat, že by byla přínosná větší vyhrazená velikost brány. Experimentovat můžete zvýšením velikosti vyhrazené brány a porovnáním nového IntegratedCacheItemHitRate a IntegratedCacheQueryHitRate. Pokud větší vyhrazená brána nezlepší IntegratedCacheItemHitRate nebo IntegratedCacheQueryHitRate, je možné, že čtení se jednoduše neopakují dostatečně, aby integrovaná mezipaměť byla ovlivněná.

Chci pochopit, jestli je moje vyhrazená brána příliš velká

Je obtížnější měřit, jestli je vyhrazená brána příliš velká, než je měřit, pokud je vyhrazená brána příliš malá. Obecně platí, že byste měli začít malá a pomalu zvětšovat vyhrazenou velikost brány, dokud se IntegratedCacheItemHitRate nevylepší a IntegratedCacheQueryHitRate nezastaví se. V některých případech bude důležité jenom jedno z těchto dvou metrik přístupů do mezipaměti, nikoli obojí. Například pokud je vaše úloha primárně dotazy, nikoli čtení bodů, IntegratedCacheQueryHitRate je mnohem důležitější než .IntegratedCacheItemHitRate

Pokud se většina dat vyřadí z mezipaměti kvůli překročení MaxIntegratedCacheStalenesshodnoty LRU místo LRU, může být vaše mezipaměť větší než požadovaná. Pokud IntegratedCacheItemExpirationCount jsou a IntegratedCacheQueryExpirationCount kombinované téměř tak velké, IntegratedCacheEvictedEntriesSizemůžete experimentovat s menší vyhrazenou velikostí brány a porovnat výkon.

Chci vědět, jestli potřebuji přidat další vyhrazené uzly brány

V některých případech, pokud je latence neočekávaně vysoká, možná budete potřebovat více vyhrazených uzlů brány místo větších uzlů. DedicatedGatewayCPUUsage Zkontrolujte a DedicatedGatewayMemoryUsage zjistěte, jestli přidání dalších vyhrazených uzlů brány sníží latenci. Je dobré mít na paměti, že vzhledem k tomu, že všechny instance integrované mezipaměti jsou nezávislé na sobě, přidání dalších vyhrazených uzlů brány nezmenší IntegratedCacheEvictedEntriesSize. Přidáním dalších uzlů se ale zlepší svazek požadavku, který váš vyhrazený cluster brány dokáže zpracovat.

Další kroky

• Nejčastější dotazy k integrované mezipaměti
• Konfigurace integrované mezipaměti
• Vyhrazená brána
• Pokoušíte se naplánovat kapacitu migrace do služby Azure Cosmos DB? Informace o stávajícím databázovém clusteru můžete použít k plánování kapacity.
  • Pokud víte, že je počet virtuálních jader a serverů ve vašem existujícím databázovém clusteru, přečtěte si informace o odhadu jednotek žádostí pomocí virtuálních jader nebo virtuálních procesorů.
  • Pokud znáte typické sazby požadavků pro vaši aktuální úlohu databáze, přečtěte si informace o odhadu jednotek žádostí pomocí plánovače kapacity služby Azure Cosmos DB.