Freigeben über

Häufig gestellte Fragen zum in der Azure Cosmos DB integrierten Cache

  • Artikel

GILT FÜR: NoSQL

Der in Azure Cosmos DB integrierte Cache ist ein In-Memory-Cache, der in Azure Cosmos DB eingebunden ist. Dieser Artikel beantwortet häufig gestellte Fragen über den integrierten Cache von Azure Cosmos DB.

Häufig gestellte Fragen

Warum ist für den integrierten Cache ein dediziertes Gateway erforderlich?

Wenn Sie eine Verbindung zu Azure Cosmos DB im Gateway-Modus hergestellt haben, haben Sie das Standard-Gateway verwendet. Während das Azure Cosmos DB-Back-End (Ihr bereitgestellter Durchsatz und Speicher) über dedizierte Kapazität pro Container verfügt, wird das Standard-Gateway von vielen Kunden gemeinsam genutzt. Es ist für viele Kunden praktisch, ein Standard-Gateway gemeinsam zu nutzen, da die von den einzelnen Kunden verbrauchten Computerressourcen minimal sind. Da der integrierte Cache spezifisch für Ihr Azure Cosmos DB-Konto ist und erhebliche CPU- und Speicheranforderungen stellt, sind dedizierte Gateway-Knoten erforderlich.

Was ist ein dediziertes Gateway?

Ein dediziertes Gateway ist eine serverseitige Rechenleistung, die ein Front-End für Daten in einem Azure Cosmos DB-Konto ist. Wenn Sie im Gatewaymodus eine Verbindung mit dem Endpunkt Ihres dedizierten Gateways herstellen, sendet Ihre Anwendung eine Anforderung an das dedizierte Gateway, das die Anforderung dann an verschiedene Back-End-Partitionen weiterleitet. Die Verwendung des direkten Modus mit dem dedizierten Gateway wird unterstützt, aber diese Anforderungen verwenden nicht den integrierten Cache.

Bietet die Verwendung des dedizierten Gateways gegenüber der Verwendung des Standard-Gateways andere Leistungsvorteile?

Im Allgemeinen haben Anforderungen, die vom dedizierten Gateway geroutet werden, eine etwas geringere und konsistentere Latenz als Anforderungen, die vom Standard-Gateway geroutet werden. Selbst Anforderungen, die den integrierten Cache nicht verwenden, haben immer noch eine etwas geringere Latenz als das Standard-Gateway.

Welche Art von Latenz sollte ich vom integrierten Cache erwarten?

Eine vom integrierten Cache verarbeitete Anforderung ist schnell, weil die zwischengespeicherten Daten im In-Memory auf dem dedizierten Gateway und nicht im Back-End gespeichert werden.

Für zwischengespeicherte Punktlesevorgänge sollten Sie eine mittlere Latenz von 2–4 ms erwarten. Bei zwischengespeicherten Abfragen hängt die Latenz von der Abfrage ab. Der Abfrage-Cache funktioniert, indem er die Antwort der Abfrage-Engine für eine bestimmte Abfrage zwischenspeichert. Diese Antwort wird dann zur Verarbeitung an das SDK zurückgesendet. Für einfache Abfragen ist minimale Arbeit im SDK erforderlich, und mittlere Latenzen von 2–4 ms sind typisch. Komplexere Abfragen mit GROUP BY oder DISTINCT erfordern eine höhere Verarbeitung im SDK, sodass die Latenz auch mit dem Abfragecache höher sein kann.

Wenn Sie zuvor eine Verbindung mit Azure Cosmos DB im direkten Modus hergestellt und zur Verbindung mit dem dedizierten Gateway gewechselt haben, kann es bei einigen Anforderungen zu einem geringfügigen Latenzanstieg kommen. Für die Verwendung des Gateway-Modus muss eine Anforderung an das Gateway (in diesem Fall das dedizierte Gateway) gesendet und dann entsprechend an das Back-End geroutet werden. Der direkte Modus ermöglicht dem Client, wie der Name schon sagt, eine direkte Kommunikation mit dem Back-End, wodurch ein zusätzlicher Hop entfernt wird. Es gibt keine Latenz-SLA für Anforderungen mit dem dedizierten Gateway.

Wenn Ihre App zuvor den direkten Modus verwendet hat, sind die Latenzvorteile des integrierten Caches nur in den folgenden Szenarien von Bedeutung:

  • Punktleselatenz für große Elemente (> 16 KB)
  • Hohe Anforderungseinheit oder komplexe Abfragen

Wenn Ihre App zuvor den Gateway-Modus mit dem Standard-Gateway verwendet hat, bietet der integrierte Cache in fast allen Szenarien eine Verringerung der Latenz.

Erstreckt sich die Azure Cosmos DB SLA-Verfügbarkeit auf das dedizierte Gateway und den integrierten Cache?

Für Szenarien, die Hochverfügbarkeit erfordern, und zur Erfüllung der Azure Cosmos DB-Verfügbarkeits-SLA sollten Sie mindestens drei dedizierte Gatewayknoten bereitstellen. Wenn beispielsweise ein dedizierter Gatewayknoten in der Produktion benötigt wird, sollten Sie zwei zusätzliche dedizierte Gatewayknoten bereitstellen, um mögliche Downtime, Ausfälle und Upgrades zu berücksichtigen. Wenn nur ein dedizierter Gatewayknoten bereitgestellt wird, geht die Verfügbarkeit in diesen Szenarien vorübergehend verloren. Stellen Sie außerdem sicher, dass Ihr dediziertes Gateway über genügend Knoten verfügt, um Ihre Workload zu verarbeiten.

Der integrierte Cache ist derzeit nur für die API für NoSQL verfügbar. Planen Sie die Freigabe auch für andere APIs?

Die Erweiterung des integrierten Caches über die API für NoSQL hinaus ist auf der Planungsliste vorgesehen, übersteigt aber den anfänglichen Umfang des integrierten Caches.

Welche Konsistenz unterstützt der integrierte Cache?

Der integrierte Cache unterstützt sowohl Sitzungskonsistenz als auch letztliche Konsistenz. Sie können auch die optionale MaxIntegratedCacheStaleness konfigurieren, die eine Obergrenze für zwischengespeicherte Daten festlegt.

Nächste Schritte