Verwendung von Schreib-Sharding zur gleichmäßigen Verteilung von Workloads

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, +1. 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.