Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Von Bedeutung
Dies ist nicht das neueste Java SDK für Azure Cosmos DB! Sie sollten Ihr Projekt auf Azure Cosmos DB Java SDK v4 aktualisieren und dann das Azure Cosmos DB Java SDK v4-Leistungstippshandbuch lesen. Befolgen Sie die Anweisungen im Leitfaden "Migrate to Azure Cosmos DB Java SDK v4 " und " Reactor vs RxJava " zum Upgrade.
Diese Leistungstipps gelten nur für Azure Cosmos DB Sync Java SDK v2. Weitere Informationen finden Sie im Maven-Repository .
Von Bedeutung
Am 29. Februar 2024 wird das Azure Cosmos DB Sync Java SDK v2.x eingestellt; das SDK und alle Anwendungen, die das SDK verwenden , funktionieren weiterhin; Azure Cosmos DB wird einfach keine weitere Wartung und Unterstützung für dieses SDK bereitstellen. Es wird empfohlen, die obigen Anweisungen zur Migration zum Azure Cosmos DB Java SDK v4 zu befolgen.
Azure Cosmos DB ist eine schnelle und flexible verteilte Datenbank mit nahtloser Skalierung, garantierter Latenz und garantiertem Durchsatz. Die Skalierung Ihrer Datenbank mit Azure Cosmos DB erfordert weder aufwendige Änderungen an der Architektur noch das Schreiben von komplexem Code. Das Hoch- und Herunterskalieren ist so einfach wie einen einzigen API-Aufruf zu tätigen. Weitere Informationen finden Sie unter Bereitstellen des Containerdurchsatzes oder zum Bereitstellen des Datenbankdurchsatzes. Da jedoch über Netzwerkaufrufe auf Azure Cosmos DB zugegriffen wird, gibt es clientseitige Optimierungen, die Sie ausführen können, um Spitzenleistung zu erzielen, wenn Sie Azure Cosmos DB Sync Java SDK v2 verwenden.
Wenn Sie sich also fragen, wie Sie die Leistung Ihrer Datenbank verbessern können, sollten Sie die folgenden Optionen in Betracht ziehen:
Vernetzung
Verbindungsmodus: Verwenden von DirectHttps
Wie ein Client eine Verbindung mit Azure Cosmos DB herstellt, hat wichtige Auswirkungen auf die Leistung, insbesondere hinsichtlich der beobachteten clientseitigen Latenz. Es gibt eine wichtige Konfigurationseinstellung für die Konfiguration der Client-ConnectionPolicy – der ConnectionMode. Die beiden verfügbaren ConnectionModes sind:
-
Der Gatewaymodus wird auf allen SDK-Plattformen unterstützt und ist der konfigurierte Standardwert. Wenn Ihre Anwendung innerhalb eines Unternehmensnetzwerks mit strengen Firewalleinschränkungen ausgeführt wird, ist Gateway die beste Wahl, da sie den standardmäßigen HTTPS-Port und einen einzelnen Endpunkt verwendet. Die Leistungseinbußen bestehen jedoch darin, dass der Gatewaymodus bei jedem Lesen oder Schreiben von Daten in Azure Cosmos DB einen zusätzlichen Netzwerksprung erfordert. Aus diesem Grund bietet der DirectHttps-Modus aufgrund weniger Netzwerkhüpfungen eine bessere Leistung.
Das Azure Cosmos DB Sync Java SDK v2 verwendet HTTPS als Transportprotokoll. HTTPS verwendet TLS für die anfängliche Authentifizierung und verschlüsselung von Datenverkehr. Bei Verwendung des Azure Cosmos DB Sync Java SDK v2 muss nur HTTPS-Port 443 geöffnet sein.
Der ConnectionMode wird während der Erstellung der DocumentClient-Instanz mit dem Parameter ConnectionPolicy konfiguriert.
Synchronisieren von Java SDK V2 (Maven com.microsoft.azure::azure-documentdb)
public ConnectionPolicy getConnectionPolicy() { ConnectionPolicy policy = new ConnectionPolicy(); policy.setConnectionMode(ConnectionMode.DirectHttps); policy.setMaxPoolSize(1000); return policy; } ConnectionPolicy connectionPolicy = new ConnectionPolicy(); DocumentClient client = new DocumentClient(HOST, MASTER_KEY, connectionPolicy, null);
Platzieren der Clients in der gleichen Azure-Region
Platzieren Sie nach Möglichkeit sämtliche Anwendungen, die Azure Cosmos DB aufrufen, in der gleichen Region wie die Azure Cosmos DB-Datenbank. Damit Sie einen ungefähren Vergleich haben: Azure Cosmos DB-Aufrufe aus derselben Region werden normalerweise innerhalb von 1 bis 2 ms abgeschlossen, während die Latenz zwischen West- und Ostküste der USA >50 ms beträgt. Diese Latenz variiert ggf. von Anforderung zu Anforderung und ist abhängig von der Route, die die Anforderung zwischen dem Client und der Grenze des Azure-Datencenters nimmt. Die geringste Latenz erzielen Sie, wenn sich die aufrufende Anwendung in der gleichen Azure-Region wie der bereitgestellte Azure Cosmos DB-Endpunkt befindet. Eine Liste mit den verfügbaren Regionen finden Sie unter Azure-Regionen.
SDK-Verwendung
Installieren des neuesten SDKs
Azure Cosmos DB-SDKs werden ständig verbessert, um eine optimale Leistung zu ermöglichen. Informationen zu den neuesten SDK-Verbesserungen finden Sie unter Azure Cosmos DB-SDK.
Verwenden eines Singleton-Azure Cosmos DB-Clients für die Lebensdauer der Anwendung
Jede DocumentClient-Instanz ist threadsicher und führt effiziente Verbindungsverwaltung und Adresszwischenspeicherung durch, wenn sie im direkten Modus ausgeführt werden. Um eine effiziente Verbindungsverwaltung und eine bessere Leistung durch DocumentClient zu ermöglichen, empfiehlt es sich, eine einzelne Instanz von DocumentClient pro AppDomain für die Lebensdauer der Anwendung zu verwenden.
Erhöhen der MaxPoolSize pro Host bei Verwendung des Gatewaymodus
Azure Cosmos DB-Anforderungen werden bei Verwendung des Gatewaymodus über HTTPS/REST vorgenommen und unterliegen dem Standardverbindungsgrenzwert pro Hostname oder IP-Adresse. Möglicherweise müssen Sie die MaxPoolSize auf einen höheren Wert (200-1000) festlegen, damit die Clientbibliothek mehrere gleichzeitige Verbindungen mit Azure Cosmos DB nutzen kann. Im Azure Cosmos DB Sync Java SDK v2 ist der Standardwert für ConnectionPolicy.getMaxPoolSize 100. Verwenden Sie setMaxPoolSize , um den Wert zu ändern.
Optimieren paralleler Abfragen für partitionierte Sammlungen
Azure Cosmos DB Sync Java SDK Version 1.9.0 und höher unterstützen parallele Abfragen, mit denen Sie eine partitionierte Sammlung parallel abfragen können. Weitere Informationen finden Sie in Codebeispielen zum Arbeiten mit den SDKs. Parallele Abfragen wurden entwickelt, um die Abfragelatenz und den Durchsatz gegenüber ihrem seriellen Gegenstück zu verbessern.
(a) Tuning setMaxDegreeOfParallelism: Parallele Abfragen funktionieren, indem sie mehrere Partitionen parallel abfragen. Daten aus einer einzelnen partitionierten Sammlung werden jedoch in Bezug auf die Abfrage fortlaufend abgerufen. Verwenden Sie also setMaxDegreeOfParallelism, um die Anzahl an Partitionen festzulegen, die die größte Chance hat, die leistungsstärkste Abfrage zu ermöglichen, vorausgesetzt, alle anderen Systembedingungen bleiben gleich. Wenn Sie die Anzahl der Partitionen nicht kennen, können Sie setMaxDegreeOfParallelism verwenden, um eine hohe Zahl festzulegen, und das System wählt das Minimum (Anzahl der Partitionen, vom Benutzer bereitgestellte Eingabe) als maximale Parallelität aus.
Es ist wichtig zu beachten, dass parallele Abfragen die besten Vorteile erzielen, wenn die Daten gleichmäßig über alle Partitionen in Bezug auf die Abfrage verteilt werden. Wenn die partitionierte Sammlung so partitioniert ist, dass alle oder die meisten der von einer Abfrage zurückgegebenen Daten in wenigen Partitionen (im schlimmsten Fall in einer einzigen Partition) konzentriert sind, wird die Leistung der Abfrage von diesen Partitionen eingeschränkt.
(b) Tuning setMaxBufferedItemCount: Parallele Abfrage ist für das Vorabfetch von Ergebnissen konzipiert, während der aktuelle Batch der Ergebnisse vom Client verarbeitet wird. Das Vorabrufen hilft bei der allgemeinen Latenzverbesserung einer Abfrage. setMaxBufferedItemCount begrenzt die Anzahl der vorab zurückgegebenen Ergebnisse. Durch das Einstellen von setMaxBufferedItemCount auf die erwartete Anzahl der zurückgegebenen Ergebnisse (oder eine höhere Zahl) kann die Abfrage den maximalen Nutzen aus dem Prefetching ziehen.
Das Vorabfetching funktioniert unabhängig vom MaxDegreeOfParallelism auf die gleiche Weise, und es gibt einen einzelnen Puffer für die Daten aus allen Partitionen.
Backoff-Mechanismus in getRetryAfterInMilliseconds-Intervallen implementieren
Während der Leistungstests sollten Sie die Last erhöhen, bis eine kleine Anzahl von Anforderungen gedrosselt wird. Wenn die Drosselung aktiviert wurde, sollte die Clientanwendung für das vom Server angegebene Wiederholungsintervall nachgeben. Durch die Einhaltung des Backoffs wird sichergestellt, dass Sie nur minimale Zeit mit Warten zwischen Wiederholungsversuchen verbringen müssen. Unterstützung für Wiederholungsrichtlinien ist in Version 1.8.0 und höher des Azure Cosmos DB Sync Java SDK enthalten. Weitere Informationen finden Sie unter "getRetryAfterInMilliseconds".
Aufskalieren Ihrer Clientworkload
Wenn Sie auf hohen Durchsatzebenen (>50.000 RU/s) testen, kann die Clientanwendung aufgrund der Cpu- oder Netzwerkauslastung des Computers zu einem Engpass werden. Wenn dieser Punkt erreicht wird, können Sie das Azure Cosmos DB-Konto weiter auslasten, indem Sie Ihre Clientanwendungen auf mehrere Server horizontal hochskalieren.
Namensbasierte Adressierung verwenden
Verwenden Sie namensbasierte Adressierung, wobei Links das Format
dbs/MyDatabaseId/colls/MyCollectionId/docs/MyDocumentIdanstelle von SelfLinks (_self) aufweisen, die das Formatdbs/<database_rid>/colls/<collection_rid>/docs/<document_rid>aufweisen, um das Abrufen von ResourceIds aller Ressourcen zu vermeiden, die zum Erstellen der Verknüpfung verwendet werden. Da diese Ressourcen neu erstellt werden (möglicherweise mit demselben Namen), hilft das Zwischenspeichern dieser Ressourcen möglicherweise nicht.Optimieren der Seitengröße für Abfragen/Lesefeeds für eine bessere Leistung
Beim Ausführen eines Massenlesevorgangs von Dokumenten mithilfe von Lesefeedfunktionen (z. B. readDocuments) oder beim Ausgeben einer SQL-Abfrage werden die Ergebnisse in segmentierter Weise zurückgegeben, wenn das Resultset zu groß ist. Standardmäßig werden Ergebnisse in Blöcken von 100 Elementen oder 1 MB zurückgegeben, je nachdem, welcher Grenzwert zuerst erreicht wird.
Um die Anzahl von Netzwerk-Roundtrips zu reduzieren, die zum Abrufen aller anwendbaren Ergebnisse erforderlich sind, können Sie die Seitengröße mithilfe des Anforderungsheaders "x-ms-max-item-count " auf bis zu 1000 erhöhen. In Fällen, in denen Nur wenige Ergebnisse angezeigt werden müssen, z. B. wenn Ihre Benutzeroberfläche oder Anwendungs-API nur 10 Ergebnisse pro Zeit zurückgibt, können Sie auch die Seitengröße auf 10 verringern, um den für Lese- und Abfragen verbrauchten Durchsatz zu verringern.
Sie können auch das Seitenformat mithilfe der setPageSize-Methode festlegen.
Indizierungsrichtlinie
Beschleunigen von Schreibvorgängen durch Ausschließen nicht verwendeter Pfade von der Indizierung
Mit der Indizierungsrichtlinie von Azure Cosmos DB können Sie angeben, welche Dokumentpfade mithilfe von Indizierungspfaden (setIncludedPaths und setExcludedPaths) ein- oder ausgeschlossen werden sollen. von der Indizierung ausgeschlossen werden sollen. Der folgende Code veranschaulicht beispielsweise, wie ein vollständiger Abschnitt (Unterstruktur) der Dokumente mithilfe des "*"-Wildcards von der Indizierung ausgeschlossen wird.
Synchronisieren von Java SDK V2 (Maven com.microsoft.azure::azure-documentdb)
Index numberIndex = Index.Range(DataType.Number); numberIndex.set("precision", -1); indexes.add(numberIndex); includedPath.setIndexes(indexes); includedPaths.add(includedPath); indexingPolicy.setIncludedPaths(includedPaths); collectionDefinition.setIndexingPolicy(indexingPolicy);Weitere Informationen finden Sie unter Indizierungsrichtlinien für Azure Cosmos DB.
Durchsatz
Messen und Optimieren (Senken) der Anzahl von Anforderungseinheiten pro Sekunde
Azure Cosmos DB bietet vielfältige Datenbankvorgänge (einschließlich relationaler und hierarchischer Abfragen mit UDFs, gespeicherter Prozeduren und Trigger), die alle in den Dokumenten innerhalb einer Datenbanksammlung ausgeführt werden. Die Kosten im Zusammenhang mit diesen Vorgängen variieren basierend auf dem CPU-, E/A- und Speicheraufwand, der für den jeweiligen Vorgang erforderlich ist. Anstelle sich Gedanken über Hardwareressourcen und deren Verwaltung zu machen, können Sie sich eine Anforderungseinheit (RU) als alleinige Maßeinheit für die Ressourcen vorstellen, die für das Durchführen der verschiedenen Datenbankvorgänge und das Ausführen einer Anwendungsanforderung erforderlich sind.
Der Durchsatz wird basierend auf der für jeden Container festgelegten Anzahl von Anforderungseinheiten bereitgestellt. Der Verbrauch von Anforderungseinheiten wird als Rate pro Sekunde bemessen. Anwendungen, die die bereitgestellte Anforderungseinheitenrate für ihre Container überschreiten, werden begrenzt, bis die Rate wieder unter das bereitgestellte Niveau für den Container fällt. Wenn Ihre Anwendung einen höheren Durchsatz erfordert, können Sie ihn durch Bereitstellung zusätzlicher Anforderungseinheiten erhöhen.
Die Komplexität einer Abfrage wirkt sich darauf aus, wie viele Anforderungseinheiten für einen Vorgang verbraucht werden. Die Anzahl von Prädikaten, die Art der Prädikate, die Anzahl von UDFs und die Größe des Quelldatasets beeinflussen die Kosten von Abfragevorgängen.
Um den Aufwand eines Vorgangs (Erstellen, Aktualisieren oder Löschen) zu messen, prüfen Sie den x-ms-request-charge-Header (oder die entsprechende RequestCharge-Eigenschaft in ResourceResponse<T oder FeedResponse T>, um die Anzahl der von diesen Vorgängen verbrauchten Anforderungseinheiten zu messen.<>
Synchronisieren von Java SDK V2 (Maven com.microsoft.azure::azure-documentdb)
ResourceResponse<Document> response = client.createDocument(collectionLink, documentDefinition, null, false); response.getRequestCharge();Bei der in diesem Header zurückgegebenen Anforderungsbelastung handelt es sich um einen Bruchteil Ihres bereitgestellten Durchsatzes. Wenn Sie beispielsweise 2000 RU/s bereitgestellt haben und die vorherige Abfrage 1.000 1 KB-Dokumente zurückgibt, beträgt die Kosten für den Vorgang 1000. Somit werden vom Server innerhalb einer Sekunde nur zwei solcher Anforderungen berücksichtigt, und für weitere Anforderungen wird die Rate begrenzt. Weitere Informationen finden Sie unter Anforderungseinheiten in DocumentDB sowie unter dem Rechner für Anforderungseinheiten.
Behandeln von Ratenbeschränkungen/zu hohen Anforderungsraten
Wenn ein Client versucht, den für ein Konto reservierten Durchsatz zu überschreiten, wird die Serverleistung nicht beeinträchtigt, und es wird kein über die reservierte Kapazität hinausgehender Durchsatz in Anspruch genommen. Der Server beendet die Anforderung präemptiv mit „RequestRateTooLarge“ (HTTP-Statuscode 429) und gibt den Header x-ms-retry-after-ms zurück. Darin ist die Zeitspanne (in Millisekunden) angegeben, die der Benutzer warten muss, bis ein neuer Anforderungsversuch unternommen werden kann.
HTTP Status 429, Status Line: RequestRateTooLarge x-ms-retry-after-ms :100Alle SDKs fangen diese Antwort implizit ab, berücksichtigen den vom Server angegebenen Header vom Typ „retry-after“ und wiederholen die Anforderung. Wenn nicht mehrere Clients gleichzeitig auf Ihr Konto zugreifen, wird die nächste Wiederholung erfolgreich ausgeführt.
Wenn Mehrere Clients kumulativ über der Anforderungsrate ausgeführt werden, reicht die standardmäßige Wiederholungsanzahl, die derzeit vom Client intern auf 9 festgelegt ist, möglicherweise nicht aus. in diesem Fall löst der Client eine DocumentClientException mit Dem Statuscode 429 an die Anwendung aus. Die Standardmäßige Wiederholungsanzahl kann mithilfe von setRetryOptions in der ConnectionPolicy-Instanz geändert werden. Standardmäßig wird die DocumentClientException mit Dem Statuscode 429 nach einer kumulierten Wartezeit von 30 Sekunden zurückgegeben, wenn die Anforderung weiterhin über der Anforderungsrate ausgeführt wird. Dies gilt auch, wenn die aktuelle Wiederholungsanzahl unter der maximalen Wiederholungsanzahl liegt – ganz gleich, ob es sich dabei um den Standardwert (9) oder um einen benutzerdefinierten Wert handelt.
Das automatisierte Wiederholungsverhalten trägt zwar bei den meisten Anwendungen zur Verbesserung der Resilienz und Nutzbarkeit bei, kann bei Leistungsbenchmarks aber auch hinderlich sein (insbesondere beim Ermitteln der Latenz). Die Wartezeit für den Client nimmt stark zu, wenn das Experiment die Serverdrosselung erreicht und damit die automatische Wiederholung durch das Client-SDK auslöst. Ermitteln Sie zur Vermeidung von Latenzspitzenwerten bei Leistungsexperimenten die von den einzelnen Vorgängen zurückgegebene Belastung, und stellen Sie sicher, dass die Anforderungen die reservierte Anforderungsrate nicht überschreiten. Weitere Informationen finden Sie unter Anforderungseinheiten in DocumentDB.
Konzipieren für kleinere Dokumente und höheren Durchsatz
Die Anforderungsbelastung (die Kosten für die Anforderungsverarbeitung) eines Vorgangs hängt direkt mit der Größe des Dokuments zusammen. Vorgänge für große Dokumente sind teurer als Vorgänge für kleine Dateien.
Nächste Schritte
Weitere Informationen zum Entwerfen einer auf Skalierung und hohe Leistung ausgelegten Anwendung finden Sie unter Partitionieren und Skalieren in Azure Cosmos DB.