Bewährte Methoden für Azure Cosmos DB Java SDK
GILT FÜR: NoSQL
In diesem Artikel werden die bewährten Methoden für die Verwendung des Azure Cosmos DB Java SDK beschrieben. Wenn Sie diese Vorgehensweisen befolgen, lassen sich Wartezeiten reduzieren, die Verfügbarkeit verbessern und die Gesamtleistung steigern.
Checkliste
Überprüft | Thema | Details/Links |
---|---|---|
SDK-Version | Verwenden Sie für eine optimale Leistung stets die aktuelle Version des Azure Cosmos DB SDK. | |
Singleton-Client | Verwenden Sie für eine bessere Leistung eine Einzelinstanz von CosmosClient für die Lebensdauer Ihrer Anwendung. |
|
Regions | Führen Sie Ihre Anwendung nach Möglichkeit in der gleichen Azure-Region aus wie Ihr Azure Cosmos DB-Konto. Durch diese Vorgehensweise lassen sich Wartezeiten reduzieren. Aktivieren Sie 2–4 Regionen, und replizieren Sie Ihre Konten in mehreren Regionen, um die beste Verfügbarkeit zu erzielen. Aktivieren Sie für Produktionsworkloads ein vom Dienst verwaltetes Failover. Ohne diese Konfiguration verliert das Konto für die gesamte Dauer des Ausfalls der Schreibregion die Schreibverfügbarkeit, da das manuelle Failover aufgrund der fehlenden Regionskonnektivität nicht erfolgreich verläuft. Informationen zum Hinzufügen mehrerer Regionen mit dem Java SDK finden Sie hier | |
Verfügbarkeit und Failover | Legen Sie die preferredRegions im v4 SDK fest. Während eines Failovers werden Schreibvorgänge an die aktuelle Schreibregion gesendet, und alle Lesevorgänge werden an die erste Region in der Liste der bevorzugten Regionen gesendet. Weitere Informationen zu regionalen Failovermechanismen finden Sie im Leitfaden zur Problembehandlung bei der Verfügbarkeit. | |
CPU | Aufgrund fehlender Ressourcen auf Ihrem Clientcomputer kann es zu Verbindungs-/Verfügbarkeitsproblemen kommen. Überwachen Sie die CPU-Auslastung auf Knoten, auf denen der Azure Cosmos DB-Client ausgeführt wird, und führen Sie bei einer sehr hohen Auslastung eine Hoch- bzw. Aufskalierung durch. | |
Hosting | Bei den meisten gängigen Fällen von Produktionsworkloads wird dringend empfohlen, nach Möglichkeit mindestens 4 Kerne und VMs mit 8 GB Arbeitsspeicher zu verwenden. | |
Konnektivitätsmodi | Verwenden Sie für eine optimale Leistung den direkten Modus. Entsprechende Anweisungen dazu finden Sie in der Dokumentation zum V4-SDK. | |
Netzwerk | Wenn Sie einen virtuellen Computer zum Ausführen Ihrer Anwendung verwenden, aktivieren Sie den beschleunigten Netzwerkbetrieb auf Ihrem virtuellen Computer, um Engpässen aufgrund von hohem Datenverkehrsaufkommen entgegenzuwirken und Wartezeiten oder CPU-Jitter zu reduzieren. Darüber hinaus sollten Sie die Verwendung eines leistungsstärkeren virtuellen Computers in Betracht ziehen, bei dem die maximale CPU-Auslastung unter 70 % liegt. | |
Kurzfristige Portauslastung | Für Verbindungen mit geringer Dichte oder sporadische Verbindungen empfiehlt es sich, idleEndpointTimeout auf einen höheren Wert festzulegen. Mithilfe der idleEndpointTimeout -Eigenschaft in DirectConnectionConfig lässt sich die Zeit steuern, in der nicht verwendete Verbindungen geschlossen werden. Dadurch lässt sich die Anzahl von nicht verwendeten Verbindungen reduzieren. Standardmäßig werden Verbindungen im Leerlauf mit einem Endpunkt eine Stunde lang offen gehalten. Wenn für die Dauer des Endpunkttimeouts im Leerlauf keine Anforderungen an einen bestimmten Endpunkt gestellt werden, schließt der direkte Client alle Verbindungen mit diesem Endpunkt, um Ressourcen und E/A-Kosten zu sparen. |
|
Verwenden des geeigneten Planers (Vermeiden des Diebstahls von Eventloop-E/A-Threads in Netty) | Vermeiden Sie es, Aufrufe zu blockieren: .block() . Die gesamte Aufrufliste ist asynchron, um von asynchronen API-Mustern und der Verwendung geeigneter Threads und Scheduler zu profitieren. |
|
End-to-End-Timeouts | Um End-to-End-Timeouts zu erhalten, implementieren Sie die End-to-End-Timeout-Richtlinie im Java SDK. Weitere Einzelheiten zu Timeouts bei Azure Cosmos DB finden Sie hier | |
Wiederholungslogik | Ein vorübergehender Fehler ist ein Fehler, dessen Ursache sich innerhalb kurzer Zeit von selbst auflöst. Anwendungen, die eine Verbindung mit der Datenbank herstellen, sollten dafür ausgelegt sein, vorübergehende Fehler zu tolerieren. Behandeln Sie diese Fehler, indem Sie Wiederholungslogik in Ihrem Code implementieren und vermeiden, dass die Fehler Benutzern als Anwendungsfehler gemeldet werden. Das SDK verfügt über integrierte Logik, um diese vorübergehenden Fehler bei wiederholbaren Anforderungen wie Lese- oder Abfragevorgängen zu behandeln. Da Schreibvorgänge nicht idempotent sind, versucht das SDK bei vorübergehenden Fehlern nicht, diese Vorgänge zu wiederholen. Benutzer können jedoch Wiederholungslogik für Drosselungen konfigurieren. Einzelheiten zu den Fehlern, bei denen ein Vorgang wiederholt wird, finden Sie hier | |
Zwischenspeichern von Datenbank-/Sammlungsnamen | Rufen Sie die Namen Ihrer Datenbanken und Container aus der Konfiguration ab, oder speichern Sie sie beim Starten zwischen. Aufrufe wie CosmosAsyncDatabase#read() oder CosmosAsyncContainer#read() führen zu Metadatenaufrufen an den Dienst. Dabei wird die für das System reservierte RU-Kapazität genutzt. createDatabaseIfNotExists() sollte ebenfalls nur einmal zum Einrichten der Datenbank verwendet werden. Diese Vorgänge sollten insgesamt selten ausgeführt werden. |
|
Parallele Abfragen | Für geringere Wartezeiten und einen höheren Durchsatz bei Ihren Abfragen unterstützt das Azure Cosmos DB SDK das parallele Ausführen von Abfragen. Es wird empfohlen, die maxDegreeOfParallelism -Eigenschaft innerhalb von CosmosQueryRequestsOptions auf die Anzahl Ihrer Partitionen festzulegen. Wenn Sie die Anzahl der Partitionen nicht kennen, legen Sie den Wert auf -1 fest, um die beste Latenz zu erhalten. Legen Sie außerdem maxBufferedItemCount auf die erwartete Anzahl von zurückgegebenen Ergebnissen fest, um die Anzahl von vorab abgerufenen Ergebnissen zu begrenzen. |
|
Backoffs bei Leistungstests | Wenn Sie Leistungstests für Ihre Anwendung durchführen, sollten Sie Backoffs mit RetryAfter -Intervallen implementieren. Durch das Aussetzen wird die geringstmögliche Wartezeit zwischen den Wiederholungsversuchen gewährleistet. |
|
Indizierung | Die Indizierungsrichtlinie von Azure Cosmos DB ermöglicht auch die Verwendung von Indizierungspfaden IndexingPolicy#getIncludedPaths() und IndexingPolicy#getExcludedPaths() , um anzugeben, welche Dokumentpfade in die Indizierung ein- bzw. ausgeschlossen werden sollen. Stellen Sie für schnellere Schreibvorgänge sicher, dass nicht verwendete Pfade von der Indizierung ausgeschlossen sind. Ein Beispiel für das Erstellen von Indizes mit dem SDK finden Sie hier |
|
Dokumentgröße | Der Anforderungsaufwand eines bestimmten Vorgangs hängt direkt mit der Größe des Dokuments zusammen. Es wird empfohlen, die Größe Ihrer Dokumente zu reduzieren, da Vorgänge für große Dokumente mehr kosten als Vorgänge für kleinere Dokumente. | |
Page Size | Abfrageergebnisse werden standardmäßig in Blöcken mit je 100 Elementen oder 4 MB zurückgegeben (je nachdem, welcher Grenzwert zuerst erreicht wird). Wenn eine Abfrage mehr als 100 Elemente zurückgibt, erhöhen Sie die Seitengröße, um die Anzahl der erforderlichen Roundtrips zu reduzieren. Der Arbeitsspeicherverbrauch steigt, wenn die Seitengröße zunimmt. | |
Aktivieren von Abfragemetriken | Eine zusätzliche Protokollierung ihrer Back-End-Abfrageausführungen erhalten Sie, wenn Sie die Anweisungen zum Erfassen von SQL-Abfragemetriken mit dem Java SDK befolgen. | |
SDK-Protokollierung | Verwenden Sie die SDK-Protokollierung, um zusätzliche Diagnoseinformationen zu erfassen und Probleme im Zusammenhang mit der Wartezeit zu beheben. Protokollieren Sie CosmosDiagnostics im Java SDK, um detailliertere Azure Cosmos DB-Diagnoseinformationen für die aktuelle Anforderung an den Dienst zu erhalten. Erfassen Sie beispielsweise Diagnoseinformationen für jede Ausnahme und für abgeschlossene Vorgänge, wenn CosmosDiagnostics#getDuration() einen festgelegten Schwellenwert überschreitet (wenn Sie z. B. über eine SLA von 10 Sekunden verfügen, erfassen Sie Diagnoseinformationen, sobald getDuration() > 10 Sekunden ist). Es wird empfohlen, diese Diagnosen nur während Leistungstests zu verwenden. Weitere Informationen finden Sie unter Erfassen von Diagnosen im Java SDK. |
|
Vermeiden der Verwendung von Sonderzeichen in Bezeichnern | Einige Zeichen sind nur eingeschränkt erlaubt und können in einigen Bezeichnern nicht verwendet werden: „/“, „\“, „?“, „#“. Generell wird empfohlen, keine Sonderzeichen in Bezeichnern wie Datenbankname, Sammlungsname, Objekt-ID oder Partitionsschlüssel zu verwenden, um ein unerwartetes Verhalten zu vermeiden. |
Bewährte Methoden bei Verwendung des Gatewaymodus
Azure Cosmos DB-Anforderungen erfolgen im Gatewaymodus über HTTPS/REST. Sie unterliegen dem Standardverbindungslimit pro Hostname oder IP-Adresse. Unter Umständen müssen Sie einen anderen Wert für maxConnectionPoolSize festlegen (100 bis 1.000), damit die Clientbibliothek mehrere Verbindungen mit Azure Cosmos DB gleichzeitig nutzen kann. Im Java v4 SDK ist der Standardwert für GatewayConnectionConfig#maxConnectionPoolSize
1000. Zum Ändern des Werts können Sie GatewayConnectionConfig#maxConnectionPoolSize
auf einen anderen Wert festlegen.
Bewährte Methoden für schreibintensive Workloads
Legen Sie für Workloads mit hohen Erstellungsnutzlasten die Anforderungsoption CosmosClientBuilder#contentResponseOnWriteEnabled()
auf false
fest. Der Dienst gibt die erstellte oder aktualisierte Ressource nicht mehr an das SDK zurück. Normalerweise verfügt die Anwendung über das zu erstellende Objekt, sodass sie den Dienst nicht benötigt, um es zurückzugeben. Die Headerwerte sind nach wie vor zugänglich wie etwa eine Anforderungsgebühr. Die Deaktivierung der Inhaltsantwort kann die Leistung verbessern, da das SDK keinen Speicher mehr zuweisen oder den Hauptteil der Antwort nicht mehr serialisieren muss. Dies reduziert auch die Auslastung der Netzwerkbandbreite, um die Leistung weiter zu steigern.
Nächste Schritte
Weitere Informationen zu Leistungstipps für das Java SDK finden Sie unter Leistungstipps für das Azure Cosmos DB Java SDK v4.
Weitere Informationen zum Entwerfen einer auf Skalierung und hohe Leistung ausgelegten Anwendung finden Sie unter Partitionieren und Skalieren in Azure Cosmos DB.
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