Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Bewährte Methoden für Amazon DocumentDB Elastic Cluster
<a name="elastic-best-practices"></a>

Lernen Sie bewährte Methoden für die Arbeit mit elastischen Amazon DocumentDB-Clustern kennen. Alle [bewährten Methoden für instanzbasierte Amazon DocumentDB-Cluster gelten auch für elastische Cluster](https://docs.aws.amazon.com/documentdb/latest/devguide/best_practices.html). Dieser Abschnitt wird fortlaufend aktualisiert, wenn neue bewährte Methoden identifiziert werden.

**Topics**
+ [Shard-Schlüssel auswählen](#choosing-shard-keys)
+ [Verbindungsverwaltung](#connection-management)
+ [Sammlungen, die nicht geteilt wurden](#unsharded-collections)
+ [Skalierung elastischer Cluster](#scaling)
+ [Überwachung elastischer Cluster](#monitoring-elastic-clusters)

## Shard-Schlüssel auswählen
<a name="choosing-shard-keys"></a>

In der folgenden Liste werden Richtlinien für die Erstellung von Shard-Schlüsseln beschrieben.
+ Verwenden Sie einen gleichmäßig verteilten Hashschlüssel, um Ihre Daten auf alle Shards in Ihrem Cluster zu verteilen (vermeiden Sie Hotkeys).
+ Verwenden Sie Ihren Shard-Schlüssel in allen read/update /delete-Anfragen, um Scatter-Gather-Abfragen zu vermeiden.
+ Vermeiden Sie verschachtelte Shard-Schlüssel, wenn Sie /delete-Operationen ausführen. read/update
+ Wenn Sie Batch-Operationen ausführen, sollten Sie `ordered` den Wert auf False setzen, damit alle Shards parallel ausgeführt werden können und die Latenzen verbessert werden.

## Verbindungsverwaltung
<a name="connection-management"></a>

In der folgenden Liste werden Richtlinien für die Verwaltung Ihrer Verbindungen zu Ihrer Datenbank beschrieben.
+ Überwachen Sie die Anzahl Ihrer Verbindungen und wie häufig neue Verbindungen geöffnet und geschlossen werden.
+ Verteilen Sie Ihre Verbindungen auf alle Subnetze in der Konfiguration Ihrer Anwendung. Wenn Ihr Cluster in mehreren Subnetzen konfiguriert ist, Sie aber nur eine Teilmenge der Subnetze nutzen, kann es zu Engpässen bei der maximalen Anzahl von Verbindungen kommen.

## Sammlungen, die nicht geteilt wurden
<a name="unsharded-collections"></a>

Im Folgenden wird eine Richtlinie für Sammlungen ohne Sharding beschrieben.
+ Versuchen Sie bei der Arbeit mit Sammlungen ohne Sharded, um die Last zu verteilen, häufig genutzte Sammlungen ohne Sharded in verschiedenen Datenbanken zu speichern. Elastische Amazon DocumentDB-Cluster platzieren Datenbanken auf verschiedenen Shards und legen Sammlungen ohne Shards für dieselbe Datenbank auf demselben Shard zusammen. 

## Skalierung elastischer Cluster
<a name="scaling"></a>

In der folgenden Liste werden Richtlinien für die Skalierung Ihrer elastischen Cluster beschrieben.
+ Skalierungsvorgänge können für einen kurzen Zeitraum zu zeitweiligen Datenbank- und Netzwerkfehlern führen. Vermeiden Sie nach Möglichkeit eine Skalierung zu Spitzenzeiten. Versuchen Sie, während der Wartungsfenster zu skalieren.
+ Das Hoch- und Herunterskalieren der Shard-Kapazität (Änderung der vCPU-Anzahl pro Shard) zur Erhöhung der Rechenleistung wird dem Erhöhen oder Verringern der Shard-Anzahl vorgezogen, da dies schneller ist und eine kürzere Dauer von zeitweiligen Datenbank- und Netzwerkfehlern hat.
+ Wenn Sie ein Wachstum erwarten, sollten Sie die Anzahl der Shards erhöhen, anstatt die Shard-Kapazität zu skalieren. Auf diese Weise können Sie Ihren Cluster skalieren, indem Sie die Shard-Kapazität für Szenarien erhöhen, in denen Sie schnell skalieren müssen.
+ Überwachen Sie Ihre clientseitigen Wiederholungsrichtlinien und versuchen Sie es erneut mit exponentiellem Backoff und Jitter, um eine Überlastung Ihrer Datenbank zu vermeiden, wenn bei der Skalierung Fehler auftreten.
+ Das Ändern der Anzahl der Shards kann einige Zeit in Anspruch nehmen, da Daten sicher von einem Shard auf einen anderen übertragen werden müssen. Um das Fehlerrisiko zu minimieren, empfehlen wir, den Clusterstatus während der Änderung nicht zu beenden oder anderweitig zu ändern.

## Überwachung elastischer Cluster
<a name="monitoring-elastic-clusters"></a>

In der folgenden Liste werden Richtlinien für die Überwachung Ihrer elastischen Cluster beschrieben.
+ Verfolgen Sie das Verhältnis zwischen Spitzenwert und Durchschnitt Ihrer Metriken pro Shard, um festzustellen, ob Sie ungleichmäßigen Traffic generieren (einen Hotspot haben). key/hot Die wichtigsten Kennzahlen zur Erfassung des Verhältnisses zwischen Spitzenwert und Durchschnitt sind:
  + `PrimaryInstanceCPUUtilization`
    + Dies kann auf der Ebene pro Shard überwacht werden.
    + Auf Clusterebene können Sie den Mittelwert bis zur Abweichung von p99 überwachen.
  + `PrimaryInstanceFreeableMemory`
    + Dies kann auf der Ebene pro Shard überwacht werden.
    + Auf Clusterebene können Sie den Mittelwert bis zur Abweichung von p99 überwachen.
  + `DatabaseCursorsMax`
    + Dies sollte auf der Ebene pro Shard überwacht werden, um die Verzerrung zu ermitteln.
  + `Documents-Inserted/Updated/Returned/Deleted`
    + Dies sollte auf der Ebene pro Shard überwacht werden, um die Verzerrung zu ermitteln.