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 das Entwerfen und effektive Verwenden von Partitionsschlüsseln in DynamoDB
Der Primärschlüssel, der jedes Element in einer Amazon-DynamoDB-Tabelle eindeutig identifiziert, kann einfach (nur Partitionsschlüssel) oder zusammengesetzt (Partitionsschlüssel in Kombination mit Sortierschlüssel) sein.
Sie sollten die Anwendung für eine gleichmäßige Aktivität über alle Partitionsschlüssel in der Tabelle und ihre sekundären Indizes hinweg entwerfen. Sie können ermitteln, welche Zugriffsmuster Ihre Anwendung braucht und wie viele Lese- und Schreibeinheiten jede Tabelle und jeder sekundäre Index insgesamt benötigen.
**Anmerkung**
Adaptive Kapazität gilt für den On-Demand-Modus und die bereitgestellte Kapazität.
Jede Partition in einer DynamoDB-Tabelle ist so konzipiert, dass sie eine maximale Kapazität von 3 000 Leseeinheiten pro Sekunde und 1 000 Schreibeinheiten pro Sekunde bietet. Eine Leseeinheit entspricht einem strikt konsistenten Lesevorgang pro Sekunde oder zwei letztendlich konsistenten Lesevorgängen pro Sekunde für ein Element mit einer Größe von bis zu 4 KB. Eine Schreibeinheit entspricht einem Schreibvorgang pro Sekunde für ein Element mit einer Größe von bis zu 1 KB.
Bei der Auswertung der Durchsatzgrenzen für die Partitionen Ihrer Tabelle müssen Sie die Größe der Elemente berücksichtigen. Wenn die Tabelle beispielsweise Elemente mit einer Größe von 20 KB enthält, verbraucht ein einziger konsistenter Lesevorgang 5 Leseeinheiten. Das bedeutet, dass Sie für dieses einzelne Element 600 konsistente Lesevorgänge pro Sekunde gleichzeitig ausführen können, bevor Sie die Partitionsgrenzen erreichen. Der Gesamtdurchsatz über alle Partitionen in der Tabelle hinweg kann durch den bereitgestellten Durchsatz im Modus bereitgestellter Kapazität oder durch die Durchsatzgrenze auf Tabellenebene im On-Demand-Modus eingeschränkt sein. Weitere Informationen finden Sie unter [Servicekontingente](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ServiceQuotas.html).
**Topics**
+ [Entwerfen von Partitionsschlüsseln zum Verteilen Ihres Workloads in DynamoDB](bp-partition-key-uniform-load.md)
+ [Verwenden von Schreib-Sharding zur gleichmäßigen Verteilung von Workloads in Ihrer DynamoDB-Tabelle](bp-partition-key-sharding.md)
+ [Effiziente Verteilung der Schreibaktivität beim Hochladen von Daten in DynamoDB](bp-partition-key-data-upload.md)
# Entwerfen von Partitionsschlüsseln zum Verteilen Ihres Workloads in DynamoDB
Der Partitionsschlüsselabschnitt des primären Schlüssels einer Tabelle legt die logischen Partitionen fest, in denen die Daten einer Tabelle gespeichert werden. Dies wirkt sich wiederum auf die zugrunde liegenden physischen Partitionen aus. Ein Partitionsschlüsseldesign, das I/O Anfragen nicht effektiv verteilt, kann zu „heißen“ Partitionen führen, die zu Drosselung führen und Ihre bereitgestellte Kapazität ineffizient nutzen. I/O
Die optimale Nutzung des bereitgestellten Durchsatzes einer Tabelle ist nicht nur von den Workload-Mustern einzelner Elemente abhängig, sondern auch vom Design des Partitionsschlüssels. Dies bedeutet nicht, dass Sie auf alle Partitionsschlüsselwerte zugreifen müssen, um einen effizienten Durchsatz zu erzielen. Es bedeutet noch nicht einmal, dass der Prozentsatz der Partitionsschlüsselwerte, auf die zugegriffen wird, hoch sein muss. Es bedeutet jedoch, dass die Anforderungen umso weiter über den partitionierten Bereich verteilt werden, je mehr unterschiedliche Partitionsschlüsselwerte dem Zugriff durch Ihren Workload unterliegen. Im Allgemeinen nutzen Sie den bereitgestellten Durchsatz effizienter, wenn das Verhältnis zwischen den Partitionsschlüsselwerten, die einem Zugriff unterliegen, und der Gesamtzahl der Partitionsschlüsselwerte zunimmt.
Im Folgenden finden Sie einen Vergleich der Effizienz des bereitgestellten Durchsatzes für einige häufige Partitionsschlüsselschemas.
****
| Partitionsschlüsselwert | Gleichmäßigkeit |
| --- | --- |
| Benutzer-ID, in der die Anwendung viele Benutzer hat. | Gut |
| Statuscode, in dem es nur einige wenige mögliche Statuscodes gibt. | Schlecht |
| Erstellungsdatum eines Elements, gerundet auf den nächsten Zeitraum (z. B. Tag, Stunde oder Minute). | Schlecht |
| Geräte-ID, in der jedes Gerät mit relativ ähnlichen Intervallen auf Daten zugreift. | Gut |
| Geräte-ID, wobei eine bei weitem beliebter als alle anderen ist, auch wenn es viele überwachte Geräte gibt. | Schlecht |
Wenn eine einzelne Tabelle nur eine kleine Anzahl von Partitionsschlüsselwerten besitzt, sollten Sie in Betracht ziehen, die Schreibvorgänge auf mehrere unterschiedliche Partitionsschlüsselwerte zu verteilen. Mit anderen Worten, strukturieren Sie die Primärschlüsselelemente, um einen "heißen" (stark angeforderten) Partitions-Schlüsselwert, der die Gesamtleistung verlangsamt, zu vermeiden.
Nehmen wir als Beispiel eine Tabelle mit einem zusammengesetzten Primärschlüssel. Der Partitionsschlüssel repräsentiert das Erstelldatum des Elements, gerundet auf den nächsten Tag. Der Sortierschlüssel ist eine Element-ID. An einem bestimmten Tag, beispielsweise `2014-07-09`, werden **alle** neuen Elemente zu diesem bestimmten Partitionsschlüsselwert (und der entsprechenden physischen Partition) geschrieben.
Wenn die Tabelle vollständig in eine einzelne Partition passt (unter Berücksichtigung des Wachstums Ihrer Daten über die Zeit) und die Lese- und Schreibdurchsatzanforderungen Ihrer Anwendung die Lese- und Schreibkapazitäten einer einzelnen Partition nicht überschreiten, erfährt Ihre Anwendung keine unerwartete Drosselung durch eine Partitionierung.
Informationen zur Verwendung von NoSQL Workbench für DynamoDB zur Visualisierung Ihres Partitionsschlüsseldesigns finden Sie unter [Erstellen von Datenmodellen mit NoSQL Workbench](workbench.Modeler.md).
# Verwenden von Schreib-Sharding zur gleichmäßigen Verteilung von Workloads in Ihrer DynamoDB-Tabelle
Eine Möglichkeit, Schreibvorgänge besser auf einen Partitionsschlüsselbereich in Amazon DynamoDB zu verteilen, besteht darin, den Speicherplatz zu erweitern. Dies kann auf verschiedene Arten geschehen. Sie können den Partitionsschlüsselwerten eine Zufallszahl hinzufügen, um die Elemente auf Partitionen zu verteilen. Oder Sie können eine Zahl verwenden, die basierend auf einer Abfrage berechnet wird.
## Sharding unter Verwendung zufälliger Suffixe
Eine Strategie zur gleichmäßigeren Verteilung von Workloads auf einen Partitions-Schlüsselraum besteht darin, am Ende der Partitions-Schlüsselwerte eine zufällige Zahl hinzuzufügen. Anschließend werden die Schreibvorgänge zufällig auf den größeren Raum verteilt.
Für einen Partitionsschlüssel beispielsweise, der das Datum des aktuellen Tages repräsentiert, könnten Sie eine zufällige Zahl zwischen `1` und `200` auswählen, und diese als Suffix mit dem Datum verketten. So ergeben sich Partitions-Schlüsselwerte wie `2014-07-09.1`, `2014-07-09.2` usw. bis `2014-07-09.200`. Durch die Randomisierung des Partitionsschlüssels werden die Schreibvorgänge in die Tabelle jeden Tag gleichmäßig auf mehrere Partitionen verteilt. Dies führt zu einer besseren Parallelverarbeitung und einem höheren Gesamtdurchsatz.
Um alle Elemente für einen bestimmten Tag zu lesen, müssten Sie allerdings die Elemente für alle Suffixe abfragen und dann die Ergebnisse zusammenführen. Beispielsweise würden Sie zunächst eine `Query`-Anforderung für den Partitionsschlüsselwert `2014-07-09.1` ausgeben. Dann geben Sie eine andere `Query` für `2014-07-09.2`, und so weiter bis `2014-07-09.200`, aus. Schließlich müsste Ihre Anwendung die Ergebnisse von allen diesen `Query`-Anfragen zusammenführen.
## Sharding unter Verwendung berechneter Suffixe
Mit einer Randomisierungsstrategie kann der Schreibdurchsatz erheblich verbessert werden. Allerdings ist es schwierig, ein bestimmtes Element zu lesen, da Sie nicht wissen, welcher Suffixwert beim Schreiben des Elements verwendet wurde. Um einzelne Elemente leichter lesen zu können, können Sie eine andere Strategie verwenden. Anstatt eine zufällige Zahl zu verwenden, um die Elemente auf die Partitionen zu verteilen, verwenden Sie eine Zahl, die Sie auf der Grundlage von etwas, für das Sie eine Abfrage durchführen möchten, berechnen können.
Denken Sie an das vorherige Beispiel, in dem eine Tabelle das Datum des aktuellen Tages im Partitionsschlüssel verwendet. Nehmen Sie nun an, dass jedes Element über ein zugängliches `OrderId`-Attribut verfügt und dass Sie Elemente meistens neben dem Datum anhand der Order-ID suchen müssen. Bevor Ihre Anwendung das Element in die Tabelle schreibt, könnte sie basierend auf der Order-ID ein Hash-Suffix berechnen und dem Partitionsschlüsseldatum anhängen. Die Berechnung könnte eine Zahl zwischen 1 und 200 ergeben, die ähnlich wie bei der Zufallsstrategie relativ gleichmäßig verteilt ist.
Eine einfache Berechnung würde wahrscheinlich genügen, beispielsweise das Produkt der UTF-8-Codepunktwerte für die Zeichen in der Order-ID, Modulo 200, \$11. Der Partitions-Schlüsselwert wäre dann das Datum, verkettet mit dem Berechnungsergebnis.
Mit dieser Strategie werden die Schreibvorgänge gleichmäßig auf die Partitions-Schlüsselwerte und somit auch über die physischen Partitionen verteilt. Sie können problemlos eine `GetItem`-Operation für ein bestimmtes Element und Datum durchführen, da Sie den Partitions-Schlüsselwert für einen bestimmten `OrderId`-Wert berechnen können.
Um alle Elemente für einen bestimmten Tag zu lesen, müssen Sie immer noch alle `Query` von den `2014-07-09.N`-Schlüsseln (wobei `N` 1-200 ist) abfragen und anschließend muss die Anwendung alle Ergebnisse zusammenführen. Der Vorteil dabei ist, dass Sie so vermeiden, dass ein einzelner „Hot Partition”-Schlüsselwert die gesamte Workload übernimmt.
**Anmerkung**
Eine noch effizientere Strategie speziell für die Verarbeitung von großen Zeitreihendatenvolumen finden Sie im Abschnitt [Zeitreihendaten](bp-time-series.md).
# Effiziente Verteilung der Schreibaktivität beim Hochladen von Daten in DynamoDB
Normalerweise partitioniert Amazon DynamoDB Ihre Tabellendaten auf mehreren Servern, wenn Sie Daten aus anderen Datenquellen laden. Sie erhalten eine bessere Leistung, wenn Sie Daten gleichzeitig auf alle zugewiesenen Server hochladen.
Angenommen, Sie möchten Benutzermitteilungen in eine DynamoDB-Tabelle hochladen, die einen zusammengesetzten Primärschlüssel mit `UserID` als Partitionsschlüssel und `MessageID` als Sortierschlüssel verwenden.
Wenn Sie die Daten hochladen, können Sie einen Ansatz verwenden, um alle Nachrichtenelemente für jeden Benutzer, einen Benutzer nach dem anderen, hochzuladen:
****
| BenutzerID | MitteilungsID |
| --- | --- |
| B1 | 1 |
| B1 | 2 |
| B1 | ... |
| B1 | ... bis zu 100 |
| B2 | 1 |
| B2 | 2 |
| B2 | ... |
| B2 | ... bis zu 200 |
Das Problem in diesem Fall besteht darin, dass Sie Ihre Schreibanforderungen nicht mittels Ihrer Partitionsschlüsselwerte in DynamoDB verteilen. Sie nehmen einen Partitionsschlüsselwert nach dem anderen und laden alle seine Elemente hoch, bevor Sie zum nächsten Partitionsschlüsselwert gehen und dasselbe tun.
Im Hintergrund partitioniert DynamoDB die Daten in Ihren Tabellen auf mehreren Servern. Um die gesamte Durchsatzkapazität, die für die Tabelle bereitgestellt wird, vollständig zu nutzen, müssen Sie Ihre Workload auf Ihre Partitionsschlüsselwerte verteilen. Indem Sie eine ungleichmäßige Menge der Upload-Arbeit auf Elemente lenken, die alle denselben Partitionsschlüsselwert haben, nutzen Sie nicht alle Ressourcen, die DynamoDB für Ihre Tabelle bereitgestellt hat.
Sie können Ihre Upload-Arbeit verteilen, indem Sie den Sortierschlüssel verwenden, um ein Element aus jedem Partitionsschlüsselwert und dann ein anderes Element aus jedem Partitionsschlüsselwert usw. zu laden:
****
| BenutzerID | MitteilungsID |
| --- | --- |
| B1 | 1 |
| B2 | 1 |
| B3 | 1 |
| ... | ... |
| B1 | 2 |
| B2 | 2 |
| B3 | 2 |
| ... | ... |
Jeder Upload in dieser Sequenz verwendet einen anderen Partitionsschlüsselwert, was mehrere DynamoDB-Server gleichzeitig beschäftigt und Ihre Durchsatzleistung verbessert.