Ereignisse
Erstellen von KI-Apps und Agents
17. März, 21 Uhr - 21. März, 10 Uhr
Nehmen Sie an der Meetup-Serie teil, um skalierbare KI-Lösungen basierend auf realen Anwendungsfällen mit Mitentwicklern und Experten zu erstellen.
Jetzt registrierenDieser Browser wird nicht mehr unterstützt.
Führen Sie ein Upgrade auf Microsoft Edge durch, um die neuesten Features, Sicherheitsupdates und den technischen Support zu nutzen.
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.
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.
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.
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.
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:
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.
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.
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.
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.
Ereignisse
Erstellen von KI-Apps und Agents
17. März, 21 Uhr - 21. März, 10 Uhr
Nehmen Sie an der Meetup-Serie teil, um skalierbare KI-Lösungen basierend auf realen Anwendungsfällen mit Mitentwicklern und Experten zu erstellen.
Jetzt registrieren