Integrierter Azure Cosmos DB-Cache: Übersicht

GILT FÜR: NoSQL

Der integrierte Azure Cosmos DB-Cache ist ein In-Memory-Cache, der Sie dabei unterstützt, überschaubare Kosten und niedrige Latenzen bei wachsendem Anforderungsvolumen zu gewährleisten. Die Einrichtung des integrierten Caches ist einfach, und Sie müssen keine Zeit damit verbringen, benutzerdefinierten Code für die Cacheinvalidierung oder zum Verwalten der Back-End-Infrastruktur zu schreiben. Der integrierter Cache nutzt das dedizierte Gateway in Ihrem Azure Cosmos DB-Konto. Bei der Bereitstellung Ihres dedizierten Gateways können Sie die Anzahl und die Größe der Knoten basierend auf der Anzahl der Kerne und des Arbeitsspeichers auswählen, die für Ihre Workload benötigt werden. Jeder dedizierte Gatewayknoten verfügt über einen separaten integrierten Cache.

Ein integrierter Cache wird automatisch innerhalb des dedizierten Gateways konfiguriert. Der integrierte Cache besteht aus zwei Teilen:

• Ein Elementcache für Punktlesevorgänge
• Ein Abfragecache für Abfragen

Der integrierte Cache ist ein Lese-/Schreibcache mit einer Entfernungsrichtlinie nach seltener Verwendung. Der Elementcache und der Abfragecache teilen sich dieselbe Kapazität innerhalb des integrierten Caches, und die Entfernungsrichtlinie nach seltener Verwendung gilt für beide. Das Entfernen von Daten aus dem Cache erfolgt streng danach, welche am längsten nicht verwendet wurden, unabhängig davon, ob es sich um einen Punktlesevorgang oder eine Abfrage handelt. Die zwischengespeicherten Daten innerhalb jedes Knotens hängen von den Daten ab, die vor kurzem über diesen spezifischen Knoten geschrieben oder gelesen wurden. Wenn ein Element oder eine Abfrage auf einem Knoten zwischengespeichert wird, wird es bzw. sie nicht unbedingt auf den anderen Knoten zwischengespeichert.

Vom integrierten Cache profitierende Workloads

Das Hauptziel des integrierten Caches ist die Reduzierung der Kosten von Workloads mit vielen Lesevorgängen. Die niedrige Latenz ist zwar nützlich, aber nicht der Hauptvorteil des integrierten Caches, da Azure Cosmos DB auch ohne die Zwischenspeicherung bereits schnell ist.

Für Punktlesevorgänge und Abfragen, die auf den integrierten Cache treffen, gilt eine RU-Gebühr von 0. Cachetreffer bieten deutlich geringere Kosten pro Vorgang als Lesevorgänge aus der Back-End-Datenbank.

Für Workloads, die den folgenden Merkmalen entsprechen, sollte in Betracht gezogen werden, ob der integrierte Cache zu Kostenvergünstigungen führt:

• Workloads mit vielen Lesevorgängen
• Viele wiederholte Punktlesevorgänge für große Elemente
• Viele wiederholte Abfragen mit großen Mengen von RUs
• Häufig angeforderte Partitionsschlüssel für Lesevorgänge

Der größte Faktor der erwarteten Einsparungen ist der Grad, in dem sich Lesevorgänge wiederholen. Wenn Ihre Workload konsistent dieselben Punktlesevorgänge oder Abfragen in einem kurzen Zeitraum ausführt, eignet sie sich bestens für den integrierten Cache. Wenn Sie den integrierten Cache für wiederholte Lesevorgänge verwenden, werden RUs nur für den ersten Lesevorgang verwendet. Nachfolgende Lesevorgänge, die über denselben dedizierten Gatewayknoten geleitet werden (im MaxIntegratedCacheStaleness-Fenster, sofern die Daten nicht entfernt wurden), nutzen den Durchsatz nicht.

Für einige Workloads sollte der integrierte Cache nicht in Betracht gezogen werden, zum Beispiel:

• Workloads mit vielen Schreibvorgängen
• Selten wiederholte Punktlesevorgänge oder Abfragen
• Workloads, die den Änderungsfeed lesen

Elementcache

Der Elementcache wird für Punktlesevorgänge (Schlüssel-/Wert-Suchvorgänge basierend auf der Element-ID und dem Partitionsschlüssel) verwendet.

Auffüllen des Elementcaches

• Neue Schreibvorgänge, Updates und Löschvorgänge werden automatisch im Elementcache des Knotens aufgefüllt, über den die Anforderung weitergeleitet wird.
• Elemente aus Punktleseanforderungen, bei denen sich das Element noch nicht im Cache (Cachefehler) des Knotens, über den die Anforderung weitergeleitet wird, befindet, werden dem Elementcache hinzugefügt.
• Leseanforderungen für mehrere Elemente, z. B. ReadMany, füllen den Abfragecache als Satz anstelle des Elementcaches als einzelne Elemente auf.
• Anforderungen, die Teil eines Transaktionsbatches sind oder sich im Massenmodus befinden, füllen den Elementcache nicht mit Daten auf.

Elementcacheinvalidierung und -entfernung

Da jeder Knoten über einen unabhängigen Cache verfügt, werden Elemente möglicherweise ungültig gemacht oder im Cache eines Knotens entfernt und nicht in denen der anderen. Elemente im Cache eines bestimmten Knotens werden anhand der folgenden Kriterien für ungültig erklärt und entfernt:

• Aktualisieren oder Löschen von Elementen
• Seltene Verwendung
• Cacheaufbewahrungszeit (d. h. MaxIntegratedCacheStaleness)

Abfragecache

Der Abfragecache wird zum Zwischenspeichern von Abfragen verwendet. Der Abfragecache transformiert eine Abfrage in eine Schlüssel-/Wert-Lookup, bei der der Schlüssel dem Abfragetext und der Wert den Abfrageergebnissen entsprechen. Der integrierte Cache verfügt über keine Abfrage-Engine, er speichert lediglich die Schlüssel-/Wertsuche für jede Abfrage. Abfrageergebnisse werden als Satz gespeichert, und der Cache verfolgt einzelne Elemente nicht nach. Ein gegebenes Element kann mehrmals im Abfragecache gespeichert werden, wenn es im Resultset mehrerer Abfragen angezeigt wird. Aktualisierungen der zugrunde liegenden Elemente werden in Abfrageergebnissen nicht widergegeben, es sei denn, die maximale Veraltung des integrierten Caches für die Abfrage wird erreicht, und die Abfrage wird von der Back-End-Datenbank bereitgestellt.

Auffüllen des Abfragecaches

• Wenn der Cache über kein Ergebnis für diese Abfrage (Cachefehler) auf dem Knoten, über den sie weitergeleitet wurde, verfügt, wird die Abfrage an das Back-End gesendet. Nachdem die Abfrage ausgeführt wurde, speichert der Cache die Ergebnisse für diese Abfrage.
• Abfragen derselben Form, aber mit unterschiedlichen Parametern oder Anforderungsoptionen, die sich auf die Ergebnisse auswirken (z. B. maximale Elementanzahl), werden als eigenes Schlüssel-/Wert-Paar gespeichert.
• Leseanforderungen für mehrere Elemente, z. B. ReadMany, füllen den Abfragecache auf. ReadMany-Ergebnisse werden als Satz gespeichert, und Anforderungen mit unterschiedlichen Eingaben werden als eigenes Schlüssel-Wert-Paar gespeichert.

Abfragecacheentfernung

Die Entfernung des Abfragecaches basiert auf dem Knoten, über den die Anforderung weitergeleitet wurde. Es ist möglich, dass Abfragen auf einem Knoten entfernt oder aktualisiert werden und auf den anderen nicht.

• Seltene Verwendung
• Cacheaufbewahrungszeit (d. h. MaxIntegratedCacheStaleness)

Arbeiten mit dem Abfragecache

Sie benötigen keinen speziellen Code, wenn Sie mit dem Abfragecache arbeiten, selbst wenn die Ergebnisse Ihrer Abfragen mehrere Seiten umfassen. Die bewährten Methoden und der Code für die Abfragepaginierung sind identisch, unabhängig davon, ob Ihre Abfrage auf den integrierten Cache trifft oder für die Back-End-Abfrage-Engine ausgeführt wird.

Der Abfragecache speichert ggf. automatisch Abfragefortsetzungstoken. Wenn die Ergebnisse Ihrer Abfrage mehrere Seiten umfassen, fallen für Seiten, die im integrierten Cache gespeichert sind, keine RU-Gebühren an. Wenn für nachfolgende Seiten mit Abfrageergebnissen Back-End-Ausführung erforderlich ist, verfügen diese über ein Fortsetzungstoken der vorherigen Seite, um die Duplizierung des vorherigen Arbeitsaufwands zu vermeiden.

Konsistenz des integrierten Caches

Der integrierte Cache unterstützt nur Leseanforderungen mit sitzungsbasierter und letztlicher Konsistenz. Wenn ein Lesevorgang über ein konsistentes Präfix, begrenzte Veraltung oder starke Konsistenz verfügt, umgeht er den integrierten Cache und wird aus dem Back-End bedient.

Die einfachste Vorgehensweise zum Konfigurieren der Sitzungskonsistenz oder letztlichen Konsistenz für alle Lesevorgänge besteht darin, diese auf Kontoebene festzulegen. Falls Sie eine bestimmte Konsistenz aber nur für einige Ihrer Lesevorgänge festlegen möchten, können Sie die Konsistenz auch auf Anforderungsebene konfigurieren.

Sitzungskonsistenz

Die Sitzungskonsistenz ist die gängigste Konsistenzebene für Konten in einer einzelnen Region und für weltweit verteilte Azure Cosmos DB-Konten. Bei der Sitzungskonsistenz können einzelne Clientsitzungen ihre eigenen Schreibvorgänge lesen. Für alle Lesevorgänge mit Sitzungskonsistenz ohne übereinstimmende Sitzungstoken fallen RU-Gebühren an. Dies schließt die erste Anforderung für ein bestimmtes Element oder eine Abfrage ein, wenn die Clientanwendung gestartet oder neu gestartet wird, es sei denn, Sie übergeben explizit ein gültiges Sitzungstoken. Clients außerhalb der Sitzung, die Schreibvorgänge ausführen, sehen letztliche Konsistenz, wenn sie den integrierten Cache verwenden.

MaxIntegratedCacheStaleness

Der Wert für MaxIntegratedCacheStaleness ist die maximal zulässige Veraltung für zwischengespeicherte Punktlesevorgänge und Abfragen, unabhängig von der ausgewählten Konsistenz. MaxIntegratedCacheStaleness ist auf Anforderungsebene konfigurierbar. Wenn Sie beispielsweise für MaxIntegratedCacheStaleness einen Wert von 2 Stunden festlegen, gibt Ihre Anforderung nur dann zwischengespeicherte Daten zurück, wenn die Daten weniger als 2 Stunden alt sind. Um die Wahrscheinlichkeit von wiederholten Lesezugriffen mithilfe des integrierten Caches zu erhöhen, sollten Sie für MaxIntegratedCacheStaleness den maximalen Wert festlegen, den Ihre Geschäftsanforderungen zulassen.

Wenn MaxIntegratedCacheStaleness für eine Anforderung, die den Cache auffüllt, konfiguriert wird, hat diese Einstellung keinen Einfluss darauf hat, wie lange diese Anforderung zwischengespeichert wird. MaxIntegratedCacheStaleness erzwingt Konsistenz, wenn Sie versuchen, zwischengespeicherte Daten zu lesen. Es gibt keine globale Einstellung für TTL oder Cachedatenaufbewahrung, sodass Daten nur dann aus dem Cache entfernt werden, wenn entweder der integrierte Cache voll ist oder ein neuer Lesezugriff mit einem MaxIntegratedCacheStaleness ausgeführt wird, der niedriger als das Alter des aktuellen zwischengespeicherten Eintrags ist.

Dies ist eine Verbesserung gegenüber der Funktionsweise der meisten Caches und ermöglicht die folgenden weiteren Anpassungen:

• Sie können unterschiedliche Veraltungsanforderungen für jedes Lesen oder Abfragen von Punkten festlegen.
• Verschiedene Clients können auch dann unterschiedliche MaxIntegratedCacheStaleness-Werte konfigurieren, wenn sie denselben Punktlese- oder Abfragevorgang ausführen.
• Wenn Sie die Lesekonsistenz bei der Verwendung zwischengespeicherter Daten ändern möchten, hat die Änderung von MaxIntegratedCacheStaleness sofortige Auswirkungen auf die Lesekonsistenz.

Sehen Sie sich das folgende Beispiel an, um den MaxIntegratedCacheStaleness-Parameter besser zu verstehen:

Lernen Sie, MaxIntegratedCacheStaleness zu konfigurieren.

Umgehung des integrierten Caches

Der integrierte Cache verfügt über eine begrenzte Speicherkapazität, die durch die dedizierte Gateway-SKU festgelegt wird. Standardmäßig durchlaufen alle Anforderungen von Clients, die mit der dedizierten Gateway-Verbindungszeichenfolge konfiguriert sind, durch den integrierten Cache geleitet und belegen Cachespeicherplatz. Sie können mit der Option „Integrierte Cacheanforderung umgehen“ steuern, welche Elemente und Abfragen zwischengespeichert werden. Diese Anforderungsoption ist nützlich für Elementschreib- oder Leseanforderungen, die voraussichtlich nicht häufig wiederholt werden. Das Umgehen des integrierten Caches für Elemente, auf die selten zugegriffen wird, spart Cachespeicher für Elemente mit mehr Wiederholungen, wodurch das Einsparungspotenzial für RU erhöht und die Zahl der Auslagerungen verringert wird. Anforderungen, die den Cache umgehen, werden trotzdem über das dedizierte Gateway weitergeleitet. Diese Anforderungen werden vom Back-End bedient und kosten RUs.

Erfahren Sie, wie sich der integrierte Cache umgehen lässt.

Metriken

Es ist hilfreich, einige wichtige DedicatedGateway- und IntegratedCache-Metriken für den integrierten Cache zu überwachen. Weitere Informationen zu diesen Metriken finden Sie unter Unterstützte Metriken für Microsoft.DocumentDB/DatabaseAccounts.

Alle vorhandenen Metriken sind standardmäßig über Metriken im Azure-Portal verfügbar (nicht „Metriken (klassisch)“):

Metriken sind entweder ein Durchschnittswert, ein Maximum oder eine Summe für alle dedizierten Gatewayknoten. Wenn Sie beispielsweise einen dedizierten Gatewaycluster mit fünf Knoten bereitstellen, spiegeln die Metriken den aggregierten Wert aller fünf Knoten wider. Es ist nicht möglich, die Metrikwerte für jeden einzelnen Knoten zu bestimmen.

Behandlung häufig auftretender Probleme

In den folgenden Beispielen wird das Debuggen einiger gängiger Szenarios veranschaulicht:

Wie erkenne ich, ob meine Anwendung das dedizierte Gateway verwendet?

Überprüfen Sie die Metrik DedicatedGatewayRequests. Diese Metrik umfasst alle Anforderungen, die das dedizierte Gateway nutzen, unabhängig davon, ob sie den integrierten Cache betreffen. Wenn Ihre Anwendung das Standardgateway oder den direkten Modus mit Ihrer ursprünglichen Verbindungszeichenfolge verwendet, wird keine Fehlermeldung angezeigt, sondern der Wert von DedicatedGatewayRequests ist 0 (Null). Wenn Ihre Anwendung den direkten Modus mit Ihrer dedizierten Gateway-Verbindungszeichenfolge verwendet, werden möglicherweise noch immer einige DedicatedGatewayRequests angezeigt.

Wie erkenne ich, ob meine Anforderungen den integrierten Cache betreffen?

Überprüfen Sie IntegratedCacheItemHitRate und IntegratedCacheQueryHitRate. Wenn beide Werte 0 (null) sind, treffen Anforderungen nicht den integrierten Cache. Stellen Sie sicher, dass Sie die Verbindungszeichenfolge des dedizierten Gateways verwenden, die Verbindung im Gatewaymodus herstellen und Sitzungs- oder Eventualkonsistenz verwenden.

Woran erkenne ich, ob mein dediziertes Gateway zu klein ist?

Überprüfen Sie IntegratedCacheItemHitRate und IntegratedCacheQueryHitRate. Hohe Werte (z. B. über 0,7- 0,8) sind ein gutes Anzeichen dafür, dass die Größe des dedizierten Gateways genügt.

Wenn IntegratedCacheItemHitRate oder IntegratedCacheQueryHitRate niedrig ist, überprüfen Sie IntegratedCacheEvictedEntriesSize. Wenn der IntegratedCacheEvictedEntriesSize-Wert hoch ist, bedeutet dies, dass ein größeres dediziertes Gateway von Vorteil wäre. Sie können experimentieren, indem Sie die Größe des dedizierten Gateways erhöhen und die neuen Werte von IntegratedCacheItemHitRate und IntegratedCacheQueryHitRate vergleichen. Wenn ein größeres dediziertes Gateway die Werte von IntegratedCacheItemHitRate oder IntegratedCacheQueryHitRate nicht verbessert, ist es möglich, dass sich Lesezugriffe einfach nicht genug wiederholen, sodass der integrierte Cache keine Auswirkung hat.

Woran erkenne ich, ob mein dediziertes Gateway zu groß ist?

Es ist schwieriger zu messen, ob ein dediziertes Gateway zu groß ist, als zu messen, ob ein dediziertes Gateway zu klein ist. Im Allgemeinen sollten Sie klein anfangen und die Größe des dedizierten Gateways langsam erhöhen, bis die Werte von IntegratedCacheItemHitRate und IntegratedCacheQueryHitRate sich nicht mehr verbessern. In einigen Fällen ist nur eine der beiden Cachetreffermetriken wichtig, nicht beide. Wenn es sich bei Ihrer Workload beispielsweise hauptsächlich um Abfragen und nicht um Punktlesevorgänge handelt, ist IntegratedCacheQueryHitRate viel wichtiger als IntegratedCacheItemHitRate.

Wenn die meisten Daten aufgrund der Überschreitung des MaxIntegratedCacheStaleness-Werts aus dem Cache entfernt werden, anstatt aufgrund der Entfernungsrichtlinie nach seltener Verwendung, ist Ihr Cache möglicherweise größer als notwendig. Wenn IntegratedCacheItemExpirationCount und IntegratedCacheQueryExpirationCount kombiniert fast so groß wie IntegratedCacheEvictedEntriesSize sind, können Sie mit einer kleineren Größe des dedizierten Gateways experimentieren und die Leistung vergleichen.

Ich möchte wissen, ob ich weitere dedizierte Gatewayknoten hinzufügen muss.

Wenn die Latenz unerwartet hoch ist, benötigen Sie in einigen Fällen möglicherweise mehr dedizierte Gatewayknoten als größere Knoten. Überprüfen Sie DedicatedGatewayCPUUsage und DedicatedGatewayMemoryUsage, um zu ermitteln, ob das Hinzufügen weiterer dedizierter Gatewayknoten die Latenz reduzieren würde. Beachten Sie: Da alle Instanzen des integrierten Caches voneinander unabhängig sind, wird der Wert von IntegratedCacheEvictedEntriesSize durch das Hinzufügen weiterer dedizierter Gatewayknoten nicht reduziert. Das Hinzufügen weiterer Knoten verbessert jedoch das Anforderungsvolumen, das Ihr dedizierter Gatewaycluster verarbeiten kann.

Nächste Schritte

• Häufig gestellte Fragen zum integrierten Cache
• Konfigurieren des integrierten Caches
• Dediziertes Gateway
• Versuchen Sie, die Kapazitätsplanung für eine Migration zu Azure Cosmos DB durchzuführen? Sie können Informationen zu Ihrem vorhandenen Datenbankcluster für die Kapazitätsplanung verwenden.
  • Wenn Sie lediglich die Anzahl der virtuellen Kerne und Server in Ihrem vorhandenen Datenbankcluster kennen, lesen Sie die Informationen zum Schätzen von Anforderungseinheiten mithilfe von virtuellen Kernen oder virtuellen CPUs.
  • Wenn Sie die typischen Anforderungsraten für Ihre aktuelle Datenbankworkload kennen, lesen Sie die Informationen zum Schätzen von Anforderungseinheiten mit dem Azure Cosmos DB-Kapazitätsplaner