kvp in attributeList)
{
string attributeName = kvp.Key;
AttributeValue value = kvp.Value;
Console.WriteLine(
attributeName + " " +
(value.S == null ? "" : "S=[" + value.S + "]") +
(value.N == null ? "" : "N=[" + value.N + "]") +
(value.SS == null ? "" : "SS=[" + string.Join(",", value.SS.ToArray()) + "]") +
(value.NS == null ? "" : "NS=[" + string.Join(",", value.NS.ToArray()) + "]") +
(value.B == null ? "" : "B=[" + FromGzipMemoryStream(value.B) + "]")
);
}
Console.WriteLine("************************************************");
}
private static MemoryStream ToGzipMemoryStream(string value)
{
MemoryStream output = new MemoryStream();
using (GZipStream zipStream = new GZipStream(output, CompressionMode.Compress, true))
using (StreamWriter writer = new StreamWriter(zipStream))
{
writer.Write(value);
}
return output;
}
private static string FromGzipMemoryStream(MemoryStream stream)
{
using (GZipStream zipStream = new GZipStream(stream, CompressionMode.Decompress))
using (StreamReader reader = new StreamReader(zipStream))
{
return reader.ReadToEnd();
}
}
}
}
```
# Verbessern des Datenzugriffs mit sekundären Indizes in DynamoDB
Amazon DynamoDB bietet einen schnellen Zugriff auf Elemente in einer Tabelle durch Angeben von Primärschlüsselwerten. Viele Anwendungen können jedoch davon profitieren, wenn ein oder mehrere Sekundärschlüssel (oder alternative Schlüssel) verfügbar sind, um effizienten Zugriff auf Daten mit anderen Attributen als dem Primärschlüssel zu erlauben. Dazu können Sie einen oder mehrere sekundäre Indizes für eine Tabelle erstellen und `Query`- oder `Scan`-Anforderungen für diese Indizes ausgeben.
Ein *sekundärer Index* ist eine Datenstruktur, die eine Teilmenge der Attribute aus einer Tabelle zusammen mit einem alternativen Schlüssel zur Unterstützung von `Query`-Operationen enthält. Sie können Daten aus dem Index mit einer `Query`-Operation ähnlich wie `Query` für eine Tabelle abrufen. Eine Tabelle kann mehrere sekundäre Indizes enthalten, die Ihren Anwendungen Zugriff auf viele verschiedene Abfragemuster bieten.
**Anmerkung**
Sie können außerdem eine `Scan`-Operation für einen Index ähnlich wie `Scan` für eine Tabelle ausführen.
Kontoübergreifender Zugriff für sekundäre Indexscanvorgänge wird derzeit nicht für [ressourcenbasierte Richtlinien](access-control-resource-based.md) unterstützt.
Jeder sekundäre Index ist genau einer Tabelle zugeordnet, von der er seine Daten erhält. Diese Tabelle wird als *Basistabelle* für den Index bezeichnet. Beim Erstellen eines Indexes definieren Sie einen alternativen Schlüssel für den Index (Partitionsschlüssel und Sortierschlüssel). Außerdem definieren Sie die Attribute, die von der Basistabelle in den Index *projiziert* oder kopiert werden sollen. DynamoDB kopiert diese Attribute in den Index zusammen mit den Primärschlüsselattributen für die Basistabelle. Sie können den Index dann genauso abfragen oder scannen wie eine Tabelle.
Jeder sekundäre Index wird von DynamoDB verwaltet. Wenn Sie der Basistabelle Elemente hinzufügen, ändern oder löschen, werden alle Indizes dieser Tabelle ebenfalls aktualisiert, um diese Änderungen zu berücksichtigen.
DynamoDB unterstützt zwei Arten sekundärer Indizes:
+ **[Globaler sekundärer Index](GSI.html) – ** Dieser Index verfügt über einen Partitionsschlüssel und einen Sortierschlüssel, die nicht mit denen der Basistabelle übereinstimmen müssen. Ein globaler sekundärer Index wird als „global“ betrachtet, da Indexabfragen partitionsübergreifend alle Daten in der Basistabelle umfassen können. Ein globaler sekundärer Index wird in einem eigenen Partitionsbereich abseits der Basistabelle gespeichert und von der Basistabelle getrennt skaliert.
+ **[Lokaler sekundärer Index](LSI.html) – **Dieser Index weist denselben Partitionsschlüssel wie die Basistabelle auf, hat aber einen anderen Sortierschlüssel. Ein lokaler sekundärer Index wird als „lokal“ betrachtet, da jede Partition eines lokalen sekundären Index auf die Basistabellenpartition bezogen ist, die denselben Partitionsschlüsselwert besitzt.
Einen Vergleich der globalen Sekundärindizes und der lokalen Sekundärindizes finden Sie in diesem Video.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/BkEu7zBWge8)
**Topics**
+ [Verwenden globaler sekundärer Indizes in DynamoDB](GSI.md)
+ [Lokale sekundäre Indizes](LSI.md)
Berücksichtigen Sie die Anforderungen Ihrer Anwendung, wenn Sie sich für einen Indextyp entscheiden. In der folgenden Tabelle werden die Hauptunterschiede zwischen einem globalen sekundären Index und einem lokalen sekundären Index dargelegt.
****
| Merkmal | Globaler sekundärer Index | Lokaler sekundärer Index |
| --- | --- | --- |
| Schlüsselschema | Der Primärschlüssel eines globalen sekundärer Indizes kann entweder einfach (Partitionsschlüssel) oder zusammengesetzt sein (Partitions- und Sortierschlüssel). | Der Primärschlüssel eines lokalen sekundären Indizes muss zusammengesetzt sein (Partitions- und Sortierschlüssel). |
| Schlüsselattribute | Der Indexpartitions- und Sortierschlüssel (sofern vorhanden) kann ein beliebiges Basistabellenattribut vom Typ Zeichenfolge, Zahl oder Binärwert sein. | Der Partitionsschlüssel des Indexes ist dasselbe Attribut wie der Partitionsschlüssel der Basistabelle. Der Sortierschlüssel kann ein beliebiges Basistabellenattribut vom Typ Zeichenfolge, Zahl oder Binärwert sein. |
| Größenbeschränkungen pro Partitionsschlüsselwert | Für globale sekundäre Indizes gibt es keine Größenbeschränkungen. | Für jeden Partitionsschlüsselwert darf die Gesamtgröße aller indizierten Elemente höchstens 10 GB betragen. |
| Online-Indizierungsoperationen | Globale sekundäre Indizes können gleichzeitig mit der Tabelle erstellt werden. Sie können einer vorhandenen Tabelle auch einen neuen globalen sekundären Index hinzufügen oder einen vorhandenen globalen sekundären Index löschen. Weitere Informationen finden Sie unter [Verwalten globaler sekundärer Indizes in DynamoDB](GSI.OnlineOps.md). | Globale sekundäre Indizes werden zur selben Zeit wie die Tabelle erstellt. Sie können einer vorhandenen Tabelle keinen lokalen sekundären Index hinzufügen oder vorhandene lokale sekundäre Indizes löschen. |
| Abfragen und Partitionen | Mit einem globalen sekundären Index können Sie die gesamte Tabelle partitionsübergreifend abfragen. | Ein lokaler sekundärer Index ermöglicht das Abfragen über eine einzelne Partition, wie vom Partitionsschlüsselwert in der Abfrage angegeben. |
| Lesekonsistenz | Abfragen zu globalen sekundären Indizes unterstützen nur Eventual Consistency. | Wenn Sie einen lokalen sekundären Index abfragen, können Sie entweder Eventually Consistent oder Strongly Consistent auswählen. |
| Verbrauch der bereitgestellten Durchsatzkapazität | Jeder globaler sekundärer Index verfügt über eigene Einstellungen für den bereitgestellten Durchsatz für Lese- und Schreibaktivitäten. Abfragen oder Scans für einen globalen sekundären Index verbrauchen Kapazitätseinheiten des Indexes und nicht der Basistabelle. Dasselbe gilt für globale sekundäre Index-Aktualisierungen aufgrund von Tabellenschreibvorgängen. Ein globaler sekundärer Index, der globalen Tabellen zugeordnet ist, verbraucht Schreibkapazitätseinheiten. | Abfragen oder Scans für einen lokalen sekundären Index verbrauchen Lesekapazitätseinheiten der Basistabelle. Wenn Sie Daten in eine Tabelle schreiben, werden die zugehörigen lokalen sekundären Indizes ebenfalls aktualisiert. Diese Aktualisierungen verbrauchen Schreibkapazitätseinheiten aus der Basistabelle. Ein lokaler sekundärer Index, der globalen Tabellen zugeordnet ist, verbraucht replizierte Schreibkapazitätseinheiten. |
| Projizierte Attribute | Mit globalen sekundären Index-Abfragen oder -Scans können Sie nur die Attribute anfordern, die in den Index projiziert sind. DynamoDB ruft keine Attribute aus der Tabelle ab. | Wenn Sie einen lokalen sekundären Index abfragen oder scannen können Sie Attribute anfordern, die nicht in den Index projiziert sind. DynamoDB ruft diese Attribute automatisch aus der Tabelle ab. |
Wenn Sie mehr als eine Tabelle mit sekundären Indizes erstellen möchten, müssen Sie diesen Vorgang sequenziell ausführen. Beispielsweise erstellen Sie die erste Tabelle und warten, bis sie `ACTIVE` wird. Dann erstellen Sie die nächste Tabelle und warten bis sie `ACTIVE` wird und so weiter. Wenn Sie versuchen, gleichzeitig mehr als eine Tabelle mit einem sekundären Index zu erstellen, gibt DynamoDB eine `LimitExceededException` zurück.
Jeder sekundäre Index verwendet dieselbe [Tabellenklasse](HowItWorks.TableClasses.html) und denselben [Kapazitätsmodus](capacity-mode.md) wie die Basistabelle, der er zugeordnet ist. Geben Sie für jeden sekundären Index Folgendes an:
+ Der Typ des zu erstellenden Indexes – entweder ein globaler sekundärer Index oder ein lokaler sekundärer Index.
+ Einen Namen für den Index. Die Namenskonventionen für Indizes sind mit den Konventionen für Tabellen identisch, wie in [Kontingente in Amazon DynamoDB](ServiceQuotas.md) aufgelistet. Der Name muss für die Basistabelle, der er zugeordnet ist, eindeutig sein. Sie können allerdings denselben Namen für Indizes verwenden, die verschiedenen Basistabellen zugeordnet sind.
+ Das Schlüsselschema für den Index. Jedes Attribut im Indexschlüsselschema muss ein Attribut auf oberster Ebene vom Typ `String`, `Number` oder `Binary` sein. Andere Datentypen, einschließlich Dokumenten und Sätzen, sind nicht zulässig. Andere Anforderungen für das Schlüsselschema hängen vom Indextyp ab:
+ Für einen globalen sekundären Index kann der Partitionsschlüssel ein beliebiges skalares Attribut der Basistabelle sein. Ein Sortierschlüssel ist optional und kann ebenfalls ein beliebiges skalares Attribut der Basistabelle sein.
+ Für einen lokalen sekundären Index muss der Partitionsschlüssel mit dem Partitionsschlüssel der Basistabelle übereinstimmen und der Sortierschlüssel muss ein Nicht-Schlüssel-Basistabellenattribut sein.
+ Zusätzliche Attribute, sofern vorhanden, werden von der Basistabelle in den Index projiziert. Diese Attribute ergänzen die Schlüsselattribute der Tabelle, die automatisch in jeden Index projiziert werden. Sie können Attribute jedes Datentyps, einschließlich Skalaren, Dokumenten und Sätzen, projizieren.
+ Die Einstellungen des für den Index bereitgestellten Durchsatzes, falls erforderlich:
+ Für einen globalen sekundären Index müssen Sie Einstellungen für Lese- und Schreibkapazitätseinheiten angeben. Diese Einstellungen für den bereitgestellten Durchsatz sind von den Einstellungen der Basistabelle unabhängig.
+ Für einen lokalen sekundären Index müssen Sie keine Einstellungen für Lese- und Schreibkapazitätseinheiten angeben. Alle Lese- und Schreibvorgänge für einen lokalen sekundären Index nutzen die Einstellungen des bereitgestellten Durchsatzes der entsprechenden Basistabelle.
Für maximale Abfrageflexibilität können Sie bis zu 20 globale sekundäre Indizes (Standardkontingent) und bis zu 5 lokale sekundäre Indizes pro Tabelle erstellen.
Um eine detaillierte Liste der sekundären Indizes in einer Tabelle abzurufen, verwenden Sie die `DescribeTable`-Operation. `DescribeTable` gibt den Namen, die Speichergröße und die Elementanzahl für jeden sekundären Index in der Tabelle zurück. Diese Werte werden nicht in Echtzeit, sondern etwa alle sechs Stunden aktualisiert.
Sie können auf die Daten in einem sekundären Index entweder mit der `Query`- oder der `Scan`-Operation zugreifen. Sie müssen den Namen der Basistabelle und den Namen des Indexes, den Sie verwenden möchten, die Attribute, die in den Abfrageergebnissen zurückgegeben werden sollen, und etwaige Bedingungsausdrücke oder Filter, die Sie anwenden möchten, angeben. DynamoDB kann Ergebnisse in auf- oder absteigender Reihenfolge liefern.
Beim Löschen einer Tabelle werden alle dieser Tabelle zugeordneten Indizes ebenfalls gelöscht.
Bewährte Methoden finden Sie unter [Bewährte Methoden für die Verwendung sekundärer Indexe in DynamoDB](bp-indexes.md).
# Verwenden globaler sekundärer Indizes in DynamoDB
Einige Anwendungen müssen u. U. viele Arten von Abfragen ausführen und verwenden dabei eine Vielzahl von verschiedenen Attributen als Abfragekriterien. Um diese Anforderungen zu unterstützen, können Sie eine oder mehrere *globale sekundäre Indizes* erstellen und `Query`-Anforderungen für diese Indizes in Amazon DynamoDB generieren.
**Topics**
+ [Schritt 6: Verwenden eines globalen sekundären Indexes](#GSI.scenario)
+ [Attributprojektionen](#GSI.Projections)
+ [Schlüsselschema mit mehreren Attributen](#GSI.MultiAttributeKeys)
+ [Lesen von Daten aus einem globalen sekundären Index](#GSI.Reading)
+ [Datensynchronisierung zwischen Tabellen und globalen sekundären Indizes](#GSI.Writes)
+ [Tabellenklassen mit globalen sekundären Indizes](#GSI.tableclasses)
+ [Überlegungen im Hinblick auf die bereitgestellte Durchsatzkapazität für globale sekundäre Indizes](#GSI.ThroughputConsiderations)
+ [Speicherüberlegungen für globale sekundäre Indizes](#GSI.StorageConsiderations)
+ [Muster entwerfen](GSI.DesignPatterns.md)
+ [Verwalten globaler sekundärer Indizes in DynamoDB](GSI.OnlineOps.md)
+ [Erkennen und Korrigieren von Indexschlüsselverstößen in DynamoDB](GSI.OnlineOps.ViolationDetection.md)
+ [Arbeiten mit globalen sekundären Indizes: Java](GSIJavaDocumentAPI.md)
+ [Arbeiten mit globalen sekundären Indizes: .NET](GSILowLevelDotNet.md)
+ [Arbeiten mit globalen sekundären Indizes in DynamoDB mithilfe der AWS CLI](GCICli.md)
## Schritt 6: Verwenden eines globalen sekundären Indexes
Betrachten wir ein Beispiel zur Veranschaulichung. Eine Tabelle mit dem Namen `GameScores` erfasst die Benutzer und Punktzahlen für eine mobile Gaming-Anwendung. Jedes Element in `GameScores` wird anhand eines Partitionsschlüssels (`UserId`) und eines Sortierschlüssels (`GameTitle`) identifiziert. Das folgende Diagramm zeigt, wie die Elemente in der Tabelle organisiert wären. (Es werden nicht alle Attribute angezeigt.)
![\[GameScores Tabelle mit einer Liste von Benutzer-ID, Titel, Punktzahl, Datum und Gewinnen/Niederlagen.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/GSI_01.png)
Angenommen, Sie möchten eine Bestenlisten-Anwendung für die Anzeige der höchsten Punktzahlen für jedes Spiel entwickeln. Eine Abfrage, die die Schlüsselattribute (`UserId` und `GameTitle`) angibt, wäre äußerst effizient. Wenn die Anwendung Daten aus `GameScores` nur basierend auf `GameTitle` abrufen muss, muss sie eine `Scan`-Operation verwenden. Wenn immer mehr Elemente der Tabelle hinzugefügt werden, werden die Scans aller Daten langsam und ineffizient. Dadurch wird die Beantwortung von folgenden Fragen erschwert:
+ Was ist die höchste Punktzahl, die für das Spiel Meteor Blaster jemals erfasst wurde?
+ Welche Benutzer hatte die höchste Punktzahl für Galaxy Invaders?
+ Wie war das höchste Verhältnis zwischen gewonnen und verlorenen Spielen?
Zum Beschleunigen von Abfragen auf der Basis von Nicht-Schlüsselattributen können Sie einen globalen sekundären Index erstellen. Ein globaler sekundärer Index enthält eine Auswahl von Attributen aus der Basistabelle. Diese sind jedoch nach einem Primärschlüssel organisiert, der sich von dem Schlüssel der Tabelle unterscheidet. Der Indexschlüssel benötigt keinen der Schlüsselattribute aus der Tabelle. Er muss nicht einmal über dasselbe Schlüsselschema verfügen wie eine Tabelle.
Sie können beispielsweise einen globalen sekundären Index mit dem Namen `GameTitleIndex` mit einem Partitionsschlüssel `GameTitle` und einem Sortierschlüssel `TopScore` erstellen. Da die Primärschlüsselattribute der Basistabelle immer in einen Index projiziert werden, ist das Attribut `UserId` ebenfalls vorhanden. Das folgende Diagramm veranschaulicht, wie der Index `GameTitleIndex` aussehen würde.
![\[GameTitleIndex Tabelle mit einer Liste von Titeln, Ergebnissen und Benutzer-IDs.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/GSI_02.png)
Jetzt können Sie `GameTitleIndex` abfragen und die Punktzahlen für Meteor Blasters einfach erhalten. Die Ergebnisse werden nach den Sortierschlüsselwerten `TopScore` sortiert. Wenn Sie den Parameter `ScanIndexForward` auf False festlegen, werden die Ergebnisse in der absteigender Reihenfolge mit der höchsten Punktzahl zuerst zurückgegeben.
Jeder globale sekundäre Index muss über einen Partitionsschlüssel verfügen und kann einen optionalen Sortierschlüssel besitzen. Das Indexschlüsselschema kann sich vom Basistabellenschema unterscheiden. Sie können eine Tabelle mit einem einfachen Primärschlüssel (Partitionsschlüssel) vorliegen haben und einen globalen sekundären Index mit einem zusammengesetzten Primärschlüssel (Partitions- und Sortierschlüssel) erstellen oder umgekehrt. Die Indexschlüsselattribute können aus beliebigen Top-Level-Attributen vom Typ `String`, `Number` oder `Binary` der Basistabelle bestehen. Andere Skalar-, Dokument- und Satztypen sind nicht zulässig.
Sie können andere Basistabellenattribute in den Index projizieren, wenn Sie möchten. Wenn Sie den Index abfragen, kann DynamoDB diese projizierten Attribute effizient abrufen. Globale sekundäre Index-Abfragen können jedoch keine Attribute aus der Basistabelle abrufen. Wenn Sie beispielsweise `GameTitleIndex` wie im Diagramm oben veranschaulicht abgefragt haben, kann die Abfrage nicht auf Nicht-Schlüsselattribute außer `TopScore` zugreifen (die Schlüsselattribute `GameTitle` und `UserId` werden allerdings automatisch projiziert).
In einer DynamoDB-Tabelle, muss jeder Schlüsselwert eindeutig sein. Die Schlüsselwerte in einem globalen sekundären Index müssen jedoch nicht eindeutig sein. Beispiel: Angenommen, ein Spiel mit dem Namen Comet Quest ist besonders schwierig. Viele neue Benutzer probieren es aus, schaffen es aber nicht, eine Punktzahl über Null zu erreichen. Im Folgenden finden Sie einige der Daten, die dies veranschaulichen.
****
| UserId | GameTitle | TopScore |
| --- | --- | --- |
| 123 | Comet Quest | 0 |
| 201 | Comet Quest | 0 |
| 301 | Comet Quest | 0 |
Wenn diese Daten der Tabelle `GameScores` hinzugefügt werden, verteilt DynamoDB sie auf `GameTitleIndex`. Wenn wir dann den Index mit Comet Quest für `GameTitle` und mit 0 für `TopScore` abfragen, werden die folgenden Daten zurückgegeben.
![\[Tabelle mit einer Liste mit Titeln, Höchstpunktzahlen und Benutzer-IDs.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/GSI_05.png)
Es werden nur die Elemente mit den angegebenen Schlüsselwerten in der Antwort angezeigt. Innerhalb dieser Datengruppe werden die Elemente nicht in einer bestimmten Reihenfolge angezeigt.
Ein globaler sekundärer Index verfolgt nur Datenelemente, bei denen die Schlüsselattribute tatsächlich vorhanden sind. Angenommen, Sie haben der Tabelle `GameScores` ein neues Element hinzugefügt, jedoch nur die erforderlichen Primärschlüsselattribute bereitgestellt.
****
| UserId | GameTitle |
| --- | --- |
| 400 | Comet Quest |
Da Sie das Attribut `TopScore` nicht angegeben haben, verteilt DynamoDB dieses Element nicht über `GameTitleIndex`. Wenn Sie `GameScores` für alle Comet Quest-Elemente abfragen, erhalten Sie die folgenden vier Elemente:
![\[Tabelle mit einer Liste mit vier Titeln, Höchstpunktzahlen und Benutzer-IDs.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/GSI_04.png)
Eine ähnliche Abfrage für `GameTitleIndex` gibt drei Elemente statt vier zurück. Der Grund hierfür ist, dass das Element mit dem nicht vorhandenen `TopScore` nicht an den Index verteilt wird.
![\[Tabelle mit einer Liste mit drei Titeln, Höchstpunktzahlen und Benutzer-IDs.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/GSI_05.png)
## Attributprojektionen
Eine *Projektion* ist der Satz von Attributen, die aus einer Tabelle in einen sekundären Index kopiert werden. Der Partitionsschlüssel und der Sortierschlüssel der Tabelle werden immer in den Index projiziert. Sie können andere Attribute projizieren, um die Abfrageanforderungen Ihrer Anwendung zu unterstützen. Wenn Sie einen Index abfragen, kann Amazon DynamoDB auf jedes Attribut in der Projektion zugreifen, als ob sich diese Attribute in einer eigenen Tabelle befinden.
Wenn Sie einen sekundären Index erstellen, müssen Sie die Attribute angeben, die in den Index projiziert werden. DynamoDB bietet hierfür drei verschiedene Optionen:
+ *KEYS\$1ONLY* – Jeder Eintrag im Index besteht nur aus dem Tabellenpartitionsschlüssel und Sortierschlüsselwerten, sowie den Indexschlüsselwerten. Die Option `KEYS_ONLY` führt zu dem kleinstmöglichen sekundären Index.
+ *INCLUDE* – Zusätzlich zu den in `KEYS_ONLY` beschriebenen Attributen, enthält der sekundäre Index andere Nicht-Schlüsselattribute, die Sie angeben.
+ *ALL* – Der sekundäre Index enthält alle Attribute der Quelltabelle. Da alle Tabellendaten im Index dupliziert werden, wird ein `ALL`-Projektion führt zu dem größtmöglichen sekundären Index.
Im vorherigen Diagramm verfügt `GameTitleIndex` nur über ein projiziertes Attribut: `UserId`. Obwohl eine Anwendung die `UserId` der besten Ergebnisse für jedes Spiel mit `GameTitle` und `TopScore` effizient in Abfragen bestimmen kann, ist es nicht möglich, effizient die höchste Punktzahl für ein bestimmtes Spiel oder das höchste Verhältnis gewonnener und verlorener Spiele bei den besten Ergebnissen zu bestimmen. Dazu müsste die Anwendung eine zusätzliche Abfrage in der Basistabelle durchführen, um die Siege und Niederlagen für jeden der besten Torschützen abzurufen. Abfragen für diese Daten lassen sich effizienter unterstützen, indem diese Attribute aus der Basistabelle in den globalen sekundären Index projiziert werden, wie in folgendem Diagramm dargestellt.
![\[Darstellung der Projektion von Nicht-Schlüsselattributen in einem globalen sekundären Index zur Unterstützung effizienter Abfragen.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/GSI_06.png)
Da die Nicht-Schlüsselattribute `Wins` und `Losses` in den Index projiziert werden, kann eine Anwendung das Verhältnis zwischen Siegen und Niederlagen für jedes Spiel oder für eine beliebige Kombination aus Spiel und Benutzer-ID bestimmen.
Wenn Sie die Attribute zum Projizieren in einen globalen sekundären Index auswählen, müssen Sie die Differenz der Kosten des bereitgestellten Durchsatzes und der Speicherkosten berücksichtigen:
+ Wenn Sie nur auf wenige Attribute mit möglichst niedriger Latenz zugreifen müssen, erwägen Sie, nur diese Attribute in einen globalen sekundären Index zu projizieren. Je kleiner der Index, desto geringer die Speicher- und somit die Schreibkosten.
+ Greift Ihre Anwendung häufig auf einige Nicht-Schlüsselattribute zu, sollten Sie erwägen, diese Attribute in einen globalen sekundären Index zu projizieren. Die zusätzlichen Speicherkosten für den globalen sekundären Index wiegen die Kosten für die Durchführung häufiger Tabellen-Scans auf.
+ Wenn Sie auf die meisten Nicht-Schlüsselattribute in regelmäßigen Abständen zugreifen müssen, können Sie diese Attribute – oder sogar die gesamte Basistabelle – in einen globalen sekundären Index projizieren. Dadurch erhalten Sie maximale Flexibilität. Ihre Speicherkosten würden allerdings steigen oder sich sogar verdoppeln.
+ Wenn Ihre Anwendung eine Tabelle selten abfragen, jedoch viele Schreibvorgänge oder Updates für die Daten in der Tabelle durchführen muss, erwägen Sie das Projizieren von `KEYS_ONLY`. Der globale sekundäre Index wäre nur klein, stünde aber weiterhin bei Bedarf für Abfrageaktivitäten zur Verfügung.
## Schlüsselschema mit mehreren Attributen
Globale Sekundärindizes unterstützen Schlüssel mit mehreren Attributen, sodass Sie Partitionsschlüssel zusammenstellen und Schlüssel aus mehreren Attributen sortieren können. Mit Schlüsseln mit mehreren Attributen können Sie einen Partitionsschlüssel aus bis zu vier Attributen und einen Sortierschlüssel aus bis zu vier Attributen erstellen, sodass insgesamt bis zu acht Attribute pro Schlüsselschema vorhanden sind.
Schlüssel mit mehreren Attributen vereinfachen Ihr Datenmodell, indem sie das manuelle Verketten von Attributen zu synthetischen Schlüsseln überflüssig machen. Anstatt zusammengesetzte Zeichenketten zu erstellen`TOURNAMENT#WINTER2024#REGION#NA-EAST`, können Sie die natürlichen Attribute aus Ihrem Domänenmodell direkt verwenden. DynamoDB verarbeitet die zusammengesetzte Schlüssellogik automatisch, indem es mehrere Partitionsschlüsselattribute für die Datenverteilung zusammenfasst und die hierarchische Sortierreihenfolge für mehrere Sortierschlüsselattribute beibehält.
Stellen Sie sich beispielsweise ein Spieleturniersystem vor, bei dem Sie Spiele nach Turnieren und Regionen organisieren möchten. Bei Schlüsseln mit mehreren Attributen können Sie Ihren Partitionsschlüssel als zwei separate Attribute definieren: `tournamentId` und`region`. In ähnlicher Weise können Sie Ihren Sortierschlüssel mit mehreren Attributen wie`round`, und definieren`bracket`, `matchId` um eine natürliche Hierarchie zu erstellen. Dieser Ansatz sorgt dafür, dass Ihre Daten eingegeben und Ihr Code sauber bleibt, ohne dass Zeichenketten manipuliert oder analysiert werden müssen.
Wenn Sie einen globalen sekundären Index mit Schlüsseln mit mehreren Attributen abfragen, müssen Sie alle Partitionsschlüsselattribute unter Verwendung von Gleichheitsbedingungen angeben. Bei Sortierschlüsselattributen können Sie sie left-to-right in der Reihenfolge abfragen, in der sie im Schlüsselschema definiert sind. Das bedeutet, dass Sie das erste Sortierschlüsselattribut allein, die ersten beiden Attribute zusammen oder alle Attribute zusammen abfragen können, aber Sie können keine Attribute in der Mitte überspringen. Ungleichheitsbedingungen wie`>`, `<``BETWEEN`, oder `begins_with()` müssen die letzte Bedingung in Ihrer Abfrage sein.
Schlüssel mit mehreren Attributen eignen sich besonders gut, wenn globale Sekundärindizes für bestehende Tabellen erstellt werden. Sie können Attribute verwenden, die bereits in Ihrer Tabelle vorhanden sind, ohne synthetische Schlüssel in Ihren Daten aufzufüllen. Auf diese Weise können Sie Ihrer Anwendung ganz einfach neue Abfragemuster hinzufügen, indem Sie Indizes erstellen, die Ihre Daten mithilfe verschiedener Attributkombinationen neu organisieren.
Jedes Attribut in einem Schlüssel mit mehreren Attributen kann seinen eigenen Datentyp haben: `String` (S), `Number` (N) oder `Binary` (B). Beachten Sie bei der Auswahl von Datentypen, dass `Number` Attribute numerisch sortiert werden, ohne dass Nullen aufgefüllt werden müssen, während Attribute lexikografisch sortiert werden. `String` Wenn Sie beispielsweise einen `Number` Typ für ein Bewertungsattribut verwenden, werden die Werte 5, 50, 500 und 1000 in natürlicher numerischer Reihenfolge sortiert. Dieselben Werte wie `String` Typ würden nach „1000", „5", „50", „500" sortiert, sofern Sie sie nicht mit führenden Nullen auffüllen.
Ordnen Sie beim Entwerfen von Schlüsseln mit mehreren Attributen die Attribute von den allgemeinsten bis hin zu den spezifischsten. Kombinieren Sie bei Partitionsschlüsseln Attribute, die immer zusammen abgefragt werden und für eine gute Datenverteilung sorgen. Platzieren Sie bei Sortierschlüsseln häufig abgefragte Attribute an erster Stelle in der Hierarchie, um die Flexibilität bei der Abfrage zu maximieren. Diese Reihenfolge ermöglicht es Ihnen, Abfragen auf jeder Granularitätsebene durchzuführen, die Ihren Zugriffsmustern entspricht.
Implementierungsbeispiele finden Sie unter. [Schlüssel mit mehreren Attributen](GSI.DesignPattern.MultiAttributeKeys.md)
## Lesen von Daten aus einem globalen sekundären Index
Sie können Elemente aus einem globalen sekundären Index mithilfe von `Query` und `Scan` verwenden. Die `GetItem` und `BatchGetItem`-Operationen können für einen globalen sekundären Index nicht verwendet werden.
### Abfragen eines globalen sekundären Index
Sie können die `Query`-Operation für den Zugriff auf ein oder mehrere Elemente in einem globalen sekundären Index verwenden. Die Abfrage muss den Namen der Basistabelle und den Namen des Index, den Sie verwenden möchten, die Attribute, die in den Abfrageergebnissen zurückgegeben werden sollen, und etwaige Abfragebedingungen, die Sie anwenden möchten, angeben. DynamoDB kann Ergebnisse in auf- oder absteigender Reihenfolge liefern.
Sehen Sie sich die folgenden Daten an, die von einer `Query` zurückgegeben wurden, die Spieledaten für eine Bestenlisten-Anwendung abfragt.
```
{
"TableName": "GameScores",
"IndexName": "GameTitleIndex",
"KeyConditionExpression": "GameTitle = :v_title",
"ExpressionAttributeValues": {
":v_title": {"S": "Meteor Blasters"}
},
"ProjectionExpression": "UserId, TopScore",
"ScanIndexForward": false
}
```
Vorgänge in dieser Abfrage:
+ DynamoDB greift zu und verwendet den *GameTitle*Partitionsschlüssel *GameTitleIndex*, um die Indexelemente für Meteor Blasters zu finden. Alle Indexelemente mit diesem Schlüssel werden nebeneinander gespeichert, um ein schnelles Abrufen zu ermöglichen.
+ In diesem Spiel verwendet DynamoDB den Index, um auf alle Benutzer IDs - und Top-Scores für dieses Spiel zuzugreifen.
+ Die Ergebnisse werden in absteigender Reihenfolge sortiert zurückgegeben, da der Parameter `ScanIndexForward` auf False festgelegt ist.
### Scannen eines globalen sekundären Index
Sie können die `Scan`-Operation zum Abrufen aller Daten aus einem globalen sekundären Index verwenden. Geben Sie dazu den Namen der Basistabelle sowie den Indexnamen in der Abfrage an. Mit einer `Scan`-Operation liest DynamoDB alle Daten im Index und gibt sie an die Anwendung zurück. Sie können auch anfordern, dass nur einige der Daten zurückgegeben und die verbleibenden Daten verworfen werden. Verwenden Sie dazu den Parameter `FilterExpression` der `Scan`-Operation. Weitere Informationen finden Sie unter [Filterausdrücke für Scan](Scan.md#Scan.FilterExpression).
## Datensynchronisierung zwischen Tabellen und globalen sekundären Indizes
DynamoDB synchronisiert automatisch jeden globalen sekundären Index mit der Basistabelle. Wenn eine Anwendung Elemente in eine Tabelle schreibt oder daraus löscht, werden globale sekundäre Indizes in dieser Tabelle mit einem Eventually-Consistent-Modell asynchron aktualisiert. Anwendungen schreiben niemals direkt in einen Index. Allerdings ist es wichtig, zu wissen, welche Auswirkungen es hat, wie DynamoDB diese Indizes verwaltet.
Globale sekundäre Indizes erben den read/write Kapazitätsmodus aus der Basistabelle. Weitere Informationen finden Sie unter [Überlegungen beim Umstellen der Kapazitätsmodi in DynamoDB](bp-switching-capacity-modes.md).
Wenn Sie einen globalen sekundären Index erstellen, geben Sie ein oder mehrere Indexschlüsselattribute und deren Datentypen an. Das bedeutet, dass wenn Sie ein Element in die Basistabelle schreiben, die Datentypen für diese Attribute den Datentypen des Indexschlüsselschemas entsprechen müssen. Im Fall von `GameTitleIndex` wird der Partitionsschlüssel `GameTitle` im Index als Datentyp `String` definiert. Der Sortierschlüssel `TopScore` im Index ist vom Typ `Number`. Wenn Sie versuchen, der Tabelle `GameScores` ein Element hinzuzufügen und einen anderen Datentyp entweder für `GameTitle` oder `TopScore` anzugeben, gibt DynamoDB eine `ValidationException` aufgrund der fehlenden Übereinstimmung des Datentyps zurück.
Wenn Sie Elemente in eine Tabelle schreiben oder daraus löschen, werden die globalen sekundären Indizes in dieser Tabelle in Eventually Consistent-Form aktualisiert. Änderungen an den Tabellendaten werden unter normalen Bedingungen im Bruchteil einer Sekunde auf die globalen sekundären Indizes verteilt. In einigen seltenen Fehlerszenarien können längere Verzögerungen bei der Verteilung auftreten. Ihre Anwendungen sollten daher Situationen abhelfen können, in denen eine Abfrage für einen globalen sekundären Index Ergebnisse zurückgibt, die nicht auf dem neuesten Stand sind.
Wenn Sie ein Element in eine Tabelle schreiben, müssen Sie keine Attribute für globale sekundäre Index-Sortierschlüssel angeben. Bei `GameTitleIndex` müssen Sie z. B. keinen Wert für das Attribut `TopScore` angeben, um ein neues Element in die Tabelle `GameScores` zu schreiben. In diesem Fall schreibt DynamoDB keine Daten in den Index für dieses bestimmte Element.
Eine Tabelle mit vielen globalen sekundären Indizes verursacht höhere Kosten für Schreibaktivitäten als Tabellen mit weniger Indizes. Weitere Informationen finden Sie unter [Überlegungen im Hinblick auf die bereitgestellte Durchsatzkapazität für globale sekundäre Indizes](#GSI.ThroughputConsiderations).
## Tabellenklassen mit globalen sekundären Indizes
Ein globaler sekundärer Index verwendet immer dieselbe Tabellenklasse wie seine Basistabelle. Jedes Mal, wenn ein neuer globaler sekundärer Index für eine Tabelle hinzugefügt wird, verwendet der neue Index dieselbe Tabellenklasse wie seine Basistabelle. Wenn die Tabellenklasse einer Tabelle aktualisiert wird, werden auch alle zugehörigen globalen sekundären Indizes aktualisiert.
## Überlegungen im Hinblick auf die bereitgestellte Durchsatzkapazität für globale sekundäre Indizes
Wenn Sie einen globalen sekundären Index für eine Tabelle mit dem Modus bereitgestellter Kapazität erstellen, müssen Sie Lese- und Schreibkapazitätseinheiten für den erwarteten Workload dieses Indexes angeben. Die Einstellungen für den bereitgestellten Durchsatz eines globalen sekundären Indizes sind getrennt von denen der Basistabelle. Eine `Query`-Operation auf einem globalen sekundären Index verbraucht Lesekapazitätseinheiten des Index und nicht der Basistabelle. Wenn Sie Elemente in eine Tabelle schreiben, sie aktualisieren oder aus der Tabelle löschen, werden die globalen sekundären Indizes in dieser Tabelle in Eventually Consistent-Form aktualisiert. Diese Indexaktualisierungen verbrauchen Kapazitätseinheiten des Indexes und nicht der Basistabelle.
Wenn Sie beispielsweise eine `Query`-Operation für einen ausführen und die bereitgestellte Lesekapazität überschreiten, wird die Anforderung gedrosselt. Wenn Sie viele Schreibaktivitäten für die Tabelle ausführen, ein globaler sekundärer Index dieser Tabelle jedoch über nicht genügend Schreibkapazität verfügt, dann wird die Schreibaktivität der Tabelle gedrosselt.
**Wichtig**
Damit es zu keiner Ablehnung kommt, sollte die bereitgestellte Kapazität für Schreibvorgänge bei einem globalen sekundären Index gleich oder größer als die Kapazität für Schreibvorgänge der Basistabelle sein, da neue Aktualisierungen in die Basistabelle und den globalen sekundären Index geschrieben werden.
Verwenden Sie zum Anzeigen der Einstellungen des bereitgestellten Durchsatzes für einen globalen sekundären Index die `DescribeTable`-Operation. Es werden detaillierte Informationen zu globalen sekundären Indizes für die Tabelle zurückgegeben.
### Lesekapazitätseinheiten
Globale sekundäre Indizes unterstützen Eventually Consistent-Lesevorgänge, die jeweils eine halbe Lesekapazitätseinheit verbrauchen. Das bedeutet, dass eine einzelne globale sekundäre Index-Abfrage bis zu 2 × 4 KB = 8 KB pro Lesekapazitätseinheit abrufen kann.
Für globale sekundäre Index-Abfragen berechnet DynamoDB die bereitgestellten Lesevorgänge auf die gleiche Weise wie für Abfragen der Tabellen. Der einzige Unterschied besteht darin, dass die Berechnung auf der Größe der Indexeinträge und nicht auf der Größe des Elements in der Basistabelle beruht. Die Anzahl der Lesekapazitätseinheiten ist die Summe aller projizierten Attributgrößen sämtlicher zurückgegebener Elemente. Das Ergebnis wird dann auf den nächsten 4 KB-Grenzwert aufgerundet. Weitere Informationen darüber, wie DynamoDB die bereitgestellte Durchsatznutzung berechnet, finden Sie unter [DynamoDB – Modus mit bereitgestellter Kapazität](provisioned-capacity-mode.md).
Die maximale Größe der von einer `Query`-Operation zurückgegebenen Ergebnisse beträgt 1MB. Diese umfasst die Größen aller Attributnamen und Werte sämtlicher zurückgegebenen Elemente.
Nehmen wir als Beispiel einen globalen sekundären Index bei dem jedes Element 2 000 Byte Daten enthält. Angenommen, Sie führen eine `Query`-Operation für diesen Index aus, bei der `KeyConditionExpression` 8 Elemente zurückgegeben werden. Die Gesamtgröße der übereinstimmenden Elemente beträgt: 2 000 Byte x 8 Elemente = 16 000 Byte. Das Ergebnis wird dann auf den nächsten 4-KB-Grenzwert aufgerundet. Da globale sekundäre Index-Abfragen Eventually Consistent ausgeführt werden, belaufen sich die Gesamtkosten auf 0,5 (16 KB/ 4 KB) oder 2 Lesekapazitätseinheiten.
### Schreibkapazitätseinheiten
Wenn ein Element in einer Tabelle hinzugefügt, aktualisiert oder gelöscht wird und ein globaler sekundärer Index davon betroffen ist, dann belegt der globale sekundäre Index bereitgestellte Schreibkapazitätseinheiten für die Operation. Die Gesamtkosten für den bereitgestellten Durchsatz ergeben sich aus der Summe der Schreibkapazitätseinheiten, die durch Schreiben in die Basistabelle verbraucht wurden, und der durch Aktualisieren der globalen sekundären Indizes belegten Einheiten. Hinweis: Wenn ein Schreibvorgang in eine Tabelle keine globale sekundäre Index-Aktualisierung erfordert, wird keine Schreibkapazität vom Index verbraucht.
Damit ein Tabellenschreibvorgang erfolgreich ausgeführt wird, muss der für die Tabelle und alle zugehörigen globalen sekundären Indizes bereitgestellte Durchsatz genügend Kapazität aufweisen. Andernfalls wird der Schreibvorgang in die Tabelle gedrosselt.
**Wichtig**
Bei der Erstellung eines globalen sekundären Index (GSI) können Schreibvorgänge in die Basistabelle gedrosselt werden, wenn die GSI-Aktivität, die sich aus Schreibvorgängen in die Basistabelle ergibt, die bereitgestellte Schreibkapazität der GSI überschreitet. Diese Drosselung wirkt sich auf alle Schreibvorgänge aus, vom Indizierungsprozess bis hin zur möglichen Unterbrechung Ihrer Produktions-Workloads. Weitere Informationen finden Sie unter [Beheben von Drosselungsereignissen in Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TroubleshootingThrottling.html).
Die Kosten für das Schreiben eines Elements in einen globalen sekundären Index hängen von mehreren Faktoren ab:
+ Wenn Sie ein neues Element in die Tabelle schreiben, die ein indiziertes Attribut definiert, oder ein vorhandenes Element zum Definieren eines zuvor nicht definierten indizierten Attributs aktualisieren, ist ein Schreibvorgang erforderlich, um das Element in den Index einzufügen.
+ Wenn eine Aktualisierung der Tabelle den Wert eines indizierten Schlüsselattributs (von A in B) ändert, sind zwei Schreibvorgänge erforderlich, und zwar einer zum Löschen des vorherigen Elements aus dem Index und einer zum Schreiben des neuen Elements in den Index.
+ Wenn ein Element im Index vorhanden war, ein Schreibvorgang in der Tabelle jedoch dazu führte, dass das indizierte Attribut gelöscht wurde, ist ein Schreibvorgang erforderlich, um die alte Elementprojektion im Index zu löschen.
+ Wenn ein Element nicht im Index vorhanden ist, bevor oder nachdem das Element aktualisiert wird, fallen keine zusätzlichen Kosten für das Schreiben in den Index an.
+ Wenn durch eine Aktualisierung der Tabelle nur der Wert von projizierten Attributen im Indexschlüsselschema, nicht aber der Wert von indizierten Schlüsselattributen geändert wird, ist ein Schreibvorgang erforderlich, um die Werte der projizierten Attribute im Index zu aktualisieren.
Alle diese Faktoren setzen voraus, dass die Größe der einzelnen Elemente im Index kleiner oder gleich der 1-KB- Elementgröße für das Berechnen der Schreibkapazitätseinheiten ist. Größere Indexeinträge erfordern zusätzliche Schreibkapazitätseinheiten. Sie können Ihre Kosten für Schreibvorgänge minimieren, indem Sie überlegen, welche Attribute Ihre Abfragen zurückgeben müssen, und nur diese Attribute in den Index projizieren.
## Speicherüberlegungen für globale sekundäre Indizes
Wenn eine Anwendung ein Element in eine Tabelle schreibt, kopiert DynamoDB automatisch die richtige Teilmenge der Attribute in den globalen sekundären Index, in dem diese Attribute angezeigt werden sollen. Ihrem AWS Konto werden sowohl die Speicherung des Elements in der Basistabelle als auch die Speicherung von Attributen in allen globalen Sekundärindizes dieser Tabelle in Rechnung gestellt.
Der Speicherplatz, der von einem Indexelement belegt wird, ergibt sich aus der Summe von folgenden Werten:
+ Die Größe in Byte des Primärschlüssels der Basistabelle (Partitionsschlüssel und Sortierschlüssel)
+ Die Größe in Byte des Indexschlüsselattributs
+ Die Größe in Byte der projizierten Attribute (sofern vorhanden)
+ 100 Bytes des Overheads pro Indexelement
Zur Schätzung der Speicheranforderungen für einen globalen sekundären Index können Sie die durchschnittliche Größe eines Elements im Index schätzen und diesen Wert mit der Anzahl der Elemente in der Basistabelle multiplizieren, die die globalen sekundären Index-Schlüsselattribute besitzen.
Wenn eine Tabelle ein Element enthält, für das ein oder mehrere bestimmte Attribute nicht definiert sind, dieses Attribut jedoch als Indexpartitionsschlüssel oder Sortierschlüssel definiert ist, schreibt DynamoDB keine Daten für dieses Element in den Index.
# Muster entwerfen
Entwurfsmuster bieten bewährte Lösungen für häufig auftretende Herausforderungen bei der Arbeit mit globalen Sekundärindizes. Diese Muster helfen Ihnen bei der Entwicklung effizienter, skalierbarer Anwendungen, indem sie Ihnen zeigen, wie Sie Ihre Indizes für bestimmte Anwendungsfälle strukturieren.
Jedes Muster enthält einen vollständigen Implementierungsleitfaden mit Codebeispielen, bewährten Methoden und realen Anwendungsfällen, die Ihnen helfen, das Muster auf Ihre eigenen Anwendungen anzuwenden.
**Topics**
+ [Schlüssel mit mehreren Attributen](GSI.DesignPattern.MultiAttributeKeys.md)
# Schlüsselmuster mit mehreren Attributen
## Übersicht
Mit Schlüsseln mit mehreren Attributen können Sie eine GSI-Partition (Global Secondary Index) erstellen und Schlüssel sortieren, die jeweils aus bis zu vier Attributen bestehen. Dadurch wird der clientseitige Code reduziert und es ist einfacher, Daten zunächst zu modellieren und später neue Zugriffsmuster hinzuzufügen.
Stellen Sie sich ein gängiges Szenario vor: Um einen globalen Index zu erstellen, der Elemente anhand mehrerer hierarchischer Attribute abfragt, müssten Sie üblicherweise synthetische Schlüssel erstellen, indem Sie Werte verketten. Um beispielsweise in einer Gaming-App Turnierspiele nach Turnier, Region und Runde abzufragen, könnten Sie einen synthetischen GSI-Partitionsschlüssel wie TOURNAMENT\$1 WINTER2 024 \$1REGION \$1NA -EAST und einen synthetischen Sortierschlüssel wie ROUND \$1SEMIFINALS \$1BRACKET \$1UPPER erstellen. Dieser Ansatz funktioniert, erfordert jedoch die Verkettung von Zeichenketten beim Schreiben von Daten, das Parsen beim Lesen und das Auffüllen synthetischer Schlüssel für alle vorhandenen Elemente, wenn Sie den GSI zu einer vorhandenen Tabelle hinzufügen. Dadurch wird der Code unübersichtlicher und es ist schwierig, die Typsicherheit einzelner Schlüsselkomponenten aufrechtzuerhalten.
Schlüssel mit mehreren Attributen lösen dieses Problem für. GSIs Sie definieren Ihren GSI-Partitionsschlüssel mithilfe mehrerer vorhandener Attribute wie TournamentID und Region. DynamoDB verarbeitet die Logik der zusammengesetzten Schlüssel automatisch und hasht sie für die Datenverteilung zusammen. Sie schreiben Elemente mit natürlichen Attributen aus Ihrem Domänenmodell, und die GSI indexiert sie automatisch. Keine Verkettung, kein Parsen, kein Hinterfüllen. Ihr Code bleibt sauber, Ihre Daten bleiben eingegeben und Ihre Abfragen bleiben einfach. Dieser Ansatz ist besonders nützlich, wenn Sie über hierarchische Daten mit natürlichen Attributgruppierungen verfügen (wie Turnier → Region → Runde oder Organisation → Abteilung → Team).
## Beispiel für eine Anwendung
In diesem Leitfaden wird der Aufbau eines Systems zur Nachverfolgung von Turnierspielen für eine Esports-Plattform beschrieben. Die Plattform muss Spiele effizient über mehrere Dimensionen hinweg abfragen können: nach Turnier und Region für die Gruppenverwaltung, nach Spielern für den Spielverlauf und nach Datum für die Planung.
## Datenmodell
In dieser exemplarischen Vorgehensweise unterstützt das System zur Nachverfolgung von Turnierspielen drei primäre Zugriffsmuster, für die jeweils eine andere Schlüsselstruktur erforderlich ist:
**Zugriffsmuster 1:** Suchen Sie ein bestimmtes Spiel anhand seiner eindeutigen ID
+ **Lösung:** Basistabelle mit einem `matchId` Partitionsschlüssel
**Zugriffsmuster 2:** Alle Spiele für ein bestimmtes Turnier und eine bestimmte Region abfragen und optional nach Runde, Bracket oder Spiel filtern
+ **Lösung:** Globaler sekundärer Index mit Partitionsschlüssel (`tournamentId`\$1`region`) mit mehreren Attributen und Sortierschlüssel mit mehreren Attributen (`round`\$1 \$1`bracket`) `matchId`
+ **Beispielabfragen:** „Alle WINTER2 024 Spiele in der Region NA-OST“ oder „Alle HALBFINALSPIELE in OBERER Klammer für 024/NA-EAST“ WINTER2
**Zugriffsmuster 3:** Fragen Sie den Spielverlauf eines Spielers ab und filtern Sie optional nach Zeitraum oder Turnierrunde
+ **Lösung:** Globaler sekundärer Index mit einem einzigen Partitionsschlüssel (`player1Id`) und einem Sortierschlüssel mit mehreren Attributen (`matchDate`\$1`round`)
+ **Beispielabfragen:** „Alle Spiele für Spieler 101“ oder „Spiele von Spieler 101 im Januar 2024“
Der entscheidende Unterschied zwischen traditionellen Ansätzen und Methoden mit mehreren Attributen wird deutlich, wenn man sich die Artikelstruktur ansieht:
**Traditioneller Ansatz für globale Sekundärindizes (verkettete Schlüssel):**
```
// Manual concatenation required for GSI keys
const item = {
matchId: 'match-001', // Base table PK
tournamentId: 'WINTER2024',
region: 'NA-EAST',
round: 'SEMIFINALS',
bracket: 'UPPER',
player1Id: '101',
// Synthetic keys needed for GSI
GSI_PK: `TOURNAMENT#${tournamentId}#REGION#${region}`, // Must concatenate
GSI_SK: `${round}#${bracket}#${matchId}`, // Must concatenate
// ... other attributes
};
```
**Globaler Sekundärindex-Ansatz mit mehreren Attributen (systemeigene Schlüssel):**
```
// Use existing attributes directly - no concatenation needed
const item = {
matchId: 'match-001', // Base table PK
tournamentId: 'WINTER2024',
region: 'NA-EAST',
round: 'SEMIFINALS',
bracket: 'UPPER',
player1Id: '101',
matchDate: '2024-01-18',
// No synthetic keys needed - GSI uses existing attributes directly
// ... other attributes
};
```
Bei Schlüsseln mit mehreren Attributen schreiben Sie Elemente einmal mit natürlichen Domänenattributen. DynamoDB indexiert sie automatisch über mehrere, GSIs ohne dass synthetische verkettete Schlüssel erforderlich sind.
**Schema der Basistabelle:**
+ Partitionsschlüssel: `matchId` (1 Attribut)
**Globales sekundäres Indexschema (TournamentRegionIndex mit Schlüsseln mit mehreren Attributen):**
+ Partitionsschlüssel:`tournamentId`, `region` (2 Attribute)
+ Sortierschlüssel:`round`,`bracket`, `matchId` (3 Attribute)
**Globales sekundäres Indexschema (PlayerMatchHistoryIndex mit Schlüsseln mit mehreren Attributen):**
+ Partitionsschlüssel: `player1Id` (1 Attribut)
+ Sortierschlüssel:`matchDate`, `round` (2 Attribute)
### Basistabelle: TournamentMatches
| MatchID (PK) | Turnier-ID | Region | round | Halterung | Spieler1-ID | Spieler2-ID | Datum des Spiels | Gewinner | Bewertung |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Match-001 | WINTER2024 | IM OSTEN | ENDSPIELE | MEISTERSCHAFT | 101 | 103 | 20.01.2024-01 | 101 | 3-1 |
| Spiel-002 | WINTER2024 | IM OSTEN | HALBFINALE | UPPER | 101 | 105 | 2024-01-18 | 101 | 3-2 |
| Spiel-003 | WINTER2024 | IM OSTEN | HALBFINALE | UPPER | 103 | 107 | 2024-01-18 | 103 | 3-0 |
| Spiel-004 | WINTER2024 | IM OSTEN | VIERTELFINALE | UPPER | 101 | 109 | 2024-01-15 | 101 | 3-1 |
| Spiel-005 | WINTER2024 | IM WESTEN | ENDSPIELE | MEISTERSCHAFT | 102 | 104 | 20.01.2024-01 | 102 | 3-2 |
| Spiel-006 | WINTER2024 | IM WESTEN | HALBFINALE | UPPER | 102 | 106 | 2024-01-18 | 102 | 3-1 |
| Spiel 007 | SPRING2024 | IM OSTEN | VIERTELFINALE | UPPER | 101 | 108 | 2024-03-15 | 101 | 3-0 |
| Spiel-008 | SPRING2024 | IM OSTEN | VIERTELFINALE | LOWER | 103 | 110 | 2024-03-15 | 103 | 3-2 |
### GSI: TournamentRegionIndex (Schlüssel mit mehreren Attributen)
| Turnier-ID (PK) | Region (PK) | rund (SK) | Klammer (SK) | Spiel-ID (SK) | Spieler1-ID | Spieler2-ID | Datum des Spiels | Gewinner | Bewertung |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| WINTER2024 | IM OSTEN | ENDSPIELE | MEISTERSCHAFT | Spiel-001 | 101 | 103 | 20.01.2024 | 101 | 3-1 |
| WINTER2024 | IM OSTEN | VIERTELFINALE | UPPER | Spiel-004 | 101 | 109 | 15.01.2024 | 101 | 3-1 |
| WINTER2024 | IM OSTEN | HALBFINALE | UPPER | Spiel-002 | 101 | 105 | 18.01.2024 | 101 | 3-2 |
| WINTER2024 | IM OSTEN | HALBFINALE | UPPER | Spiel-003 | 103 | 107 | 18.01.2024 | 103 | 3-0 |
| WINTER2024 | IM WESTEN | ENDSPIELE | MEISTERSCHAFT | Spiel-005 | 102 | 104 | 20.01.2024 | 102 | 3-2 |
| WINTER2024 | IM WESTEN | HALBFINALE | UPPER | Spiel-006 | 102 | 106 | 18.01.2024 | 102 | 3-1 |
| SPRING2024 | IM OSTEN | VIERTELFINALE | LOWER | Spiel-008 | 103 | 110 | 15.03.2024 | 103 | 3-2 |
| SPRING2024 | IM OSTEN | VIERTELFINALE | UPPER | Spiel-007 | 101 | 108 | 15.03.2024 | 101 | 3-0 |
### GSI: PlayerMatchHistoryIndex (Schlüssel mit mehreren Attributen)
| Spieler1-ID (PK) | Spieldatum (SK) | Runde (SK) | ID des Turniers | Region | Halterung | ID abgleichen | Spieler2-ID | Gewinner | Bewertung |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 101 | 2024-01-15 | VIERTELFINALE | WINTER2024 | IM OSTEN | UPPER | Spiel-004 | 109 | 101 | 3-1 |
| 101 | 18.01.2024 | HALBFINALE | WINTER2024 | IM OSTEN | UPPER | Spiel-002 | 105 | 101 | 3-2 |
| 101 | 20.01.2024 | ENDSPIELE | WINTER2024 | IM OSTEN | MEISTERSCHAFT | Spiel-001 | 103 | 101 | 3-1 |
| 101 | 15.03.2024 | VIERTELFINALE | SPRING2024 | IM OSTEN | UPPER | Spiel 007 | 108 | 101 | 3-0 |
| 102 | 18.01.2024 | HALBFINALE | WINTER2024 | IM WESTEN | UPPER | Spiel-006 | 106 | 102 | 3-1 |
| 102 | 20.01.2024 | ENDSPIELE | WINTER2024 | IM WESTEN | MEISTERSCHAFT | Spiel-005 | 104 | 102 | 3-2 |
| 103 | 18.01.2024 | HALBFINALE | WINTER2024 | IM OSTEN | UPPER | Spiel-003 | 107 | 103 | 3-0 |
| 103 | 2024-03-15 | VIERTELFINALE | SPRING2024 | IM OSTEN | LOWER | Spiel-008 | 110 | 103 | 3-2 |
## Voraussetzungen
Stellen Sie vor Beginn sicher, dass Sie über Folgendes verfügen:
### Konto und Berechtigungen
+ Ein aktives AWS Konto ([erstellen Sie hier bei Bedarf eines](https://aws.amazon.com/free/))
+ IAM-Berechtigungen für DynamoDB-Operationen:
+ `dynamodb:CreateTable`
+ `dynamodb:DeleteTable`
+ `dynamodb:DescribeTable`
+ `dynamodb:PutItem`
+ `dynamodb:Query`
+ `dynamodb:BatchWriteItem`
**Anmerkung**
**Sicherheitshinweis:** Erstellen Sie für Produktionszwecke eine benutzerdefinierte IAM-Richtlinie mit nur den Berechtigungen, die Sie benötigen. Für dieses Tutorial können Sie die AWS verwaltete Richtlinie `AmazonDynamoDBFullAccessV2` verwenden.
### Entwicklungsumgebung
+ Node.js ist auf Ihrem Computer installiert
+ AWS Anmeldeinformationen, die mit einer der folgenden Methoden konfiguriert wurden:
**Option 1: AWS CLI**
```
aws configure
```
**Option 2: Umgebungsvariablen**
```
export AWS_ACCESS_KEY_ID=your_access_key_here
export AWS_SECRET_ACCESS_KEY=your_secret_key_here
export AWS_DEFAULT_REGION=us-east-1
```
### Installieren erforderlicher Pakete
```
npm install @aws-sdk/client-dynamodb @aws-sdk/lib-dynamodb
```
## Implementierung
### Schritt 1: Erstellen Sie eine Tabelle mit Schlüsseln GSIs mit mehreren Attributen
Erstellen Sie eine Tabelle mit einer einfachen Basisschlüsselstruktur GSIs , die Schlüssel mit mehreren Attributen verwendet.
#### Codebeispiel
```
import { DynamoDBClient, CreateTableCommand } from "@aws-sdk/client-dynamodb";
const client = new DynamoDBClient({ region: 'us-west-2' });
const response = await client.send(new CreateTableCommand({
TableName: 'TournamentMatches',
// Base table: Simple partition key
KeySchema: [
{ AttributeName: 'matchId', KeyType: 'HASH' } // Simple PK
],
AttributeDefinitions: [
{ AttributeName: 'matchId', AttributeType: 'S' },
{ AttributeName: 'tournamentId', AttributeType: 'S' },
{ AttributeName: 'region', AttributeType: 'S' },
{ AttributeName: 'round', AttributeType: 'S' },
{ AttributeName: 'bracket', AttributeType: 'S' },
{ AttributeName: 'player1Id', AttributeType: 'S' },
{ AttributeName: 'matchDate', AttributeType: 'S' }
],
// GSIs with multi-attribute keys
GlobalSecondaryIndexes: [
{
IndexName: 'TournamentRegionIndex',
KeySchema: [
{ AttributeName: 'tournamentId', KeyType: 'HASH' }, // GSI PK attribute 1
{ AttributeName: 'region', KeyType: 'HASH' }, // GSI PK attribute 2
{ AttributeName: 'round', KeyType: 'RANGE' }, // GSI SK attribute 1
{ AttributeName: 'bracket', KeyType: 'RANGE' }, // GSI SK attribute 2
{ AttributeName: 'matchId', KeyType: 'RANGE' } // GSI SK attribute 3
],
Projection: { ProjectionType: 'ALL' }
},
{
IndexName: 'PlayerMatchHistoryIndex',
KeySchema: [
{ AttributeName: 'player1Id', KeyType: 'HASH' }, // GSI PK
{ AttributeName: 'matchDate', KeyType: 'RANGE' }, // GSI SK attribute 1
{ AttributeName: 'round', KeyType: 'RANGE' } // GSI SK attribute 2
],
Projection: { ProjectionType: 'ALL' }
}
],
BillingMode: 'PAY_PER_REQUEST'
}));
console.log("Table with multi-attribute GSI keys created successfully");
```
**Wichtige Designentscheidungen:**
**Basistabelle:** Die Basistabelle verwendet einen einfachen `matchId` Partitionsschlüssel für direkte Suchabfragen, wodurch die Struktur der Basistabelle übersichtlich bleibt und gleichzeitig die komplexen Abfragemuster GSIs bereitgestellt werden.
**TournamentRegionIndex Globaler Sekundärindex:** Der `TournamentRegionIndex` globale Sekundärindex verwendet `tournamentId` \$1 `region` als Partitionsschlüssel mit mehreren Attributen, wodurch eine Isolierung der Turnierregion erreicht wird, bei der die Daten durch den Hash beider Attribute zusammen verteilt werden, was effiziente Abfragen innerhalb eines bestimmten Turnierregionskontextes ermöglicht. Der Sortierschlüssel mit mehreren Attributen (`round`\$1 `bracket` \$1`matchId`) ermöglicht eine hierarchische Sortierung, die Abfragen auf jeder Hierarchieebene mit natürlicher Reihenfolge von allgemein (rund) bis spezifisch (Match-ID) unterstützt.
**PlayerMatchHistoryIndex Globaler Sekundärindex:** Der `PlayerMatchHistoryIndex` globale sekundäre Index reorganisiert Daten nach Spielern, die `player1Id` als Partitionsschlüssel verwendet werden, und ermöglicht so turnierübergreifende Abfragen für einen bestimmten Spieler. Der Sortierschlüssel mit mehreren Attributen (`matchDate`\$1`round`) bietet eine chronologische Reihenfolge mit der Möglichkeit, nach Datumsbereichen oder bestimmten Turnierrunden zu filtern.
### Schritt 2: Fügen Sie Daten mit systemeigenen Attributen ein
Fügen Sie Turnierspieldaten mit natürlichen Attributen hinzu. Die GSI indexiert diese Attribute automatisch, ohne dass synthetische Schlüssel erforderlich sind.
#### Codebeispiel
```
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, PutCommand } from "@aws-sdk/lib-dynamodb";
const client = new DynamoDBClient({ region: 'us-west-2' });
const docClient = DynamoDBDocumentClient.from(client);
// Tournament match data - no synthetic keys needed for GSIs
const matches = [
// Winter 2024 Tournament, NA-EAST region
{
matchId: 'match-001',
tournamentId: 'WINTER2024',
region: 'NA-EAST',
round: 'FINALS',
bracket: 'CHAMPIONSHIP',
player1Id: '101',
player2Id: '103',
matchDate: '2024-01-20',
winner: '101',
score: '3-1'
},
{
matchId: 'match-002',
tournamentId: 'WINTER2024',
region: 'NA-EAST',
round: 'SEMIFINALS',
bracket: 'UPPER',
player1Id: '101',
player2Id: '105',
matchDate: '2024-01-18',
winner: '101',
score: '3-2'
},
{
matchId: 'match-003',
tournamentId: 'WINTER2024',
region: 'NA-EAST',
round: 'SEMIFINALS',
bracket: 'UPPER',
player1Id: '103',
player2Id: '107',
matchDate: '2024-01-18',
winner: '103',
score: '3-0'
},
{
matchId: 'match-004',
tournamentId: 'WINTER2024',
region: 'NA-EAST',
round: 'QUARTERFINALS',
bracket: 'UPPER',
player1Id: '101',
player2Id: '109',
matchDate: '2024-01-15',
winner: '101',
score: '3-1'
},
// Winter 2024 Tournament, NA-WEST region
{
matchId: 'match-005',
tournamentId: 'WINTER2024',
region: 'NA-WEST',
round: 'FINALS',
bracket: 'CHAMPIONSHIP',
player1Id: '102',
player2Id: '104',
matchDate: '2024-01-20',
winner: '102',
score: '3-2'
},
{
matchId: 'match-006',
tournamentId: 'WINTER2024',
region: 'NA-WEST',
round: 'SEMIFINALS',
bracket: 'UPPER',
player1Id: '102',
player2Id: '106',
matchDate: '2024-01-18',
winner: '102',
score: '3-1'
},
// Spring 2024 Tournament, NA-EAST region
{
matchId: 'match-007',
tournamentId: 'SPRING2024',
region: 'NA-EAST',
round: 'QUARTERFINALS',
bracket: 'UPPER',
player1Id: '101',
player2Id: '108',
matchDate: '2024-03-15',
winner: '101',
score: '3-0'
},
{
matchId: 'match-008',
tournamentId: 'SPRING2024',
region: 'NA-EAST',
round: 'QUARTERFINALS',
bracket: 'LOWER',
player1Id: '103',
player2Id: '110',
matchDate: '2024-03-15',
winner: '103',
score: '3-2'
}
];
// Insert all matches
for (const match of matches) {
await docClient.send(new PutCommand({
TableName: 'TournamentMatches',
Item: match
}));
console.log(`Added: ${match.matchId} - ${match.tournamentId}/${match.region} - ${match.round} ${match.bracket}`);
}
console.log(`\nInserted ${matches.length} tournament matches`);
console.log("No synthetic keys created - GSIs use native attributes automatically");
```
**Datenstruktur erklärt:**
**Natürliche Verwendung von Attributen:** Jedes Attribut steht für ein echtes Turnierkonzept, bei dem keine Verkettung oder Analyse von Zeichenketten erforderlich ist, sodass eine direkte Zuordnung zum Domänenmodell möglich ist.
**Automatische Indizierung des globalen sekundären Indexes:** Die Indexierung von Elementen GSIs erfolgt automatisch unter Verwendung der vorhandenen Attribute (`tournamentId`,,,`region`, `matchId` für TournamentRegionIndex und `round``bracket`, `round` für PlayerMatchHistoryIndex), ohne dass `player1Id` synthetische `matchDate` verkettete Schlüssel erforderlich sind.
**Kein Backfilling erforderlich:** Wenn Sie einer vorhandenen Tabelle einen neuen globalen sekundären Index mit Schlüsseln mit mehreren Attributen hinzufügen, indexiert DynamoDB automatisch alle vorhandenen Elemente anhand ihrer natürlichen Attribute — es ist nicht erforderlich, Elemente mit synthetischen Schlüsseln zu aktualisieren.
### Schritt 3: Fragen Sie den globalen sekundären Index mit allen Partitionsschlüsselattributen ab TournamentRegionIndex
In diesem Beispiel wird der TournamentRegionIndex globale sekundäre Index abgefragt, der über einen Partitionsschlüssel mit mehreren Attributen (`tournamentId`\$1`region`) verfügt. Alle Partitionsschlüsselattribute müssen in Abfragen mit Gleichheitsbedingungen angegeben werden. Es ist nicht möglich, Abfragen nur `tournamentId` allein oder Ungleichheitsoperatoren für Partitionsschlüsselattribute zu verwenden.
#### Codebeispiel
```
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, QueryCommand } from "@aws-sdk/lib-dynamodb";
const client = new DynamoDBClient({ region: 'us-west-2' });
const docClient = DynamoDBDocumentClient.from(client);
// Query GSI: All matches for WINTER2024 tournament in NA-EAST region
const response = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'TournamentRegionIndex',
KeyConditionExpression: 'tournamentId = :tournament AND #region = :region',
ExpressionAttributeNames: {
'#region': 'region', // 'region' is a reserved keyword
'#tournament': 'tournament'
},
ExpressionAttributeValues: {
':tournament': 'WINTER2024',
':region': 'NA-EAST'
}
}));
console.log(`Found ${response.Items.length} matches for WINTER2024/NA-EAST:\n`);
response.Items.forEach(match => {
console.log(` ${match.round} | ${match.bracket} | ${match.matchId}`);
console.log(` Players: ${match.player1Id} vs ${match.player2Id}`);
console.log(` Winner: ${match.winner}, Score: ${match.score}\n`);
});
```
**Erwartete Ausgabe:**
```
Found 4 matches for WINTER2024/NA-EAST:
FINALS | CHAMPIONSHIP | match-001
Players: 101 vs 103
Winner: 101, Score: 3-1
QUARTERFINALS | UPPER | match-004
Players: 101 vs 109
Winner: 101, Score: 3-1
SEMIFINALS | UPPER | match-002
Players: 101 vs 105
Winner: 101, Score: 3-2
SEMIFINALS | UPPER | match-003
Players: 103 vs 107
Winner: 103, Score: 3-0
```
**Ungültige Abfragen:**
```
// Missing region attribute
KeyConditionExpression: 'tournamentId = :tournament'
// Using inequality on partition key attribute
KeyConditionExpression: 'tournamentId = :tournament AND #region > :region'
```
**Leistung:** Partitionsschlüssel mit mehreren Attributen werden zusammen gehasht und bieten so dieselbe O (1) -Suchleistung wie Schlüssel mit einem Attribut.
### Schritt 4: Sortierschlüssel für den globalen sekundären Index abfragen left-to-right
Sortierschlüsselattribute müssen left-to-right in der Reihenfolge abgefragt werden, in der sie im globalen sekundären Index definiert sind. Dieses Beispiel zeigt die Abfrage von TournamentRegionIndex auf verschiedenen Hierarchieebenen: das Filtern nur nach`round`, nach `round` \$1 `bracket` oder nach allen drei Sortierschlüsselattributen. Sie können keine Attribute in der Mitte überspringen. Sie können beispielsweise keine Abfragen nach und nach `round` dem Überspringen durchführen. `matchId` `bracket`
#### Codebeispiel
```
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, QueryCommand } from "@aws-sdk/lib-dynamodb";
const client = new DynamoDBClient({ region: 'us-west-2' });
const docClient = DynamoDBDocumentClient.from(client);
// Query 1: Filter by first sort key attribute (round)
console.log("Query 1: All SEMIFINALS matches");
const query1 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'TournamentRegionIndex',
KeyConditionExpression: 'tournamentId = :tournament AND #region = :region AND round = :round',
ExpressionAttributeNames: {
'#region': 'region' // 'region' is a reserved keyword
},
ExpressionAttributeValues: {
':tournament': 'WINTER2024',
':region': 'NA-EAST',
':round': 'SEMIFINALS'
}
}));
console.log(` Found ${query1.Items.length} matches\n`);
// Query 2: Filter by first two sort key attributes (round + bracket)
console.log("Query 2: SEMIFINALS UPPER bracket matches");
const query2 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'TournamentRegionIndex',
KeyConditionExpression: 'tournamentId = :tournament AND #region = :region AND round = :round AND bracket = :bracket',
ExpressionAttributeNames: {
'#region': 'region' // 'region' is a reserved keyword
},
ExpressionAttributeValues: {
':tournament': 'WINTER2024',
':region': 'NA-EAST',
':round': 'SEMIFINALS',
':bracket': 'UPPER'
}
}));
console.log(` Found ${query2.Items.length} matches\n`);
// Query 3: Filter by all three sort key attributes (round + bracket + matchId)
console.log("Query 3: Specific match in SEMIFINALS UPPER bracket");
const query3 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'TournamentRegionIndex',
KeyConditionExpression: 'tournamentId = :tournament AND #region = :region AND round = :round AND bracket = :bracket AND matchId = :matchId',
ExpressionAttributeNames: {
'#region': 'region' // 'region' is a reserved keyword
},
ExpressionAttributeValues: {
':tournament': 'WINTER2024',
':region': 'NA-EAST',
':round': 'SEMIFINALS',
':bracket': 'UPPER',
':matchId': 'match-002'
}
}));
console.log(` Found ${query3.Items.length} matches\n`);
// Query 4: INVALID - skipping round
console.log("Query 4: Attempting to skip first sort key attribute (WILL FAIL)");
try {
const query4 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'TournamentRegionIndex',
KeyConditionExpression: 'tournamentId = :tournament AND #region = :region AND bracket = :bracket',
ExpressionAttributeNames: {
'#region': 'region' // 'region' is a reserved keyword
},
ExpressionAttributeValues: {
':tournament': 'WINTER2024',
':region': 'NA-EAST',
':bracket': 'UPPER'
}
}));
} catch (error) {
console.log(` Error: ${error.message}`);
console.log(` Cannot skip sort key attributes - must query left-to-right\n`);
}
```
**Erwartete Ausgabe:**
```
Query 1: All SEMIFINALS matches
Found 2 matches
Query 2: SEMIFINALS UPPER bracket matches
Found 2 matches
Query 3: Specific match in SEMIFINALS UPPER bracket
Found 1 matches
Query 4: Attempting to skip first sort key attribute (WILL FAIL)
Error: Query key condition not supported
Cannot skip sort key attributes - must query left-to-right
```
**Left-to-right Abfrageregeln:** Sie müssen Attribute in der Reihenfolge von links nach rechts abfragen, ohne irgendwelche zu überspringen.
**Gültige Muster:**
+ Nur erstes Attribut: `round = 'SEMIFINALS'`
+ Die ersten beiden Attribute: `round = 'SEMIFINALS' AND bracket = 'UPPER'`
+ Alle drei Attribute: `round = 'SEMIFINALS' AND bracket = 'UPPER' AND matchId = 'match-002'`
**Ungültige Muster:**
+ Das erste Attribut wird übersprungen: `bracket = 'UPPER'` (überspringt die Runde)
+ Die Abfrage ist nicht in der richtigen Reihenfolge: `matchId = 'match-002' AND round = 'SEMIFINALS'`
+ Lücken hinterlassen: `round = 'SEMIFINALS' AND matchId = 'match-002'` (überspringt die Klammer)
**Anmerkung**
**Design-Tipp:** Sortieren Sie die Schlüsselattribute von den allgemeinsten bis hin zu den spezifischsten, um die Flexibilität bei der Abfrage zu maximieren.
### Schritt 5: Verwenden Sie Ungleichheitsbedingungen für Sortierschlüssel im globalen sekundären Index
Ungleichheitsbedingungen müssen die letzte Bedingung in Ihrer Abfrage sein. Dieses Beispiel zeigt die Verwendung von Vergleichsoperatoren (`>=`,`BETWEEN`) und Präfixabgleich (`begins_with()`) für Sortierschlüsselattribute. Sobald Sie einen Ungleichheitsoperator verwendet haben, können Sie danach keine weiteren Sortierschlüsselbedingungen hinzufügen — die Ungleichheit muss die letzte Bedingung in Ihrem Schlüsselbedingungsausdruck sein.
#### Codebeispiel
```
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, QueryCommand } from "@aws-sdk/lib-dynamodb";
const client = new DynamoDBClient({ region: 'us-west-2' });
const docClient = DynamoDBDocumentClient.from(client);
// Query 1: Round comparison (inequality on first sort key attribute)
console.log("Query 1: Matches from QUARTERFINALS onwards");
const query1 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'TournamentRegionIndex',
KeyConditionExpression: 'tournamentId = :tournament AND #region = :region AND round >= :round',
ExpressionAttributeNames: {
'#region': 'region' // 'region' is a reserved keyword
},
ExpressionAttributeValues: {
':tournament': 'WINTER2024',
':region': 'NA-EAST',
':round': 'QUARTERFINALS'
}
}));
console.log(` Found ${query1.Items.length} matches\n`);
// Query 2: Round range with BETWEEN
console.log("Query 2: Matches between QUARTERFINALS and SEMIFINALS");
const query2 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'TournamentRegionIndex',
KeyConditionExpression: 'tournamentId = :tournament AND #region = :region AND round BETWEEN :start AND :end',
ExpressionAttributeNames: {
'#region': 'region' // 'region' is a reserved keyword
},
ExpressionAttributeValues: {
':tournament': 'WINTER2024',
':region': 'NA-EAST',
':start': 'QUARTERFINALS',
':end': 'SEMIFINALS'
}
}));
console.log(` Found ${query2.Items.length} matches\n`);
// Query 3: Prefix matching with begins_with (treated as inequality)
console.log("Query 3: Matches in brackets starting with 'U'");
const query3 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'TournamentRegionIndex',
KeyConditionExpression: 'tournamentId = :tournament AND #region = :region AND round = :round AND begins_with(bracket, :prefix)',
ExpressionAttributeNames: {
'#region': 'region' // 'region' is a reserved keyword
},
ExpressionAttributeValues: {
':tournament': 'WINTER2024',
':region': 'NA-EAST',
':round': 'SEMIFINALS',
':prefix': 'U'
}
}));
console.log(` Found ${query3.Items.length} matches\n`);
// Query 4: INVALID - condition after inequality
console.log("Query 4: Attempting condition after inequality (WILL FAIL)");
try {
const query4 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'TournamentRegionIndex',
KeyConditionExpression: 'tournamentId = :tournament AND #region = :region AND round > :round AND bracket = :bracket',
ExpressionAttributeNames: {
'#region': 'region' // 'region' is a reserved keyword
},
ExpressionAttributeValues: {
':tournament': 'WINTER2024',
':region': 'NA-EAST',
':round': 'QUARTERFINALS',
':bracket': 'UPPER'
}
}));
} catch (error) {
console.log(` Error: ${error.message}`);
console.log(` Cannot add conditions after inequality - it must be last\n`);
}
```
**Regeln für Ungleichheitsoperatoren:** Sie können Vergleichsoperatoren (`>`, `>=``<`,`<=`) `BETWEEN` für Bereichsabfragen und `begins_with()` für den Präfixabgleich verwenden. Die Ungleichheit muss die letzte Bedingung in Ihrer Abfrage sein.
**Gültige Muster:**
+ Gleichheitsbedingungen, gefolgt von Ungleichheit: `round = 'SEMIFINALS' AND bracket = 'UPPER' AND matchId > 'match-001'`
+ Ungleichheit beim ersten Merkmal: `round BETWEEN 'QUARTERFINALS' AND 'SEMIFINALS'`
+ Präfixübereinstimmung als letzte Bedingung: `round = 'SEMIFINALS' AND begins_with(bracket, 'U')`
**Ungültige Muster:**
+ Hinzufügen von Bedingungen nach einer Ungleichung: `round > 'QUARTERFINALS' AND bracket = 'UPPER'`
+ Verwendung mehrerer Ungleichungen: `round > 'QUARTERFINALS' AND bracket > 'L'`
**Wichtig**
`begins_with()`wird als Ungleichheitsbedingung behandelt, sodass ihr keine weiteren Sortierschlüsselbedingungen folgen können.
### Schritt 6: Fragen Sie den PlayerMatchHistoryIndex globalen sekundären Index mit einem Sortierschlüssel mit mehreren Attributen ab
In diesem Beispiel wird abgefragt PlayerMatchHistoryIndex , welcher einen einzelnen Partitionsschlüssel (`player1Id`) und einen Sortierschlüssel mit mehreren Attributen (`matchDate`\$1`round`) hat. Dies ermöglicht eine turnierübergreifende Analyse, indem alle Spiele eines bestimmten Spielers abgefragt werden, ohne das Turnier IDs zu kennen. In der Basistabelle wären für jede Kombination aus Turnier und Region separate Abfragen erforderlich.
#### Codebeispiel
```
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, QueryCommand } from "@aws-sdk/lib-dynamodb";
const client = new DynamoDBClient({ region: 'us-west-2' });
const docClient = DynamoDBDocumentClient.from(client);
// Query 1: All matches for Player 101 across all tournaments
console.log("Query 1: All matches for Player 101");
const query1 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'PlayerMatchHistoryIndex',
KeyConditionExpression: 'player1Id = :player',
ExpressionAttributeValues: {
':player': '101'
}
}));
console.log(` Found ${query1.Items.length} matches for Player 101:`);
query1.Items.forEach(match => {
console.log(` ${match.tournamentId}/${match.region} - ${match.matchDate} - ${match.round}`);
});
console.log();
// Query 2: Player 101 matches on specific date
console.log("Query 2: Player 101 matches on 2024-01-18");
const query2 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'PlayerMatchHistoryIndex',
KeyConditionExpression: 'player1Id = :player AND matchDate = :date',
ExpressionAttributeValues: {
':player': '101',
':date': '2024-01-18'
}
}));
console.log(` Found ${query2.Items.length} matches\n`);
// Query 3: Player 101 SEMIFINALS matches on specific date
console.log("Query 3: Player 101 SEMIFINALS matches on 2024-01-18");
const query3 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'PlayerMatchHistoryIndex',
KeyConditionExpression: 'player1Id = :player AND matchDate = :date AND round = :round',
ExpressionAttributeValues: {
':player': '101',
':date': '2024-01-18',
':round': 'SEMIFINALS'
}
}));
console.log(` Found ${query3.Items.length} matches\n`);
// Query 4: Player 101 matches in date range
console.log("Query 4: Player 101 matches in January 2024");
const query4 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'PlayerMatchHistoryIndex',
KeyConditionExpression: 'player1Id = :player AND matchDate BETWEEN :start AND :end',
ExpressionAttributeValues: {
':player': '101',
':start': '2024-01-01',
':end': '2024-01-31'
}
}));
console.log(` Found ${query4.Items.length} matches\n`);
```
## Variationen des Musters
### Zeitreihendaten mit Schlüsseln mit mehreren Attributen
Optimieren Sie für Zeitreihenabfragen mit hierarchischen Zeitattributen
#### Codebeispiel
```
{
TableName: 'IoTReadings',
// Base table: Simple partition key
KeySchema: [
{ AttributeName: 'readingId', KeyType: 'HASH' }
],
AttributeDefinitions: [
{ AttributeName: 'readingId', AttributeType: 'S' },
{ AttributeName: 'deviceId', AttributeType: 'S' },
{ AttributeName: 'locationId', AttributeType: 'S' },
{ AttributeName: 'year', AttributeType: 'S' },
{ AttributeName: 'month', AttributeType: 'S' },
{ AttributeName: 'day', AttributeType: 'S' },
{ AttributeName: 'timestamp', AttributeType: 'S' }
],
// GSI with multi-attribute keys for time-series queries
GlobalSecondaryIndexes: [{
IndexName: 'DeviceLocationTimeIndex',
KeySchema: [
{ AttributeName: 'deviceId', KeyType: 'HASH' },
{ AttributeName: 'locationId', KeyType: 'HASH' },
{ AttributeName: 'year', KeyType: 'RANGE' },
{ AttributeName: 'month', KeyType: 'RANGE' },
{ AttributeName: 'day', KeyType: 'RANGE' },
{ AttributeName: 'timestamp', KeyType: 'RANGE' }
],
Projection: { ProjectionType: 'ALL' }
}],
BillingMode: 'PAY_PER_REQUEST'
}
// Query patterns enabled via GSI:
// - All readings for device in location
// - Readings for specific year
// - Readings for specific month in year
// - Readings for specific day
// - Readings in time range
```
**Vorteile: Die** natürliche Zeithierarchie (Jahr → Monat → Tag → Zeitstempel) ermöglicht effiziente Abfragen mit beliebiger Granularität, ohne dass das Datum analysiert oder manipuliert werden muss. Der globale Sekundärindex indexiert automatisch alle Messwerte anhand ihrer natürlichen Zeitattribute.
### E-Commerce-Bestellungen mit Schlüsseln mit mehreren Attributen
Verfolgen Sie Bestellungen mit mehreren Dimensionen
#### Codebeispiel
```
{
TableName: 'Orders',
// Base table: Simple partition key
KeySchema: [
{ AttributeName: 'orderId', KeyType: 'HASH' }
],
AttributeDefinitions: [
{ AttributeName: 'orderId', AttributeType: 'S' },
{ AttributeName: 'sellerId', AttributeType: 'S' },
{ AttributeName: 'region', AttributeType: 'S' },
{ AttributeName: 'orderDate', AttributeType: 'S' },
{ AttributeName: 'category', AttributeType: 'S' },
{ AttributeName: 'customerId', AttributeType: 'S' },
{ AttributeName: 'orderStatus', AttributeType: 'S' }
],
GlobalSecondaryIndexes: [
{
IndexName: 'SellerRegionIndex',
KeySchema: [
{ AttributeName: 'sellerId', KeyType: 'HASH' },
{ AttributeName: 'region', KeyType: 'HASH' },
{ AttributeName: 'orderDate', KeyType: 'RANGE' },
{ AttributeName: 'category', KeyType: 'RANGE' },
{ AttributeName: 'orderId', KeyType: 'RANGE' }
],
Projection: { ProjectionType: 'ALL' }
},
{
IndexName: 'CustomerOrdersIndex',
KeySchema: [
{ AttributeName: 'customerId', KeyType: 'HASH' },
{ AttributeName: 'orderDate', KeyType: 'RANGE' },
{ AttributeName: 'orderStatus', KeyType: 'RANGE' }
],
Projection: { ProjectionType: 'ALL' }
}
],
BillingMode: 'PAY_PER_REQUEST'
}
// SellerRegionIndex GSI queries:
// - Orders by seller and region
// - Orders by seller, region, and date
// - Orders by seller, region, date, and category
// CustomerOrdersIndex GSI queries:
// - Customer's orders
// - Customer's orders by date
// - Customer's orders by date and status
```
### Hierarchische Organisationsdaten
Modellieren Sie Organisationshierarchien
#### Codebeispiel
```
{
TableName: 'Employees',
// Base table: Simple partition key
KeySchema: [
{ AttributeName: 'employeeId', KeyType: 'HASH' }
],
AttributeDefinitions: [
{ AttributeName: 'employeeId', AttributeType: 'S' },
{ AttributeName: 'companyId', AttributeType: 'S' },
{ AttributeName: 'divisionId', AttributeType: 'S' },
{ AttributeName: 'departmentId', AttributeType: 'S' },
{ AttributeName: 'teamId', AttributeType: 'S' },
{ AttributeName: 'skillCategory', AttributeType: 'S' },
{ AttributeName: 'skillLevel', AttributeType: 'S' },
{ AttributeName: 'yearsExperience', AttributeType: 'N' }
],
GlobalSecondaryIndexes: [
{
IndexName: 'OrganizationIndex',
KeySchema: [
{ AttributeName: 'companyId', KeyType: 'HASH' },
{ AttributeName: 'divisionId', KeyType: 'HASH' },
{ AttributeName: 'departmentId', KeyType: 'RANGE' },
{ AttributeName: 'teamId', KeyType: 'RANGE' },
{ AttributeName: 'employeeId', KeyType: 'RANGE' }
],
Projection: { ProjectionType: 'ALL' }
},
{
IndexName: 'SkillsIndex',
KeySchema: [
{ AttributeName: 'skillCategory', KeyType: 'HASH' },
{ AttributeName: 'skillLevel', KeyType: 'RANGE' },
{ AttributeName: 'yearsExperience', KeyType: 'RANGE' }
],
Projection: { ProjectionType: 'INCLUDE', NonKeyAttributes: ['employeeId', 'name'] }
}
],
BillingMode: 'PAY_PER_REQUEST'
}
// OrganizationIndex GSI query patterns:
// - All employees in company/division
// - Employees in specific department
// - Employees in specific team
// SkillsIndex GSI query patterns:
// - Employees by skill and experience level
```
### Wenige Schlüssel mit mehreren Attributen
Kombinieren Sie Schlüssel mit mehreren Attributen, um einen globalen Index mit geringer Dichte zu erstellen
#### Codebeispiel
```
{
TableName: 'Products',
// Base table: Simple partition key
KeySchema: [
{ AttributeName: 'productId', KeyType: 'HASH' }
],
AttributeDefinitions: [
{ AttributeName: 'productId', AttributeType: 'S' },
{ AttributeName: 'categoryId', AttributeType: 'S' },
{ AttributeName: 'subcategoryId', AttributeType: 'S' },
{ AttributeName: 'averageRating', AttributeType: 'N' },
{ AttributeName: 'reviewCount', AttributeType: 'N' }
],
GlobalSecondaryIndexes: [
{
IndexName: 'CategoryIndex',
KeySchema: [
{ AttributeName: 'categoryId', KeyType: 'HASH' },
{ AttributeName: 'subcategoryId', KeyType: 'HASH' },
{ AttributeName: 'productId', KeyType: 'RANGE' }
],
Projection: { ProjectionType: 'ALL' }
},
{
IndexName: 'ReviewedProductsIndex',
KeySchema: [
{ AttributeName: 'categoryId', KeyType: 'HASH' },
{ AttributeName: 'averageRating', KeyType: 'RANGE' }, // Optional attribute
{ AttributeName: 'reviewCount', KeyType: 'RANGE' } // Optional attribute
],
Projection: { ProjectionType: 'ALL' }
}
],
BillingMode: 'PAY_PER_REQUEST'
}
// Only products with reviews appear in ReviewedProductsIndex GSI
// Automatic filtering without application logic
// Multi-attribute sort key enables rating and count queries
```
### SaaS für mehrere Mandanten
Mehrinstanzenfähige SaaS-Plattform mit Kundenisolierung
#### Codebeispiel
```
// Table design
{
TableName: 'SaasData',
// Base table: Simple partition key
KeySchema: [
{ AttributeName: 'resourceId', KeyType: 'HASH' }
],
AttributeDefinitions: [
{ AttributeName: 'resourceId', AttributeType: 'S' },
{ AttributeName: 'tenantId', AttributeType: 'S' },
{ AttributeName: 'customerId', AttributeType: 'S' },
{ AttributeName: 'resourceType', AttributeType: 'S' }
],
// GSI with multi-attribute keys for tenant-customer isolation
GlobalSecondaryIndexes: [{
IndexName: 'TenantCustomerIndex',
KeySchema: [
{ AttributeName: 'tenantId', KeyType: 'HASH' },
{ AttributeName: 'customerId', KeyType: 'HASH' },
{ AttributeName: 'resourceType', KeyType: 'RANGE' },
{ AttributeName: 'resourceId', KeyType: 'RANGE' }
],
Projection: { ProjectionType: 'ALL' }
}],
BillingMode: 'PAY_PER_REQUEST'
}
// Query GSI: All resources for tenant T001, customer C001
const resources = await docClient.send(new QueryCommand({
TableName: 'SaasData',
IndexName: 'TenantCustomerIndex',
KeyConditionExpression: 'tenantId = :tenant AND customerId = :customer',
ExpressionAttributeValues: {
':tenant': 'T001',
':customer': 'C001'
}
}));
// Query GSI: Specific resource type for tenant/customer
const documents = await docClient.send(new QueryCommand({
TableName: 'SaasData',
IndexName: 'TenantCustomerIndex',
KeyConditionExpression: 'tenantId = :tenant AND customerId = :customer AND resourceType = :type',
ExpressionAttributeValues: {
':tenant': 'T001',
':customer': 'C001',
':type': 'document'
}
}));
```
**Vorteile:** Effiziente Abfragen im Mandanten-Kunden-Kontext und natürliche Datenorganisation.
### Finanztransaktionen
Banksystem zur Verfolgung von Kontotransaktionen mithilfe von GSIs
#### Codebeispiel
```
// Table design
{
TableName: 'BankTransactions',
// Base table: Simple partition key
KeySchema: [
{ AttributeName: 'transactionId', KeyType: 'HASH' }
],
AttributeDefinitions: [
{ AttributeName: 'transactionId', AttributeType: 'S' },
{ AttributeName: 'accountId', AttributeType: 'S' },
{ AttributeName: 'year', AttributeType: 'S' },
{ AttributeName: 'month', AttributeType: 'S' },
{ AttributeName: 'day', AttributeType: 'S' },
{ AttributeName: 'transactionType', AttributeType: 'S' }
],
GlobalSecondaryIndexes: [
{
IndexName: 'AccountTimeIndex',
KeySchema: [
{ AttributeName: 'accountId', KeyType: 'HASH' },
{ AttributeName: 'year', KeyType: 'RANGE' },
{ AttributeName: 'month', KeyType: 'RANGE' },
{ AttributeName: 'day', KeyType: 'RANGE' },
{ AttributeName: 'transactionId', KeyType: 'RANGE' }
],
Projection: { ProjectionType: 'ALL' }
},
{
IndexName: 'TransactionTypeIndex',
KeySchema: [
{ AttributeName: 'accountId', KeyType: 'HASH' },
{ AttributeName: 'transactionType', KeyType: 'RANGE' },
{ AttributeName: 'year', KeyType: 'RANGE' },
{ AttributeName: 'month', KeyType: 'RANGE' }
],
Projection: { ProjectionType: 'ALL' }
}
],
BillingMode: 'PAY_PER_REQUEST'
}
// Query AccountTimeIndex GSI: All transactions for account in 2023
const yearTransactions = await docClient.send(new QueryCommand({
TableName: 'BankTransactions',
IndexName: 'AccountTimeIndex',
KeyConditionExpression: 'accountId = :account AND #year = :year',
ExpressionAttributeNames: { '#year': 'year' },
ExpressionAttributeValues: {
':account': 'ACC-12345',
':year': '2023'
}
}));
// Query AccountTimeIndex GSI: Transactions in specific month
const monthTransactions = await docClient.send(new QueryCommand({
TableName: 'BankTransactions',
IndexName: 'AccountTimeIndex',
KeyConditionExpression: 'accountId = :account AND #year = :year AND #month = :month',
ExpressionAttributeNames: { '#year': 'year', '#month': 'month' },
ExpressionAttributeValues: {
':account': 'ACC-12345',
':year': '2023',
':month': '11'
}
}));
// Query TransactionTypeIndex GSI: Deposits in 2023
const deposits = await docClient.send(new QueryCommand({
TableName: 'BankTransactions',
IndexName: 'TransactionTypeIndex',
KeyConditionExpression: 'accountId = :account AND transactionType = :type AND #year = :year',
ExpressionAttributeNames: { '#year': 'year' },
ExpressionAttributeValues: {
':account': 'ACC-12345',
':type': 'deposit',
':year': '2023'
}
}));
```
## Vollständiges Beispiel
Das folgende Beispiel zeigt Schlüssel mit mehreren Attributen von der Einrichtung bis zur Bereinigung:
### Codebeispiel
```
import {
DynamoDBClient,
CreateTableCommand,
DeleteTableCommand,
waitUntilTableExists
} from "@aws-sdk/client-dynamodb";
import {
DynamoDBDocumentClient,
PutCommand,
QueryCommand
} from "@aws-sdk/lib-dynamodb";
const client = new DynamoDBClient({ region: 'us-west-2' });
const docClient = DynamoDBDocumentClient.from(client);
async function multiAttributeKeysDemo() {
console.log("Starting Multi-Attribute GSI Keys Demo\n");
// Step 1: Create table with GSIs using multi-attribute keys
console.log("1. Creating table with multi-attribute GSI keys...");
await client.send(new CreateTableCommand({
TableName: 'TournamentMatches',
KeySchema: [
{ AttributeName: 'matchId', KeyType: 'HASH' }
],
AttributeDefinitions: [
{ AttributeName: 'matchId', AttributeType: 'S' },
{ AttributeName: 'tournamentId', AttributeType: 'S' },
{ AttributeName: 'region', AttributeType: 'S' },
{ AttributeName: 'round', AttributeType: 'S' },
{ AttributeName: 'bracket', AttributeType: 'S' },
{ AttributeName: 'player1Id', AttributeType: 'S' },
{ AttributeName: 'matchDate', AttributeType: 'S' }
],
GlobalSecondaryIndexes: [
{
IndexName: 'TournamentRegionIndex',
KeySchema: [
{ AttributeName: 'tournamentId', KeyType: 'HASH' },
{ AttributeName: 'region', KeyType: 'HASH' },
{ AttributeName: 'round', KeyType: 'RANGE' },
{ AttributeName: 'bracket', KeyType: 'RANGE' },
{ AttributeName: 'matchId', KeyType: 'RANGE' }
],
Projection: { ProjectionType: 'ALL' }
},
{
IndexName: 'PlayerMatchHistoryIndex',
KeySchema: [
{ AttributeName: 'player1Id', KeyType: 'HASH' },
{ AttributeName: 'matchDate', KeyType: 'RANGE' },
{ AttributeName: 'round', KeyType: 'RANGE' }
],
Projection: { ProjectionType: 'ALL' }
}
],
BillingMode: 'PAY_PER_REQUEST'
}));
await waitUntilTableExists({ client, maxWaitTime: 120 }, { TableName: 'TournamentMatches' });
console.log("Table created\n");
// Step 2: Insert tournament matches
console.log("2. Inserting tournament matches...");
const matches = [
{ matchId: 'match-001', tournamentId: 'WINTER2024', region: 'NA-EAST', round: 'FINALS', bracket: 'CHAMPIONSHIP', player1Id: '101', player2Id: '103', matchDate: '2024-01-20', winner: '101', score: '3-1' },
{ matchId: 'match-002', tournamentId: 'WINTER2024', region: 'NA-EAST', round: 'SEMIFINALS', bracket: 'UPPER', player1Id: '101', player2Id: '105', matchDate: '2024-01-18', winner: '101', score: '3-2' },
{ matchId: 'match-003', tournamentId: 'WINTER2024', region: 'NA-WEST', round: 'FINALS', bracket: 'CHAMPIONSHIP', player1Id: '102', player2Id: '104', matchDate: '2024-01-20', winner: '102', score: '3-2' },
{ matchId: 'match-004', tournamentId: 'SPRING2024', region: 'NA-EAST', round: 'QUARTERFINALS', bracket: 'UPPER', player1Id: '101', player2Id: '108', matchDate: '2024-03-15', winner: '101', score: '3-0' }
];
for (const match of matches) {
await docClient.send(new PutCommand({ TableName: 'TournamentMatches', Item: match }));
}
console.log(`Inserted ${matches.length} tournament matches\n`);
// Step 3: Query GSI with multi-attribute partition key
console.log("3. Query TournamentRegionIndex GSI: WINTER2024/NA-EAST matches");
const gsiQuery1 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'TournamentRegionIndex',
KeyConditionExpression: 'tournamentId = :tournament AND #region = :region',
ExpressionAttributeNames: { '#region': 'region' },
ExpressionAttributeValues: { ':tournament': 'WINTER2024', ':region': 'NA-EAST' }
}));
console.log(` Found ${gsiQuery1.Items.length} matches:`);
gsiQuery1.Items.forEach(match => {
console.log(` ${match.round} - ${match.bracket} - ${match.winner} won`);
});
// Step 4: Query GSI with multi-attribute sort key
console.log("\n4. Query PlayerMatchHistoryIndex GSI: All matches for Player 101");
const gsiQuery2 = await docClient.send(new QueryCommand({
TableName: 'TournamentMatches',
IndexName: 'PlayerMatchHistoryIndex',
KeyConditionExpression: 'player1Id = :player',
ExpressionAttributeValues: { ':player': '101' }
}));
console.log(` Found ${gsiQuery2.Items.length} matches for Player 101:`);
gsiQuery2.Items.forEach(match => {
console.log(` ${match.tournamentId}/${match.region} - ${match.matchDate} - ${match.round}`);
});
console.log("\nDemo complete");
console.log("No synthetic keys needed - GSIs use native attributes automatically");
}
async function cleanup() {
console.log("Deleting table...");
await client.send(new DeleteTableCommand({ TableName: 'TournamentMatches' }));
console.log("Table deleted");
}
// Run demo
multiAttributeKeysDemo().catch(console.error);
// Uncomment to cleanup:
// cleanup().catch(console.error);
```
**Minimales Codegerüst**
### Codebeispiel
```
// 1. Create table with GSI using multi-attribute keys
await client.send(new CreateTableCommand({
TableName: 'MyTable',
KeySchema: [
{ AttributeName: 'id', KeyType: 'HASH' } // Simple base table PK
],
AttributeDefinitions: [
{ AttributeName: 'id', AttributeType: 'S' },
{ AttributeName: 'attr1', AttributeType: 'S' },
{ AttributeName: 'attr2', AttributeType: 'S' },
{ AttributeName: 'attr3', AttributeType: 'S' },
{ AttributeName: 'attr4', AttributeType: 'S' }
],
GlobalSecondaryIndexes: [{
IndexName: 'MyGSI',
KeySchema: [
{ AttributeName: 'attr1', KeyType: 'HASH' }, // GSI PK attribute 1
{ AttributeName: 'attr2', KeyType: 'HASH' }, // GSI PK attribute 2
{ AttributeName: 'attr3', KeyType: 'RANGE' }, // GSI SK attribute 1
{ AttributeName: 'attr4', KeyType: 'RANGE' } // GSI SK attribute 2
],
Projection: { ProjectionType: 'ALL' }
}],
BillingMode: 'PAY_PER_REQUEST'
}));
// 2. Insert items with native attributes (no concatenation needed for GSI)
await docClient.send(new PutCommand({
TableName: 'MyTable',
Item: {
id: 'item-001',
attr1: 'value1',
attr2: 'value2',
attr3: 'value3',
attr4: 'value4',
// ... other attributes
}
}));
// 3. Query GSI with all partition key attributes
await docClient.send(new QueryCommand({
TableName: 'MyTable',
IndexName: 'MyGSI',
KeyConditionExpression: 'attr1 = :v1 AND attr2 = :v2',
ExpressionAttributeValues: {
':v1': 'value1',
':v2': 'value2'
}
}));
// 4. Query GSI with sort key attributes (left-to-right)
await docClient.send(new QueryCommand({
TableName: 'MyTable',
IndexName: 'MyGSI',
KeyConditionExpression: 'attr1 = :v1 AND attr2 = :v2 AND attr3 = :v3',
ExpressionAttributeValues: {
':v1': 'value1',
':v2': 'value2',
':v3': 'value3'
}
}));
// Note: If any attribute name is a DynamoDB reserved keyword, use ExpressionAttributeNames:
// KeyConditionExpression: 'attr1 = :v1 AND #attr2 = :v2'
// ExpressionAttributeNames: { '#attr2': 'attr2' }
```
## Weitere Ressourcen
+ [Bewährte Methoden für DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html)
+ [Arbeiten mit Tabellen und Daten](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithTables.html)
+ [Globale Sekundärindizes](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html)
+ [Abfrage- und Scanvorgänge](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Query.html)
# Verwalten globaler sekundärer Indizes in DynamoDB
Dieser Abschnitt beschreibt, wie Sie globale sekundäre Indizes in Amazon DynamoDB erstellen, ändern und löschen.
**Topics**
+ [Erstellen einer Tabelle mit globalen sekundären Indizes](#GSI.Creating)
+ [Beschreiben globaler sekundären Indizes in einer Tabelle](#GSI.Describing)
+ [Hinzufügen eines globalen sekundären Index zu einer vorhandenen Tabelle](#GSI.OnlineOps.Creating)
+ [Löschen eines globalen sekundären Index](#GSI.OnlineOps.Deleting)
+ [Ändern eines globalen sekundären Indexes während der Erstellung](#GSI.OnlineOps.Creating.Modify)
## Erstellen einer Tabelle mit globalen sekundären Indizes
Um eine Tabelle mit einem oder mehreren globalen sekundären Indizes zu erstellen, verwenden Sie `CreateTable` mit dem Parameter `GlobalSecondaryIndexes`. Für maximale Abfrageflexibilität können Sie bis zu 20 globale sekundäre Indizes pro Tabelle (Standardkontingent) erstellen.
Sie müssen ein Attribut angeben, das als Partitionsschlüssel des Index fungieren soll. Sie können optional ein weiteres Attribut für den Sortierschlüssel des Index festlegen. Diese beiden Schlüsselattribute müssen nicht mit den Schlüsselattributen in der Tabelle übereinstimmen. Beispielsweise sind in der *GameScores*Tabelle (siehe[Verwenden globaler sekundärer Indizes in DynamoDB](GSI.md)) `TopScore` weder Schlüsselattribute `TopScoreDateTime` noch Schlüsselattribute enthalten. Sie könnten einen globalen sekundären Index mit einem Partitionsschlüssel von `TopScore` und einem Sortierschlüssel von `TopScoreDateTime` erstellen. Sie könnten einen solchen Index verwenden, um festzustellen, ob eine Verbindung zwischen den Highscores und der Uhrzeit, an der ein Spiel stattfindet, besteht.
Jedes Schlüsselattribut eines Indexes muss ein Skalar des `String`, `Number` oder `Binary` sein. (Es kann kein Dokument oder Satz sein.) Sie können Attribute jeden Datentyps in einen globalen sekundären Index projizieren. Dazu zählen skalare Werte, Dokumente und Sätze. Eine vollständige Liste der Datentypen finden Sie unter [Datentypen](HowItWorks.NamingRulesDataTypes.md#HowItWorks.DataTypes).
Wenn Sie den bereitgestellten Modus verwenden, müssen Sie die `ProvisionedThroughput`-Einstellungen für den Index, die aus `ReadCapacityUnits` und `WriteCapacityUnits` bestehen, bereitstellen. Diese Einstellungen des bereitgestellten Durchsatzes sind getrennt von denen der Tabelle, aber verhalten sich auf ähnliche Weise. Weitere Informationen finden Sie unter [Überlegungen im Hinblick auf die bereitgestellte Durchsatzkapazität für globale sekundäre Indizes](GSI.md#GSI.ThroughputConsiderations).
Globale Sekundärindizes erben den read/write Kapazitätsmodus aus der Basistabelle. Weitere Informationen finden Sie unter [Überlegungen beim Umstellen der Kapazitätsmodi in DynamoDB](bp-switching-capacity-modes.md).
**Anmerkung**
Beim Erstellen eines neuen GSI kann es wichtig sein zu prüfen, ob Ihre Wahl des Partitionsschlüssels eine ungleichmäßige oder eingeschränkte Verteilung von Daten oder Datenverkehr über die Partitionsschlüssel-Werte des neuen Index erzeugt. In diesem Fall werden möglicherweise Backfill- und Schreibvorgänge gleichzeitig auftreten und Schreibvorgänge in die Basistabelle drosseln. Der Service ergreift Maßnahmen, um das Potenzial für dieses Szenario zu minimieren, hat jedoch keinen Einblick in die Form von Kundendaten in Bezug auf den Indexpartitionsschlüssel, die gewählte Projektion oder die Spärlichkeit des Index-Primärschlüssels.
Wenn Sie vermuten, dass Ihr neuer globaler Sekundärindex möglicherweise enge oder verzerrte Daten oder Datenverkehrsverteilung über Partitionsschlüsselwerte hinweg aufweisen könnte, sollten Sie Folgendes berücksichtigen, bevor Sie betrieblich wichtigen Tabellen neue Indizes hinzufügen.
Es ist möglicherweise am sichersten, den Index zu einem Zeitpunkt hinzuzufügen, zu dem Ihre Anwendung den geringsten Datenverkehr steuert.
Erwägen Sie, CloudWatch Contributor Insights für Ihre Basistabelle und Indizes zu aktivieren. Dies gibt Ihnen wertvolle Einblicke in Ihre Verkehrsverteilung.
Beobachten Sie `WriteThrottleEvents` den gesamten Prozess und `OnlineIndexPercentageProgress` CloudWatch geben Sie Kennzahlen an. `ThrottledRequests` Passen Sie die bereitgestellte Schreibkapazität nach Bedarf an, um das Backfill innerhalb einer angemessenen Zeit abzuschließen, ohne dass Ihr laufender Betrieb nennenswert beeinträchtigt wird. `OnlineIndexConsumedWriteCapacity`und `OnlineThrottleEvents` es wird erwartet, dass sie beim Auffüllen des Index 0 anzeigen.
Seien Sie bereit, die Indexerstellung abzubrechen, falls Sie aufgrund der Schreibdrosselung betriebliche Auswirkungen haben.
## Beschreiben globaler sekundären Indizes in einer Tabelle
Um den Status aller globalen sekundären Indizes in einer Tabelle anzuzeigen, verwenden Sie die `DescribeTable`-Operation. Der `GlobalSecondaryIndexes`-Teil der Antwort zeigt alle Indizes der Tabelle, zusammen mit deren jeweiligem aktuellen Status ( `IndexStatus`).
`IndexStatus` für einen globalen sekundären Index ist einer der folgenden:
+ `CREATING` – Der Index wird derzeit erstellt und ist noch nicht verfügbar.
+ `ACTIVE` — Der Index ist betriebsbereit und Anwendungen können in diesem `Query`-Operationen durchführen
+ `UPDATING` — Die Einstellungen des bereitgestellten Durchsatzes des Index werden geändert.
+ `DELETING` – Der Index wird derzeit gelöscht und kann nicht länger verwendet werden.
Wenn DynamoDB einen globalen sekundären Index fertiggestellt hat, ändert sich der Indexstatus von `CREATING` in `ACTIVE`.
## Hinzufügen eines globalen sekundären Index zu einer vorhandenen Tabelle
Um einen globalen sekundären Index einer vorhandenen Tabelle hinzuzufügen, verwenden Sie die `UpdateTable`-Operation mit dem Parameter `GlobalSecondaryIndexUpdates`. Geben Sie die folgenden Informationen ein:
+ Ein Indexname. Der Name muss innerhalb der Indizes der Tabelle eindeutig sein.
+ Das Schlüsselschema des Index. Sie müssen ein Attribut für den Partitionsschlüssel des Index angeben. Sie können optional ein weiteres Attribut für den Sortierschlüssel des Index festlegen. Diese beiden Schlüsselattribute müssen nicht mit den Schlüsselattributen in der Tabelle übereinstimmen. Die Datentypen für jedes Schemaattribut müssen skalar sein: `String`, `Number` oder `Binary`.
+ Die Attribute, die von der Tabelle in den Index projiziert werden:
+ `KEYS_ONLY` — Jeder Eintrag im Index besteht nur aus dem Tabellenpartitionsschlüssel und Sortierschlüsselwerten, sowie den Indexschlüsselwerten.
+ `INCLUDE` — Zusätzlich zu den in `KEYS_ONLY` beschriebenen Attributen, enthält der sekundäre Index andere Nicht-Schlüsselattribute, die Sie angeben.
+ `ALL` — Der Index enthält alle Attribute der Quelltabelle.
+ Die Einstellungen für den bereitgestellten Durchsatz für den Index bestehen aus `ReadCapacityUnits` und `WriteCapacityUnits`. Diese Einstellungen für den bereitgestellten Durchsatz sind getrennt von denen der Tabelle.
Sie können nur einen globalen sekundären Index pro `UpdateTable`-Operation verwenden.
### Phasen der Index-Erstellung
Wenn Sie einen neuen globalen sekundären Index einer vorhandenen Tabelle hinzufügen, ist die Tabelle weiterhin verfügbar, während der Index erstellt wird. Jedoch ist der neue Index für Abfrageoperationen nicht verfügbar bis sein Status sich von `CREATING` in `ACTIVE` ändert.
**Anmerkung**
Bei der Erstellung des globalen sekundären Index wird Application Auto Scaling nicht verwendet. Wenn die `MIN`-Kapazität für Application Auto Scaling erhöht wird, verkürzt sich die Erstellungszeit für den globalen sekundären Index nicht.
Im Hintergrund erstellt DynamoDB den Index in zwei Phasen:
**Ressourcenzuweisung**
DynamoDB weist die erforderlichen Rechen- und Speicherressourcen zu, um den Index zu erstellen.
Während der Ressourcenzuordnungsphase ist das `IndexStatus`-Attribut `CREATING` und das `Backfilling`-Attribut ist False. Um den Status einer Tabelle und all ihre sekundären Indizes abzurufen, verwenden Sie die `DescribeTable`-Operation.
Während sich der Index in der Ressourcenzuweisungsphase befindet, können Sie weder den Index noch seine übergeordnete Tabelle löschen. Sie können auch den bereitgestellten Durchsatz des Index oder der Tabelle nicht ändern. Sie in der Tabelle keine anderen Indizes hinzufügen oder löschen. Sie können jedoch den bereitgestellten Durchsatz dieser anderen Indizes ändern.
**Abgleichen**
Für jedes Element in der Tabelle bestimmt DynamoDB, welche Reihe von Attributen auf Basis seiner Projektion (`KEYS_ONLY`, `INCLUDE`, oder `ALL`) in den Index geschrieben werden. Es schreibt dann diese Attribute in den Index. Während der Abgleichphase verfolgt DynamoDB Elemente, die in der Tabelle hinzugefügt, gelöscht oder aktualisiert werden. Die Attribute dieser Elemente werden, soweit erforderlich, auch in dem Index hinzugefügt, gelöscht oder aktualisiert.
Während der Abgleichphase ist das `IndexStatus`-Attribut auf `CREATING` gesetzt und das `Backfilling`-Attribut ist True. Um den Status einer Tabelle und all ihrer es abzurufen, verwenden Sie die `DescribeTable`-Operation.
Während der Index abgleicht, können Sie seine übergeordnete Tabelle nicht löschen. Sie können jedoch weiterhin den den Index löschen oder den bereitgestellten Durchsatz der Tabelle und dessen sekundäre Indizes ändern.
Während der Abgleichphase können einige Schreibvorgänge regelwidriger Elemente erfolgreich sein, während andere abgelehnt werden. Nach dem Abgleich werden alle Schreibvorgänge für Elemente, die gegen das neue Schlüsselschema des Index verstoßen, abgelehnt. Wir empfehlen, dass Sie das Tool Violation Detector ausführen, nachdem die Abgleichphase abgeschlossen ist, um alle Schlüsselverstöße, die gegebenenfalls aufgetreten sind, zu erkennen und zu beheben. Weitere Informationen finden Sie unter [Erkennen und Korrigieren von Indexschlüsselverstößen in DynamoDB](GSI.OnlineOps.ViolationDetection.md).
Während der laufenden Ressourcenzuordnung und Abgleichphasen ist der Index im Status `CREATING`. Während dieser Zeit führt DynamoDB Leseoperationen für die Tabelle durch. Lesevorgänge aus der Basistabelle zum Auffüllen des globalen sekundären Indexes werden Ihnen nicht in Rechnung gestellt.
Sobald die Erstellung des Index abgeschlossen ist, ändert sich sein Status in `ACTIVE`. Sie können den Index nicht `Query` oder `Scan` bis er `ACTIVE` ist.
**Anmerkung**
In einigen Fällen kann DynamoDB aufgrund von Indexschlüsselverstößen keine Daten aus der Tabelle in den Index schreiben. Dies kann in folgenden Fällen passieren:
Der Datentyp eines Attributwerts stimmt nicht mit dem Datentyp eines Indexschlüssel-Schema-Datentyps überein.
Die Größe eines Attributs überschreitet die maximale Länge für ein Indexschlüsselattribut.
Ein Indexschlüsselattribut hat eine leere Zeichenfolge oder einen leeren Binärattributwert.
Indexschlüsselverstöße beeinträchtigen die Erstellung des globalen sekundären Indexes nicht. Wenn der Index jedoch `ACTIVE` wird, sind die verstoßenden Schlüssel nicht im Index vorhanden.
DynamoDB bietet ein eigenständiges Tool für das Erkennen und Lösen dieser Probleme. Weitere Informationen finden Sie unter [Erkennen und Korrigieren von Indexschlüsselverstößen in DynamoDB](GSI.OnlineOps.ViolationDetection.md).
### Hinzufügen eines globalen sekundären Index zu einer großen Tabelle
Die erforderliche Zeit für das Erstellen eines globalen sekundären Indizes hängt von mehreren Faktoren ab, z. B.:
+ Die Tabellengröße
+ Die Anzahl der Elemente in der Tabelle, die sich für eine Aufnahme in den Index eignen
+ Die Reihe von Attributen, die in den Index projiziert werden
+ Schreibaktivität der Haupttabelle, während der Index erstellt wird
Wenn Sie einen globalen sekundären Index einer sehr große Tabelle hinzufügen, kann es sehr lang dauern, bis der Erstellungsvorgang abgeschlossen ist. Um den Fortschritt zu überwachen und festzustellen, ob der Index über ausreichende Schreibkapazität verfügt, ziehen Sie die folgenden CloudWatch Amazon-Metriken zu Rate:
+ `OnlineIndexPercentageProgress`
Weitere Informationen zu CloudWatch Metriken im Zusammenhang mit DynamoDB finden Sie unter. [DynamoDB-Metriken](metrics-dimensions.md#dynamodb-metrics)
**Wichtig**
Möglicherweise müssen Sie sehr große Tabellen auf eine Zulassungsliste setzen, bevor Sie einen globalen sekundären Index erstellen oder aktualisieren können. Bitte wenden Sie sich an den AWS Support, um Ihre Tische auf die Zulassungsliste zu setzen.
Während ein Index abgeglichen wird, verwendet DynamoDB interne Systemkapazität um aus der Tabelle zu lesen. Dies soll die Auswirkung der Indexerstellung minimieren und vermeiden, dass der Tabelle nicht genügend Schreibkapazität zur Verfügung steht.
## Löschen eines globalen sekundären Index
Wenn Sie keinen globalen sekundären Index mehr benötigen, können Sie ihn mithilfe von `UpdateTable` verwenden.
Sie können nur einen globalen sekundären Index pro `UpdateTable`verwenden.
Während der globale sekundäre Index gelöscht wird, hat dies keine Auswirkung auf jegliche Lese- oder Schreibaktivität in der übergeordneten Tabelle. Während die Löschung ausgeführt wird, können Sie weiterhin den bereitgestellten Durchsatz anderer Indizes ändern
**Anmerkung**
Beim Löschen einer Tabelle mithilfe der `DeleteTable`-Aktion, werden alle es in dieser Tabelle ebenfalls gelöscht.
Die Löschung des globalen sekundären Index wird Ihrem Konto nicht berechnet.
## Ändern eines globalen sekundären Indexes während der Erstellung
Während ein Index erstellt wird, können Sie die `DescribeTable`-Operation verwenden, um zu bestimmen, in welcher Phase er sich befindet. Die Beschreibung für den Index enthält ein Boolesches Attribut, `Backfilling`, um anzugeben, ob DynamoDB derzeit den Index mit Elementen aus der Tabelle lädt. Wenn `Backfilling` True ist, dann ist die Phase der Ressourcenzuordnung abgeschlossen und der Index ist dabei, abzugleichen.
Während des Abgleichens können Sie den erstellten Index löschen. Während der Phase können Sie in der Tabelle keine anderen Indizes hinzufügen oder löschen.
**Anmerkung**
Bei Indizes, die als Teil einer `CreateTable`-Operation erstellt wurden, wird das `Backfilling`-Attribut in der `DescribeTable`-Ausgabe nicht angezeigt. Weitere Informationen finden Sie unter [Phasen der Index-Erstellung](#GSI.OnlineOps.Creating.Phases).
# Erkennen und Korrigieren von Indexschlüsselverstößen in DynamoDB
Während der Abgleichphase der globalen sekundären Index-Erstellung untersucht Amazon DynamoDB jedes Element in der Tabelle, um zu ermitteln, ob es in den Index aufgenommen werden kann. Einige Elemente können möglicherweise nicht in den Index aufgenommen werden, da sie zu Indexschlüsselverstößen führen würden. In diesem Fall verbleiben die Elemente in der Tabelle, der Index verfügt dann jedoch über keinen entsprechenden Eintrag für dieses Element.
*Verstoß des Indexschlüssels* tritt in folgenden Situationen auf:
+ Die Datentypen zwischen einem Attributwert und dem Indexschlüsselschema stimmen nicht überein. Angenommen, eines der Elemente in der Tabelle `GameScores` verfügt über den Wert `TopScore` des Typs `String`. Wenn Sie dann einen globalen sekundären Index mit dem Partitionsschlüssel `TopScore` vom Typ `Number` hinzufügen, verstößt das Element aus der Tabelle gegen den Index.
+ Ein Attributwert aus der Tabelle überschreitet die maximale Länge für ein Indexschlüsselattribut. Die maximale Länge des Partitionsschlüssels beträgt 2048 bytes und die maximale Länge des Sortierschlüssels 1024 bytes. Wenn einer der entsprechenden Attributwerte in der Tabelle diese Grenzwerte überschreitet, würde das Element aus der Tabelle gegen den Index verstoßen.
**Anmerkung**
Wenn ein Zeichenfolgen- oder Binär-Attributwert für ein Attribut festgelegt ist, das als Indexschlüssel verwendet wird, muss der Attributwert eine Länge größer als Null haben. Andernfalls würde das Element aus der Tabelle gegen den Indexschlüssel verstoßen.
Dieses Tool kennzeichnet diesen Indexschlüsselverstoß derzeit nicht.
Wenn ein Indexschlüsselverstoß auftritt, wird die Auffüllphase ohne Unterbrechung fortgesetzt. Verstoßende Elemente sind jedoch nicht im Index enthalten. Nach Abschluss der Abgleichphase werden alle Schreibvorgänge für Elemente, die gegen das neue Schlüsselschema des Indexes verstoßen, abgelehnt.
Um die Attributwerte in einer Tabelle, die gegen einen Indexschlüssel verstoßen, zu identifizieren und zu korrigieren, verwenden Sie das Tool Violation Detector. Um Violation Detector auszuführen, erstellen Sie eine Konfigurationsdatei, die den Namen einer zu scannenden Tabelle sowie die Datentypen des Partitions- und Sortierschlüssels des globalen sekundären Indizes enthält und angibt, welche Aktionen unternommen werden, sollten Verstöße gegen den Indexschlüssel gefunden werden. Violation Detector kann in einem der beiden folgenden Modi ausgeführt werden:
+ **Erkennungsmodus** — Erkennt Indexschlüsselverstöße. Verwenden Sie den Erkennungsmodus, um die Elemente in der Tabelle zu ermitteln, die in einem globalen sekundären Index zu Schlüsselverstößen führen. (Sie können optional angeben, dass die den Verstoß verursachenden Tabellenelemente sofort gelöscht werden, nachdem sie gefunden wurden.) Die Ausgabe des Erkennungsmodus wird eine Datei geschrieben, die Sie für weitere Analysen verwenden können.
+ **Korrekturmodus** — Korrigiert Indexschlüsselverstöße. Im Korrekturmodus liest Violation Detector eine Eingabedatei im gleichen Format wie die Ausgabedatei des Erkennungsmodus. Der Korrekturmodus liest die Datensätze aus der Eingabedatei und löscht zu jedem Datensatz die entsprechenden Elemente in der Tabelle bzw. aktualisiert diese. (Wenn Sie beschließen, die Elemente zu aktualisieren, müssen Sie die Eingabedatei bearbeiten und für diese Aktualisierungen entsprechende Werte festlegen.)
## Herunterladen und Ausführen von Violation Detector
Violation Detector steht als ausführbares Java-Archiv (`.jar`-Datei) zur Verfügung und kann auf Windows-, MacOS- oder Linux-Computern ausgeführt werden. Der Violation Detector erfordert Java 1.7 (oder höher) und Apache Maven.
+ [Laden Sie den Verletzungsdetektor herunter von GitHub](https://github.com/awslabs/dynamodb-online-index-violation-detector)
Um Violation Detector mit Maven herunterzuladen und zu installieren, befolgen Sie die Anweisungen in der `README.md`-Datei.
Um Violation Detector zu starten, gehen Sie zu dem Verzeichnis, in dem Sie `ViolationDetector.java` erstellt haben, und geben Sie den folgenden Befehl ein:
```
java -jar ViolationDetector.jar [options]
```
Die Violation-Detector-Befehlszeile akzeptiert die folgenden Optionen:
+ `-h | --help` – Druckt eine Nutzungszusammenfassung und die Optionen für Violation Detector.
+ `-p | --configFilePath` `value` – Der vollständig qualifizierte Namen einer Violation Detector Konfigurationsdatei. Weitere Informationen finden Sie unter [Die Konfigurationsdatei für den Violation Detector](#GSI.OnlineOps.ViolationDetection.ConfigFile).
+ `-t | --detect` `value`– Erkennt Indexschlüsselverstöße in der Tabelle und schreibt sie in die Ausgabedatei von Violation Detector. Wenn der Wert für diesen Parameter auf `keep` festgelegt ist, werden Elemente mit Schlüsselverstößen nicht geändert. Wenn der Wert auf `delete` festgelegt ist, werden Elemente mit Schlüsselverstößen aus der Tabelle gelöscht.
+ `-c | --correct` `value` — Liest Indexschlüsselverstöße aus einer Eingabedatei und nimmt entsprechende Korrekturen an den Elementen in der Tabelle vor. Wenn der Wert für diesen Parameter auf `update` festgelegt ist, werden Elemente mit Schlüsselverstößen mit neuen, konformen Werten aktualisiert. Wenn der Wert auf `delete` festgelegt ist, werden Elemente mit Schlüsselverstößen aus der Tabelle gelöscht.
## Die Konfigurationsdatei für den Violation Detector
Zur Laufzeit erfordert das Tool Violation Detector eine Konfigurationsdatei. Die Parameter in dieser Datei bestimmen, auf welche DynamoDB-Ressourcen Violation Detector zugreifen kann und wie viel bereitgestellten Durchsatz es verbrauchen darf. In der Tabelle unten werden diese Parameter beschrieben.
****
| Parametername | Description | Erforderlich? |
| --- | --- | --- |
| `awsCredentialsFile` | Der vollständig qualifizierte Namen einer Datei, die Ihre AWS -Anmeldeinformationen enthält. Die Datei mit den Anmeldeinformationen muss das folgende Format aufweisen: accessKey = access_key_id_goes_here
secretKey = secret_key_goes_here
| Ja |
| `dynamoDBRegion` | Die AWS Region, in der sich die Tabelle befindet. Beispiel: `us-west-2`. | Ja |
| `tableName` | Der Name der zu scannenden DynamoDB-Tabelle. | Ja |
| `gsiHashKeyName` | Der Name des Partitionsschlüssels des Index. | Ja |
| `gsiHashKeyType` | Der Datentyp des Partitionsschlüssels des Index – `String`, `Number` oder `Binary`: `S \| N \| B` | Ja |
| `gsiRangeKeyName` | Der Name des Sortierschlüssels des Index. Geben Sie diesen Parameter nicht an, wenn der Index nur über einen einfachen Primärschlüssel (Partitionsschlüssel) verfügt. | Nein |
| `gsiRangeKeyType` | Der Datentyp des Sortierschlüssels–`String`,`Number`, oder`Binary`: `S \| N \| B` Geben Sie diesen Parameter nicht an, wenn der Index nur über einen einfachen Primärschlüssel (Partitionsschlüssel) verfügt. | Nein |
| `recordDetails` | Gibt an, ob alle Details der Indexschlüsselverstöße in die Ausgabedatei geschrieben werden sollen. Ist dieser Parameter auf `true` (Standardwert) gesetzt, werden alle Informationen zu den Verstoß-Elementen aufgezeichnet. Wenn er auf `false` festgelegt ist, wird nur die Anzahl der Verstöße erfasst. | Nein |
| `recordGsiValueInViolationRecord` | Gibt an, ob die Werte der verursachenden Indexschlüssel in die Ausgabedatei geschrieben werden sollen. Ist dieser Parameter auf `true` (Standardwert) gesetzt, werden die Schlüsselwerte aufgezeichnet. Ist dieser Parameter auf `false` festgelegt, werden die Schlüsselwerte nicht aufgezeichnet. | Nein |
| `detectionOutputPath` | Der vollständige Pfad der Violation-Detector-Ausgabedatei. Dieser Parameter unterstützt das Schreiben in ein lokales Verzeichnis oder in Amazon Simple Storage Service (Amazon S3). Im Folgenden sind einige Beispiele aufgeführt: `detectionOutputPath = ``//local/path/filename.csv` `detectionOutputPath = ``s3://bucket/filename.csv` Die Informationen in der Ausgabedatei werden im komma-separierten Werte (CSV)-Format angezeigt. Wenn Sie `detectionOutputPath` nicht festlegen, wird die Ausgabedatei `violation_detection.csv` genannt und in das aktuelle Arbeitsverzeichnis geschrieben. | Nein |
| `numOfSegments` | Die Anzahl der Segmente des parallelen Scans, die verwendet werden sollen, wenn Violation Detector die Tabelle scannt. Der Standardwert ist 1. Dies bedeutet, dass die Tabelle sequenziell gescannt wird. Wenn der Wert 2 oder höher lautet, unterteilt Violation Detector die Tabelle in diese Anzahl logischer Segmente und eine gleichmäßigen Anzahl von Scan-Threads. Die maximale Einstellung für `numOfSegments` lautet 4.096 Tage.Bei größeren Tabellen ist ein paralleler Scan in der Regel schneller als ein sequenzieller Scan. Wenn die Tabelle außerdem groß genug ist, um sich über mehrere Partitionen zu erstrecken, verteilt ein paralleler Scan die Lesevorgänge gleichmäßig auf mehrere Partitionen.Weitere Informationen zu parallelen Scans in DynamoDB finden Sie im Abschnitt [Parallele Scans](Scan.md#Scan.ParallelScan). | Nein |
| `numOfViolations` | Der obere Grenzwert für Indexschlüsselverstöße, die in die Ausgabedatei geschrieben werden sollen. Ist dieser Parameter auf `-1` (Standardwert) gesetzt, wird die gesamte Tabelle gescannt. Ist eine positive Ganzzahl festgelegt, beendet Violation Detector den Vorgang nach Erreichen dieser Anzahl von Verstößen. | Nein |
| `numOfRecords` | Die Anzahl der Elemente in der Tabelle, die gescannt werden sollen. Ist dieser Parameter auf -1 (Standardwert) gesetzt, wird die gesamte Tabelle gescannt. Ist eine positive Ganzzahl festgelegt, beendet Violation Detector den Vorgang, nachdem es diese Anzahl von Elementen in der Tabelle gescannt hat. | Nein |
| `readWriteIOPSPercent` | Regelt den Prozentsatz der bereitgestellten Lesekapazitätseinheiten, die während des Tabellen-Scans verbraucht werden. Der Bereich gültiger Werte lautet `1` bis `100`. Der Standardwert (`25`) bedeutet, dass Violation Detector nicht mehr als 25 % des bereitgestellten Lesedurchsatzes der Tabelle verbraucht. | Nein |
| `correctionInputPath` | Der vollständige Pfad der Violation-Detector-Korrektureingabedatei. Wenn Sie Violation Detector im Korrekturmodus ausführen, wird der Inhalt dieser Datei herangezogen, um die Datenelemente in der Tabelle, die gegen den verstoßen, zu ändern oder zu löschen. Das Format der `correctionInputPath`-Datei ist identisch mit der `detectionOutputPath`-Datei. So können Sie die Ausgabe des Erkennungsmodus als Eingabe für den Korrekturmodus verarbeiten. | Nein |
| `correctionOutputPath` | Der vollständige Pfad der Violation-Detector-Korrekturausgabedatei. Diese Datei wird nur erstellt, wenn bei der Aktualisierung Fehler aufgetreten sind. Dieser Parameter unterstützt das Schreiben in ein lokales Verzeichnis oder in Amazon S3. Im Folgenden sind einige Beispiele aufgeführt: `correctionOutputPath = ``//local/path/filename.csv` `correctionOutputPath = ``s3://bucket/filename.csv` Die Informationen in der Ausgabedatei werden im CSV-Format angezeigt. Wenn Sie `correctionOutputPath` nicht festlegen, wird die Ausgabedatei `violation_update_errors.csv` genannt und in das aktuelle Arbeitsverzeichnis geschrieben. | Nein |
## Erkennung
Um Verstöße gegen den Indexschlüssel zu erkennen, verwenden Sie Violation Detector mit der Befehlszeilenoption `--detect`. Um zu verstehen, wie diese Option funktioniert, sollten Sie die Tabelle `ProductCatalog` zurate ziehen. Im Folgenden finden Sie eine Liste der Elemente in der Tabelle. Nur der Primärschlüssel (`Id`) und das `Price`-Attribut werden angezeigt.
****
| ID (Primärschlüssel) | Preis |
| --- | --- |
| 101 | 5 |
| 102 | 20 |
| 103 | 200 |
| 201 | 100 |
| 202 | 200 |
| 203 | 300 |
| 204 | 400 |
| 205 | 500 |
Alle Werte für `Price` sind vom Typ `Number`. Da DynamoDB jedoch schemalos ist, können Sie ein Element mit einem nicht numerischen `Price` hinzufügen. Angenommen, wir fügen ein anderes Element zur Tabelle `ProductCatalog` hinzu.
****
| ID (Primärschlüssel) | Preis |
| --- | --- |
| 999 | "Hello" |
Die Tabelle verfügt jetzt über insgesamt neun Elemente.
Nun fügen Sie der Tabelle einen neuen globalen sekundären Index hinzu: `PriceIndex`. Der Primärschlüssel für diesen Index ist ein Partitionsschlüssel, `Price`, vom Typ `Number`. Nachdem der Index erstellt wurde, enthält er acht Elemente—aber die `ProductCatalog`-Tabelle verfügt aber über neun Elemente. Der Grund für diese Abweichung ist, dass der Wert `"Hello"` vom Typ `String` ist, `PriceIndex` aber über einen Primärschlüssel vom Typ `Number` verfügt. Der `String`-Wert verstößt gegen den Schlüssel des globalen sekundären Indizes, also ist er im Index nicht vorhanden.
Um Violation Detector in diesem Szenario zu verwenden, erstellen Sie zuerst eine Konfigurationsdatei, wie z. B. folgende:
```
# Properties file for violation detection tool configuration.
# Parameters that are not specified will use default values.
awsCredentialsFile = /home/alice/credentials.txt
dynamoDBRegion = us-west-2
tableName = ProductCatalog
gsiHashKeyName = Price
gsiHashKeyType = N
recordDetails = true
recordGsiValueInViolationRecord = true
detectionOutputPath = ./gsi_violation_check.csv
correctionInputPath = ./gsi_violation_check.csv
numOfSegments = 1
readWriteIOPSPercent = 40
```
Als Nächstes führen Sie den Violation Detector aus, wie im folgenden Beispiel gezeigt.
```
$ java -jar ViolationDetector.jar --configFilePath config.txt --detect keep
Violation detection started: sequential scan, Table name: ProductCatalog, GSI name: PriceIndex
Progress: Items scanned in total: 9, Items scanned by this thread: 9, Violations found by this thread: 1, Violations deleted by this thread: 0
Violation detection finished: Records scanned: 9, Violations found: 1, Violations deleted: 0, see results at: ./gsi_violation_check.csv
```
Wenn der Konfigurationsparameter `recordDetails` auf `true` gesetzt ist, schreibt Violation Detector die Details jedes Verstoßes in die Ausgabedatei, wie im folgenden Beispiel:
```
Table Hash Key,GSI Hash Key Value,GSI Hash Key Violation Type,GSI Hash Key Violation Description,GSI Hash Key Update Value(FOR USER),Delete Blank Attributes When Updating?(Y/N)
999,"{""S"":""Hello""}",Type Violation,Expected: N Found: S,,
```
Die Ausgabedatei ist im CSV-Format. Die erste Zeile in der Datei ist eine Überschrift, gefolgt von einem Datensatz für jedes Element, das gegen den Indexschlüssel verstößt. Die Felder dieser die Verletzung verursachenden Datensätze sind folgende:
+ **Hash-Schlüssel der Tabelle** — Der Partitionsschlüsselwert des Elements in der Tabelle.
+ **Tabellenbereichsschlüssel** — Der Sortierschlüsselwert des Elements in der Tabelle.
+ **GSI-Hash-Schlüsselwert** – Partitionsschlüsselwert des globalen sekundären Indizes.
+ **Art des GSI-Hash-Schlüsselverstoßes** — Entweder `Type Violation` oder `Size Violation`.
+ **Beschreibung des GSI-Hash-Schlüsselverstoßes** — Die Ursache des Verstoßes.
+ **Aktualisierungswert des GSI-Hash-Schlüssels (FÜR BENUTZER)** — Im Korrekturmodus ein neuer, vom Benutzer angegebener Wert für das Attribut.
+ **Schlüsselwert des GSI-Bereichs** – Der Sortierschlüsselwert des globalen sekundären Indexes.
+ **Art des GSI-Bereichsschlüsselverstoßes** — Entweder `Type Violation` oder `Size Violation`.
+ **Beschreibung des GSI-Bereichsschlüsselverstoßes** — Die Ursache des Verstoßes.
+ **Aktualisierungswert des GSI-Bereichsschlüssels (FÜR BENUTZER)** — Im Korrekturmodus ein neuer, vom Benutzer angegebener Wert für das Attribut.
+ **Leeres Attribut bei Aktualisierung löschen (J/N)** — Bestimmt im Korrekturmodus, ob das den Verstoß verursachende Element in der Tabelle gelöscht (J) oder beibehalten (N) werden soll; jedoch nur, wenn eines der folgenden Felder leer ist:
+ `GSI Hash Key Update Value(FOR USER)`
+ `GSI Range Key Update Value(FOR USER)`
Wenn eines dieser Felder nicht leer ist, hat `Delete Blank Attribute When Updating(Y/N)` keine Auswirkungen.
**Anmerkung**
Das Ausgabeformat kann abhängig von der Konfigurationsdatei und den Befehlszeilenoptionen variieren. Wenn die Tabelle z. B. über einen einfachen Primärschlüssel (ohne Sortierschlüssel) verfügt, sind in der Ausgabe keine Sortierschlüsselfelder vorhanden.
Die den Verstoß verursachenden Datensätze in der Datei sind möglicherweise nicht sortiert.
## Korrektur
Um Verstöße gegen den Indexschlüssel zu korrigieren, verwenden Sie Violation Detector mit der Befehlszeilenoption `--correct`. Im Korrekturmodus liest Violation Detector die Eingabedatei, die im Parameter `correctionInputPath` angegeben ist. Diese Datei hat das gleiche Format wie die Datei `detectionOutputPath`. Sie können also die Ausgabe der Erkennung als Eingabe für die Korrektur verwenden.
Violation Detector bietet zwei verschiedene Möglichkeiten zur Korrektur von Indexschlüsselverstößen:
+ **Verstöße löschen** – Löscht die Tabellenelemente, die über Verstoß-Attributwerte verfügen.
+ **Verstöße aktualisieren** – Aktualisiert die Tabellenelemente durch Ersetzen der Verstoß-Attribute durch konforme Werte.
In beiden Fällen können Sie die Ausgabedatei aus dem Erkennungsmodus als Eingabe für den Korrekturmodus verwenden.
Setzen wir unser Beispiel `ProductCatalog` fort: Angenommen, wir möchten das Verstoß-Element aus der Tabelle löschen. Zu diesem Zweck verwenden Sie die folgenden Befehlszeile:
```
$ java -jar ViolationDetector.jar --configFilePath config.txt --correct delete
```
An diesem Punkt werden Sie gebeten zu bestätigen, ob die verletzenden Elemente gelöscht werden sollen.
```
Are you sure to delete all violations on the table?y/n
y
Confirmed, will delete violations on the table...
Violation correction from file started: Reading records from file: ./gsi_violation_check.csv, will delete these records from table.
Violation correction from file finished: Violations delete: 1, Violations Update: 0
```
Nun verfügen `ProductCatalog` und `PriceIndex` über dieselbe Anzahl Elemente.
# Arbeiten mit globalen sekundären Indizes: Java
Sie können die AWS SDK für Java Document API verwenden, um eine Amazon DynamoDB-Tabelle mit einem oder mehreren globalen Sekundärindizes zu erstellen, die Indizes in der Tabelle zu beschreiben und Abfragen mithilfe der Indizes durchzuführen.
Nachfolgend sind die allgemeinen Schritte für Tabellenoperationen aufgeführt.
1. Erstellen Sie eine Instance der `DynamoDB`-Klasse.
1. Stellen Sie den erforderlichen und optionalen Parameter für die Operation bereit, indem Sie die entsprechenden Anforderungsobjekte erstellen.
1. Rufen Sie die entsprechende Methode auf, die vom Client, den Sie im vorhergehenden Schritt erstellt haben, bereitgestellt wird.
**Topics**
+ [Erstellen einer Tabelle mit einem globalen sekundären Index](#GSIJavaDocumentAPI.CreateTableWithIndex)
+ [Beschreiben einer Tabelle mit einem globalen sekundären Index](#GSIJavaDocumentAPI.DescribeTableWithIndex)
+ [Abfragen eines globalen sekundären Indexes](#GSIJavaDocumentAPI.QueryAnIndex)
+ [Beispiel: Globale Sekundärindizes mithilfe der AWS SDK für Java Dokument-API](GSIJavaDocumentAPI.Example.md)
## Erstellen einer Tabelle mit einem globalen sekundären Index
Sie können globale sekundäre Indizes gleichzeitig mit der Tabelle erstellen. Zu diesem Zweck verwenden Sie `CreateTable` und geben Ihre Spezifikationen für ein oder mehrere globale sekundäre Indizes an. Das folgende Java-Codebeispiel erstellt eine Tabelle, die Informationen über Wetterdaten enthält. Der Partitionsschlüssel ist `Location` und der Sortierschlüssel `Date`. Ein globaler sekundärer Index mit Namen `PrecipIndex` ermöglicht einen schnellen Zugriff auf Niederschlagsdaten für verschiedene Standorte.
Im Folgenden sind die Schritte zum Erstellen einer Tabelle mit einem globalen sekundären Index unter Verwendung der DynamoDB-Dokument-API aufgeführt.
1. Erstellen Sie eine Instance der `DynamoDB`-Klasse.
1. Erstellen Sie eine Instance der `CreateTableRequest`-Klasse, um die Anforderungsinformationen bereitzustellen.
Sie müssen den Tabellennamen, seinen zugehörigen Primärschlüssel und die Werte des bereitgestellten Durchsatzes angeben. Für den globalen sekundären Index müssen Sie den Indexnamen, seine Einstellungen des bereitgestellten Durchsatzes, die Attributdefinitionen für den Index, das Schlüsselschema für den Index und die Attributprojektion angeben.
1. Rufen Sie die `createTable`-Methode auf, indem das Anforderungsobjekt als Parameter festgelegt wird.
Im folgenden Java-Codebeispiel werden die vorherigen Schritte veranschaulicht. Der Code erstellt eine Tabelle (`WeatherData`) mit einem globalen sekundären Index (`PrecipIndex`). Der Index-Partitionsschlüssel ist `Date` und der Sortierschlüssel `Precipitation`. Alle Tabellenattribute werden in den Index projiziert. Benutzer können diesen Index abfragen, um Wetterdaten für ein bestimmtes Datum abzurufen. Optional können diese nach Niederschlagsmenge sortiert werden.
Da es sich bei `Precipitation` um kein Schlüsselattribut für die Tabelle handelt, ist es nicht erforderlich. `WeatherData`-Elemente ohne `Precipitation` erscheinen jedoch nicht in `PrecipIndex`.
```
AmazonDynamoDB client = AmazonDynamoDBClientBuilder.standard().build();
DynamoDB dynamoDB = new DynamoDB(client);
// Attribute definitions
ArrayList attributeDefinitions = new ArrayList();
attributeDefinitions.add(new AttributeDefinition()
.withAttributeName("Location")
.withAttributeType("S"));
attributeDefinitions.add(new AttributeDefinition()
.withAttributeName("Date")
.withAttributeType("S"));
attributeDefinitions.add(new AttributeDefinition()
.withAttributeName("Precipitation")
.withAttributeType("N"));
// Table key schema
ArrayList tableKeySchema = new ArrayList();
tableKeySchema.add(new KeySchemaElement()
.withAttributeName("Location")
.withKeyType(KeyType.HASH)); //Partition key
tableKeySchema.add(new KeySchemaElement()
.withAttributeName("Date")
.withKeyType(KeyType.RANGE)); //Sort key
// PrecipIndex
GlobalSecondaryIndex precipIndex = new GlobalSecondaryIndex()
.withIndexName("PrecipIndex")
.withProvisionedThroughput(new ProvisionedThroughput()
.withReadCapacityUnits((long) 10)
.withWriteCapacityUnits((long) 1))
.withProjection(new Projection().withProjectionType(ProjectionType.ALL));
ArrayList indexKeySchema = new ArrayList();
indexKeySchema.add(new KeySchemaElement()
.withAttributeName("Date")
.withKeyType(KeyType.HASH)); //Partition key
indexKeySchema.add(new KeySchemaElement()
.withAttributeName("Precipitation")
.withKeyType(KeyType.RANGE)); //Sort key
precipIndex.setKeySchema(indexKeySchema);
CreateTableRequest createTableRequest = new CreateTableRequest()
.withTableName("WeatherData")
.withProvisionedThroughput(new ProvisionedThroughput()
.withReadCapacityUnits((long) 5)
.withWriteCapacityUnits((long) 1))
.withAttributeDefinitions(attributeDefinitions)
.withKeySchema(tableKeySchema)
.withGlobalSecondaryIndexes(precipIndex);
Table table = dynamoDB.createTable(createTableRequest);
System.out.println(table.getDescription());
```
Sie müssen warten bis DynamoDB die Tabelle erstellt und den Tabellenstatus auf `ACTIVE` setzt. Im Anschluss können Sie die Daten in der Tabelle ablegen.
## Beschreiben einer Tabelle mit einem globalen sekundären Index
Um Informationen zu globalen sekundären Indizes in einer Tabelle zu erhalten, verwenden Sie `DescribeTable`. Sie können auf den Namen, das Schlüsselschema und die projizierten Attribute von jedem Index zugreifen.
Im Folgenden werden die Schritte zum Zugriff auf globale sekundäre Index-Informationen in einer Tabelle dargelegt.
1. Erstellen Sie eine Instance der `DynamoDB`-Klasse.
1. Erstellen Sie eine Instance der `Table`-Klasse, um den Index darzustellen, mit dem Sie arbeiten möchten.
1. Rufen Sie die `describe`-Methode für das `Table`-Objekt auf.
Im folgenden Java-Codebeispiel werden die vorherigen Schritte veranschaulicht.
**Example**
```
AmazonDynamoDB client = AmazonDynamoDBClientBuilder.standard().build();
DynamoDB dynamoDB = new DynamoDB(client);
Table table = dynamoDB.getTable("WeatherData");
TableDescription tableDesc = table.describe();
Iterator gsiIter = tableDesc.getGlobalSecondaryIndexes().iterator();
while (gsiIter.hasNext()) {
GlobalSecondaryIndexDescription gsiDesc = gsiIter.next();
System.out.println("Info for index "
+ gsiDesc.getIndexName() + ":");
Iterator kseIter = gsiDesc.getKeySchema().iterator();
while (kseIter.hasNext()) {
KeySchemaElement kse = kseIter.next();
System.out.printf("\t%s: %s\n", kse.getAttributeName(), kse.getKeyType());
}
Projection projection = gsiDesc.getProjection();
System.out.println("\tThe projection type is: "
+ projection.getProjectionType());
if (projection.getProjectionType().toString().equals("INCLUDE")) {
System.out.println("\t\tThe non-key projected attributes are: "
+ projection.getNonKeyAttributes());
}
}
```
## Abfragen eines globalen sekundären Indexes
Sie können `Query` für einen globalen sekundären Index genauso nutzen, wie Sie `Query` für eine Tabelle nutzen. Sie müssen den Indexnamen, die Abfragekriterien für den Indexpartitionsschlüssel und Sortierschlüssel (falls vorhanden) und die Attribute angeben, die Sie zurückgeben möchten. In diesem Beispiel ist der Index `PrecipIndex`, der über den Partitionsschlüssel `Date` und den Sortierschlüssel `Precipitation` verfügt. Die Indexabfrage gibt alle Wetterdaten für ein bestimmtes Datum zurück, in denen der Niederschlag größer als Null ist.
Im Folgenden werden die Schritte beschrieben, um einen globalen sekundären Index mithilfe der Document API abzufragen. AWS SDK für Java
1. Erstellen Sie eine Instance der `DynamoDB`-Klasse.
1. Erstellen Sie eine Instance der `Table`-Klasse, um den Index darzustellen, mit dem Sie arbeiten möchten.
1. Erstellen Sie für den Index, den Sie abfragen möchten, eine Instance der `Index`-Klasse.
1. Rufen Sie die `query`-Methode für das `Index`-Objekt auf.
Der Attributname `Date` ist ein DynamoDB-reserviertes Wort. Daher müssen Sie einen Ausdrucksattributnamen als Platzhalter in dem `KeyConditionExpression` verwenden.
Im folgenden Java-Codebeispiel werden die vorherigen Schritte veranschaulicht.
**Example**
```
AmazonDynamoDB client = AmazonDynamoDBClientBuilder.standard().build();
DynamoDB dynamoDB = new DynamoDB(client);
Table table = dynamoDB.getTable("WeatherData");
Index index = table.getIndex("PrecipIndex");
QuerySpec spec = new QuerySpec()
.withKeyConditionExpression("#d = :v_date and Precipitation = :v_precip")
.withNameMap(new NameMap()
.with("#d", "Date"))
.withValueMap(new ValueMap()
.withString(":v_date","2013-08-10")
.withNumber(":v_precip",0));
ItemCollection items = index.query(spec);
Iterator- iter = items.iterator();
while (iter.hasNext()) {
System.out.println(iter.next().toJSONPretty());
}
```
# Beispiel: Globale Sekundärindizes mithilfe der AWS SDK für Java Dokument-API
Das folgende Java-Codebeispiel zeigt, wie Sie mit globalen sekundären Indizes arbeiten. Das Beispiel erstellt eine Tabelle mit dem Namen `Issues`, die in einem einfachen Fehlerüberwachungssystem für Softwareentwicklung verwendet werden könnte. Der Partitionsschlüssel ist `IssueId` und der Sortierschlüssel `Title`. Es gibt drei globale sekundäre Indizes in dieser Tabelle:
+ `CreateDateIndex` – Der Partitionsschlüssel ist `CreateDate` und der Sortierschlüssel `IssueId`. Zusätzlich zu den Tabellenschlüsseln werden die Attribute `Description` und `Status` in den Index projiziert.
+ `TitleIndex` – Der Partitionsschlüssel ist `Title` und der Sortierschlüssel `IssueId`. Keine anderen Attribute als die Tabellenschlüssel werden in den Index projiziert.
+ `DueDateIndex` — Der Partitionsschlüssel ist `DueDate`. Ein Sortierschlüssel ist nicht vorhanden.) Alle Tabellenattribute werden in den Index projiziert.
Nachdem die `Issues`-Tabelle erstellt wurde, lädt das Programm die Tabelle mit Daten, die Software-Fehlerberichte darstellen. Anschließend werden die Daten mithilfe der globalen sekundären Indizes abgefragt. Schließlich löscht das Programm die `Issues`-Tabelle.
step-by-stepAnweisungen zum Testen des folgenden Beispiels finden Sie unter[Java-Codebeispiele](CodeSamples.Java.md).
**Example**
```
package com.amazonaws.codesamples.document;
import java.util.ArrayList;
import java.util.Iterator;
import com.amazonaws.services.dynamodbv2.AmazonDynamoDB;
import com.amazonaws.services.dynamodbv2.AmazonDynamoDBClientBuilder;
import com.amazonaws.services.dynamodbv2.document.DynamoDB;
import com.amazonaws.services.dynamodbv2.document.Index;
import com.amazonaws.services.dynamodbv2.document.Item;
import com.amazonaws.services.dynamodbv2.document.ItemCollection;
import com.amazonaws.services.dynamodbv2.document.QueryOutcome;
import com.amazonaws.services.dynamodbv2.document.Table;
import com.amazonaws.services.dynamodbv2.document.spec.QuerySpec;
import com.amazonaws.services.dynamodbv2.document.utils.ValueMap;
import com.amazonaws.services.dynamodbv2.model.AttributeDefinition;
import com.amazonaws.services.dynamodbv2.model.CreateTableRequest;
import com.amazonaws.services.dynamodbv2.model.GlobalSecondaryIndex;
import com.amazonaws.services.dynamodbv2.model.KeySchemaElement;
import com.amazonaws.services.dynamodbv2.model.KeyType;
import com.amazonaws.services.dynamodbv2.model.Projection;
import com.amazonaws.services.dynamodbv2.model.ProvisionedThroughput;
public class DocumentAPIGlobalSecondaryIndexExample {
static AmazonDynamoDB client = AmazonDynamoDBClientBuilder.standard().build();
static DynamoDB dynamoDB = new DynamoDB(client);
public static String tableName = "Issues";
public static void main(String[] args) throws Exception {
createTable();
loadData();
queryIndex("CreateDateIndex");
queryIndex("TitleIndex");
queryIndex("DueDateIndex");
deleteTable(tableName);
}
public static void createTable() {
// Attribute definitions
ArrayList attributeDefinitions = new ArrayList();
attributeDefinitions.add(new AttributeDefinition().withAttributeName("IssueId").withAttributeType("S"));
attributeDefinitions.add(new AttributeDefinition().withAttributeName("Title").withAttributeType("S"));
attributeDefinitions.add(new AttributeDefinition().withAttributeName("CreateDate").withAttributeType("S"));
attributeDefinitions.add(new AttributeDefinition().withAttributeName("DueDate").withAttributeType("S"));
// Key schema for table
ArrayList tableKeySchema = new ArrayList();
tableKeySchema.add(new KeySchemaElement().withAttributeName("IssueId").withKeyType(KeyType.HASH)); // Partition
// key
tableKeySchema.add(new KeySchemaElement().withAttributeName("Title").withKeyType(KeyType.RANGE)); // Sort
// key
// Initial provisioned throughput settings for the indexes
ProvisionedThroughput ptIndex = new ProvisionedThroughput().withReadCapacityUnits(1L)
.withWriteCapacityUnits(1L);
// CreateDateIndex
GlobalSecondaryIndex createDateIndex = new GlobalSecondaryIndex().withIndexName("CreateDateIndex")
.withProvisionedThroughput(ptIndex)
.withKeySchema(new KeySchemaElement().withAttributeName("CreateDate").withKeyType(KeyType.HASH), // Partition
// key
new KeySchemaElement().withAttributeName("IssueId").withKeyType(KeyType.RANGE)) // Sort
// key
.withProjection(
new Projection().withProjectionType("INCLUDE").withNonKeyAttributes("Description", "Status"));
// TitleIndex
GlobalSecondaryIndex titleIndex = new GlobalSecondaryIndex().withIndexName("TitleIndex")
.withProvisionedThroughput(ptIndex)
.withKeySchema(new KeySchemaElement().withAttributeName("Title").withKeyType(KeyType.HASH), // Partition
// key
new KeySchemaElement().withAttributeName("IssueId").withKeyType(KeyType.RANGE)) // Sort
// key
.withProjection(new Projection().withProjectionType("KEYS_ONLY"));
// DueDateIndex
GlobalSecondaryIndex dueDateIndex = new GlobalSecondaryIndex().withIndexName("DueDateIndex")
.withProvisionedThroughput(ptIndex)
.withKeySchema(new KeySchemaElement().withAttributeName("DueDate").withKeyType(KeyType.HASH)) // Partition
// key
.withProjection(new Projection().withProjectionType("ALL"));
CreateTableRequest createTableRequest = new CreateTableRequest().withTableName(tableName)
.withProvisionedThroughput(
new ProvisionedThroughput().withReadCapacityUnits((long) 1).withWriteCapacityUnits((long) 1))
.withAttributeDefinitions(attributeDefinitions).withKeySchema(tableKeySchema)
.withGlobalSecondaryIndexes(createDateIndex, titleIndex, dueDateIndex);
System.out.println("Creating table " + tableName + "...");
dynamoDB.createTable(createTableRequest);
// Wait for table to become active
System.out.println("Waiting for " + tableName + " to become ACTIVE...");
try {
Table table = dynamoDB.getTable(tableName);
table.waitForActive();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
public static void queryIndex(String indexName) {
Table table = dynamoDB.getTable(tableName);
System.out.println("\n***********************************************************\n");
System.out.print("Querying index " + indexName + "...");
Index index = table.getIndex(indexName);
ItemCollection items = null;
QuerySpec querySpec = new QuerySpec();
if (indexName == "CreateDateIndex") {
System.out.println("Issues filed on 2013-11-01");
querySpec.withKeyConditionExpression("CreateDate = :v_date and begins_with(IssueId, :v_issue)")
.withValueMap(new ValueMap().withString(":v_date", "2013-11-01").withString(":v_issue", "A-"));
items = index.query(querySpec);
} else if (indexName == "TitleIndex") {
System.out.println("Compilation errors");
querySpec.withKeyConditionExpression("Title = :v_title and begins_with(IssueId, :v_issue)")
.withValueMap(
new ValueMap().withString(":v_title", "Compilation error").withString(":v_issue", "A-"));
items = index.query(querySpec);
} else if (indexName == "DueDateIndex") {
System.out.println("Items that are due on 2013-11-30");
querySpec.withKeyConditionExpression("DueDate = :v_date")
.withValueMap(new ValueMap().withString(":v_date", "2013-11-30"));
items = index.query(querySpec);
} else {
System.out.println("\nNo valid index name provided");
return;
}
Iterator
- iterator = items.iterator();
System.out.println("Query: printing results...");
while (iterator.hasNext()) {
System.out.println(iterator.next().toJSONPretty());
}
}
public static void deleteTable(String tableName) {
System.out.println("Deleting table " + tableName + "...");
Table table = dynamoDB.getTable(tableName);
table.delete();
// Wait for table to be deleted
System.out.println("Waiting for " + tableName + " to be deleted...");
try {
table.waitForDelete();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
public static void loadData() {
System.out.println("Loading data into table " + tableName + "...");
// IssueId, Title,
// Description,
// CreateDate, LastUpdateDate, DueDate,
// Priority, Status
putItem("A-101", "Compilation error", "Can't compile Project X - bad version number. What does this mean?",
"2013-11-01", "2013-11-02", "2013-11-10", 1, "Assigned");
putItem("A-102", "Can't read data file", "The main data file is missing, or the permissions are incorrect",
"2013-11-01", "2013-11-04", "2013-11-30", 2, "In progress");
putItem("A-103", "Test failure", "Functional test of Project X produces errors", "2013-11-01", "2013-11-02",
"2013-11-10", 1, "In progress");
putItem("A-104", "Compilation error", "Variable 'messageCount' was not initialized.", "2013-11-15",
"2013-11-16", "2013-11-30", 3, "Assigned");
putItem("A-105", "Network issue", "Can't ping IP address 127.0.0.1. Please fix this.", "2013-11-15",
"2013-11-16", "2013-11-19", 5, "Assigned");
}
public static void putItem(
String issueId, String title, String description, String createDate, String lastUpdateDate, String dueDate,
Integer priority, String status) {
Table table = dynamoDB.getTable(tableName);
Item item = new Item().withPrimaryKey("IssueId", issueId).withString("Title", title)
.withString("Description", description).withString("CreateDate", createDate)
.withString("LastUpdateDate", lastUpdateDate).withString("DueDate", dueDate)
.withNumber("Priority", priority).withString("Status", status);
table.putItem(item);
}
}
```
# Arbeiten mit globalen sekundären Indizes: .NET
Sie können die AWS SDK für .NET Low-Level-API verwenden, um eine Amazon DynamoDB-Tabelle mit einem oder mehreren globalen Sekundärindizes zu erstellen, die Indizes in der Tabelle zu beschreiben und Abfragen mithilfe der Indizes durchzuführen. Diese Operationen entsprechen den entsprechenden DynamoDB-Operationen. Weitere Informationen finden Sie in der [Amazon-DynamoDB-API-Referenz](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/).
Folgende sind die allgemeinen Schritte für Tabellenoperationen mithilfe der .NET-Low-Level-API.
1. Erstellen Sie eine Instance der `AmazonDynamoDBClient`-Klasse.
1. Stellen Sie den erforderlichen und optionalen Parameter für die Operation bereit, indem Sie die entsprechenden Anforderungsobjekte erstellen.
Erstellen Sie beispielsweise ein `CreateTableRequest`-Objekt, um eine Tabelle zu erstellen und ein `QueryRequest`-Objekt, um eine Tabelle oder einen Index abzufragen.
1. Rufen Sie die entsprechende Methode auf, die vom Client, den Sie im vorhergehenden Schritt erstellt haben, bereitgestellt wird.
**Topics**
+ [Erstellen einer Tabelle mit einem globalen sekundären Index](#GSILowLevelDotNet.CreateTableWithIndex)
+ [Beschreiben einer Tabelle mit einem globalen sekundären Index](#GSILowLevelDotNet.DescribeTableWithIndex)
+ [Abfragen eines globalen sekundären Indexes](#GSILowLevelDotNet.QueryAnIndex)
+ [Beispiel: Globale Sekundärindizes unter Verwendung der Low-Level-API AWS SDK für .NET](GSILowLevelDotNet.Example.md)
## Erstellen einer Tabelle mit einem globalen sekundären Index
Sie können globale sekundäre Indizes gleichzeitig mit der Tabelle erstellen. Zu diesem Zweck verwenden Sie `CreateTable` und geben Ihre Spezifikationen für ein oder mehrere globale sekundäre Indizes an. Das folgende C\$1-Codebeispiel erstellt eine Tabelle, die Informationen über Wetterdaten enthält. Der Partitionsschlüssel ist `Location` und der Sortierschlüssel `Date`. Ein globaler sekundärer Index mit Namen `PrecipIndex` ermöglicht einen schnellen Zugriff auf Niederschlagsdaten für verschiedene Standorte.
Im Folgenden werden die Schritte zum Erstellen einer Tabelle mit einem globalen sekundären Index mithilfe der .NET-Low-Level-API dargelegt.
1. Erstellen Sie eine Instance der `AmazonDynamoDBClient`-Klasse.
1. Erstellen Sie eine Instance der `CreateTableRequest`-Klasse, um die Anforderungsinformationen bereitzustellen.
Sie müssen den Tabellennamen, seinen zugehörigen Primärschlüssel und die Werte des bereitgestellten Durchsatzes angeben. Für den globalen sekundären Index müssen Sie den Indexnamen, seine Einstellungen des bereitgestellten Durchsatzes, die Attributdefinitionen für den Index, das Schlüsselschema für den Index und die Attributprojektion angeben.
1. Führen Sie die `CreateTable`-Methode aus, indem das Anforderungsobjekt als Parameter festgelegt wird.
Im folgenden C\$1-Codebeispiel werden die vorherigen Schritte veranschaulicht. Erstellt eine Tabelle (`WeatherData`) mit einem globalen und lokalen sekundären Index (`PrecipIndex`). Der Index-Partitionsschlüssel ist `Date` und der Sortierschlüssel `Precipitation`. Alle Tabellenattribute werden in den Index projiziert. Benutzer können diesen Index abfragen, um Wetterdaten für ein bestimmtes Datum abzurufen. Optional können diese nach Niederschlagsmenge sortiert werden.
Da es sich bei `Precipitation` um kein Schlüsselattribut für die Tabelle handelt, ist es nicht erforderlich. `WeatherData`-Elemente ohne `Precipitation` erscheinen jedoch nicht in `PrecipIndex`.
```
client = new AmazonDynamoDBClient();
string tableName = "WeatherData";
// Attribute definitions
var attributeDefinitions = new List()
{
{new AttributeDefinition{
AttributeName = "Location",
AttributeType = "S"}},
{new AttributeDefinition{
AttributeName = "Date",
AttributeType = "S"}},
{new AttributeDefinition(){
AttributeName = "Precipitation",
AttributeType = "N"}
}
};
// Table key schema
var tableKeySchema = new List()
{
{new KeySchemaElement {
AttributeName = "Location",
KeyType = "HASH"}}, //Partition key
{new KeySchemaElement {
AttributeName = "Date",
KeyType = "RANGE"} //Sort key
}
};
// PrecipIndex
var precipIndex = new GlobalSecondaryIndex
{
IndexName = "PrecipIndex",
ProvisionedThroughput = new ProvisionedThroughput
{
ReadCapacityUnits = (long)10,
WriteCapacityUnits = (long)1
},
Projection = new Projection { ProjectionType = "ALL" }
};
var indexKeySchema = new List {
{new KeySchemaElement { AttributeName = "Date", KeyType = "HASH"}}, //Partition key
{new KeySchemaElement{AttributeName = "Precipitation",KeyType = "RANGE"}} //Sort key
};
precipIndex.KeySchema = indexKeySchema;
CreateTableRequest createTableRequest = new CreateTableRequest
{
TableName = tableName,
ProvisionedThroughput = new ProvisionedThroughput
{
ReadCapacityUnits = (long)5,
WriteCapacityUnits = (long)1
},
AttributeDefinitions = attributeDefinitions,
KeySchema = tableKeySchema,
GlobalSecondaryIndexes = { precipIndex }
};
CreateTableResponse response = client.CreateTable(createTableRequest);
Console.WriteLine(response.CreateTableResult.TableDescription.TableName);
Console.WriteLine(response.CreateTableResult.TableDescription.TableStatus);
```
Sie müssen warten bis DynamoDB die Tabelle erstellt und den Tabellenstatus auf `ACTIVE` setzt. Im Anschluss können Sie die Daten in der Tabelle ablegen.
## Beschreiben einer Tabelle mit einem globalen sekundären Index
Um Informationen zu globalen sekundären Indizes in einer Tabelle zu erhalten, verwenden Sie `DescribeTable`. Sie können auf den Namen, das Schlüsselschema und die projizierten Attribute von jedem Index zugreifen.
Im Folgenden werden die Schritte zum Zugriff auf globale sekundäre Index-Informationen in einer Tabelle mithilfe der .NET-Low-Level-API dargelegt.
1. Erstellen Sie eine Instance der `AmazonDynamoDBClient`-Klasse.
1. Führen Sie die `describeTable`-Methode aus, indem das Anforderungsobjekt als Parameter festgelegt wird.
Erstellen Sie eine Instance der `DescribeTableRequest`-Klasse, um die Anforderungsinformationen bereitzustellen. Sie müssen den Tabellennamen angeben.
Im folgenden C\$1-Codebeispiel werden die vorherigen Schritte veranschaulicht.
**Example**
```
client = new AmazonDynamoDBClient();
string tableName = "WeatherData";
DescribeTableResponse response = client.DescribeTable(new DescribeTableRequest { TableName = tableName});
List globalSecondaryIndexes =
response.DescribeTableResult.Table.GlobalSecondaryIndexes;
// This code snippet will work for multiple indexes, even though
// there is only one index in this example.
foreach (GlobalSecondaryIndexDescription gsiDescription in globalSecondaryIndexes) {
Console.WriteLine("Info for index " + gsiDescription.IndexName + ":");
foreach (KeySchemaElement kse in gsiDescription.KeySchema) {
Console.WriteLine("\t" + kse.AttributeName + ": key type is " + kse.KeyType);
}
Projection projection = gsiDescription.Projection;
Console.WriteLine("\tThe projection type is: " + projection.ProjectionType);
if (projection.ProjectionType.ToString().Equals("INCLUDE")) {
Console.WriteLine("\t\tThe non-key projected attributes are: "
+ projection.NonKeyAttributes);
}
}
```
## Abfragen eines globalen sekundären Indexes
Sie können `Query` für einen globalen sekundären Index genauso nutzen, wie Sie `Query` für eine Tabelle nutzen. Sie müssen den Indexnamen, die Abfragekriterien für den Indexpartitionsschlüssel und Sortierschlüssel (falls vorhanden) und die Attribute angeben, die Sie zurückgeben möchten. In diesem Beispiel ist der Index `PrecipIndex`, der über den Partitionsschlüssel `Date` und den Sortierschlüssel `Precipitation` verfügt. Die Indexabfrage gibt alle Wetterdaten für ein bestimmtes Datum zurück, in denen der Niederschlag größer als Null ist.
Im Folgenden werden die Schritte zur Abfrage eines globalen sekundären Indizes mithilfe der .NET-Low-Level-API dargelegt.
1. Erstellen Sie eine Instance der `AmazonDynamoDBClient`-Klasse.
1. Erstellen Sie eine Instance der `QueryRequest`-Klasse, um die Anforderungsinformationen bereitzustellen.
1. Führen Sie die `query`-Methode aus, indem das Anforderungsobjekt als Parameter festgelegt wird.
Der Attributname `Date` ist ein DynamoDB-reserviertes Wort. Daher müssen Sie einen Ausdrucksattributnamen als Platzhalter in dem `KeyConditionExpression` verwenden.
Im folgenden C\$1-Codebeispiel werden die vorherigen Schritte veranschaulicht.
**Example**
```
client = new AmazonDynamoDBClient();
QueryRequest queryRequest = new QueryRequest
{
TableName = "WeatherData",
IndexName = "PrecipIndex",
KeyConditionExpression = "#dt = :v_date and Precipitation > :v_precip",
ExpressionAttributeNames = new Dictionary {
{"#dt", "Date"}
},
ExpressionAttributeValues = new Dictionary {
{":v_date", new AttributeValue { S = "2013-08-01" }},
{":v_precip", new AttributeValue { N = "0" }}
},
ScanIndexForward = true
};
var result = client.Query(queryRequest);
var items = result.Items;
foreach (var currentItem in items)
{
foreach (string attr in currentItem.Keys)
{
Console.Write(attr + "---> ");
if (attr == "Precipitation")
{
Console.WriteLine(currentItem[attr].N);
}
else
{
Console.WriteLine(currentItem[attr].S);
}
}
Console.WriteLine();
}
```
# Beispiel: Globale Sekundärindizes unter Verwendung der Low-Level-API AWS SDK für .NET
Das folgende C\$1-Codebeispiel zeigt, wie Sie mit globalen sekundären Indizes arbeiten. Das Beispiel erstellt eine Tabelle mit dem Namen `Issues`, die in einem einfachen Fehlerüberwachungssystem für Softwareentwicklung verwendet werden könnte. Der Partitionsschlüssel ist `IssueId` und der Sortierschlüssel `Title`. Es gibt drei globale sekundäre Indizes in dieser Tabelle:
+ `CreateDateIndex` – Der Partitionsschlüssel ist `CreateDate` und der Sortierschlüssel `IssueId`. Zusätzlich zu den Tabellenschlüsseln werden die Attribute `Description` und `Status` in den Index projiziert.
+ `TitleIndex` – Der Partitionsschlüssel ist `Title` und der Sortierschlüssel `IssueId`. Keine anderen Attribute als die Tabellenschlüssel werden in den Index projiziert.
+ `DueDateIndex` — Der Partitionsschlüssel ist `DueDate`. Ein Sortierschlüssel ist nicht vorhanden.) Alle Tabellenattribute werden in den Index projiziert.
Nachdem die `Issues`-Tabelle erstellt wurde, lädt das Programm die Tabelle mit Daten, die Software-Fehlerberichte darstellen. Anschließend werden die Daten mithilfe der globalen sekundären Indizes abgefragt. Schließlich löscht das Programm die `Issues`-Tabelle.
step-by-stepAnweisungen zum Testen des folgenden Beispiels finden Sie unter. [.NET-Codebeispiele](CodeSamples.DotNet.md)
**Example**
```
using System;
using System.Collections.Generic;
using System.Linq;
using Amazon.DynamoDBv2;
using Amazon.DynamoDBv2.DataModel;
using Amazon.DynamoDBv2.DocumentModel;
using Amazon.DynamoDBv2.Model;
using Amazon.Runtime;
using Amazon.SecurityToken;
namespace com.amazonaws.codesamples
{
class LowLevelGlobalSecondaryIndexExample
{
private static AmazonDynamoDBClient client = new AmazonDynamoDBClient();
public static String tableName = "Issues";
public static void Main(string[] args)
{
CreateTable();
LoadData();
QueryIndex("CreateDateIndex");
QueryIndex("TitleIndex");
QueryIndex("DueDateIndex");
DeleteTable(tableName);
Console.WriteLine("To continue, press enter");
Console.Read();
}
private static void CreateTable()
{
// Attribute definitions
var attributeDefinitions = new List()
{
{new AttributeDefinition {
AttributeName = "IssueId", AttributeType = "S"
}},
{new AttributeDefinition {
AttributeName = "Title", AttributeType = "S"
}},
{new AttributeDefinition {
AttributeName = "CreateDate", AttributeType = "S"
}},
{new AttributeDefinition {
AttributeName = "DueDate", AttributeType = "S"
}}
};
// Key schema for table
var tableKeySchema = new List() {
{
new KeySchemaElement {
AttributeName= "IssueId",
KeyType = "HASH" //Partition key
}
},
{
new KeySchemaElement {
AttributeName = "Title",
KeyType = "RANGE" //Sort key
}
}
};
// Initial provisioned throughput settings for the indexes
var ptIndex = new ProvisionedThroughput
{
ReadCapacityUnits = 1L,
WriteCapacityUnits = 1L
};
// CreateDateIndex
var createDateIndex = new GlobalSecondaryIndex()
{
IndexName = "CreateDateIndex",
ProvisionedThroughput = ptIndex,
KeySchema = {
new KeySchemaElement {
AttributeName = "CreateDate", KeyType = "HASH" //Partition key
},
new KeySchemaElement {
AttributeName = "IssueId", KeyType = "RANGE" //Sort key
}
},
Projection = new Projection
{
ProjectionType = "INCLUDE",
NonKeyAttributes = {
"Description", "Status"
}
}
};
// TitleIndex
var titleIndex = new GlobalSecondaryIndex()
{
IndexName = "TitleIndex",
ProvisionedThroughput = ptIndex,
KeySchema = {
new KeySchemaElement {
AttributeName = "Title", KeyType = "HASH" //Partition key
},
new KeySchemaElement {
AttributeName = "IssueId", KeyType = "RANGE" //Sort key
}
},
Projection = new Projection
{
ProjectionType = "KEYS_ONLY"
}
};
// DueDateIndex
var dueDateIndex = new GlobalSecondaryIndex()
{
IndexName = "DueDateIndex",
ProvisionedThroughput = ptIndex,
KeySchema = {
new KeySchemaElement {
AttributeName = "DueDate",
KeyType = "HASH" //Partition key
}
},
Projection = new Projection
{
ProjectionType = "ALL"
}
};
var createTableRequest = new CreateTableRequest
{
TableName = tableName,
ProvisionedThroughput = new ProvisionedThroughput
{
ReadCapacityUnits = (long)1,
WriteCapacityUnits = (long)1
},
AttributeDefinitions = attributeDefinitions,
KeySchema = tableKeySchema,
GlobalSecondaryIndexes = {
createDateIndex, titleIndex, dueDateIndex
}
};
Console.WriteLine("Creating table " + tableName + "...");
client.CreateTable(createTableRequest);
WaitUntilTableReady(tableName);
}
private static void LoadData()
{
Console.WriteLine("Loading data into table " + tableName + "...");
// IssueId, Title,
// Description,
// CreateDate, LastUpdateDate, DueDate,
// Priority, Status
putItem("A-101", "Compilation error",
"Can't compile Project X - bad version number. What does this mean?",
"2013-11-01", "2013-11-02", "2013-11-10",
1, "Assigned");
putItem("A-102", "Can't read data file",
"The main data file is missing, or the permissions are incorrect",
"2013-11-01", "2013-11-04", "2013-11-30",
2, "In progress");
putItem("A-103", "Test failure",
"Functional test of Project X produces errors",
"2013-11-01", "2013-11-02", "2013-11-10",
1, "In progress");
putItem("A-104", "Compilation error",
"Variable 'messageCount' was not initialized.",
"2013-11-15", "2013-11-16", "2013-11-30",
3, "Assigned");
putItem("A-105", "Network issue",
"Can't ping IP address 127.0.0.1. Please fix this.",
"2013-11-15", "2013-11-16", "2013-11-19",
5, "Assigned");
}
private static void putItem(
String issueId, String title,
String description,
String createDate, String lastUpdateDate, String dueDate,
Int32 priority, String status)
{
Dictionary item = new Dictionary();
item.Add("IssueId", new AttributeValue
{
S = issueId
});
item.Add("Title", new AttributeValue
{
S = title
});
item.Add("Description", new AttributeValue
{
S = description
});
item.Add("CreateDate", new AttributeValue
{
S = createDate
});
item.Add("LastUpdateDate", new AttributeValue
{
S = lastUpdateDate
});
item.Add("DueDate", new AttributeValue
{
S = dueDate
});
item.Add("Priority", new AttributeValue
{
N = priority.ToString()
});
item.Add("Status", new AttributeValue
{
S = status
});
try
{
client.PutItem(new PutItemRequest
{
TableName = tableName,
Item = item
});
}
catch (Exception e)
{
Console.WriteLine(e.ToString());
}
}
private static void QueryIndex(string indexName)
{
Console.WriteLine
("\n***********************************************************\n");
Console.WriteLine("Querying index " + indexName + "...");
QueryRequest queryRequest = new QueryRequest
{
TableName = tableName,
IndexName = indexName,
ScanIndexForward = true
};
String keyConditionExpression;
Dictionary expressionAttributeValues = new Dictionary();
if (indexName == "CreateDateIndex")
{
Console.WriteLine("Issues filed on 2013-11-01\n");
keyConditionExpression = "CreateDate = :v_date and begins_with(IssueId, :v_issue)";
expressionAttributeValues.Add(":v_date", new AttributeValue
{
S = "2013-11-01"
});
expressionAttributeValues.Add(":v_issue", new AttributeValue
{
S = "A-"
});
}
else if (indexName == "TitleIndex")
{
Console.WriteLine("Compilation errors\n");
keyConditionExpression = "Title = :v_title and begins_with(IssueId, :v_issue)";
expressionAttributeValues.Add(":v_title", new AttributeValue
{
S = "Compilation error"
});
expressionAttributeValues.Add(":v_issue", new AttributeValue
{
S = "A-"
});
// Select
queryRequest.Select = "ALL_PROJECTED_ATTRIBUTES";
}
else if (indexName == "DueDateIndex")
{
Console.WriteLine("Items that are due on 2013-11-30\n");
keyConditionExpression = "DueDate = :v_date";
expressionAttributeValues.Add(":v_date", new AttributeValue
{
S = "2013-11-30"
});
// Select
queryRequest.Select = "ALL_PROJECTED_ATTRIBUTES";
}
else
{
Console.WriteLine("\nNo valid index name provided");
return;
}
queryRequest.KeyConditionExpression = keyConditionExpression;
queryRequest.ExpressionAttributeValues = expressionAttributeValues;
var result = client.Query(queryRequest);
var items = result.Items;
foreach (var currentItem in items)
{
foreach (string attr in currentItem.Keys)
{
if (attr == "Priority")
{
Console.WriteLine(attr + "---> " + currentItem[attr].N);
}
else
{
Console.WriteLine(attr + "---> " + currentItem[attr].S);
}
}
Console.WriteLine();
}
}
private static void DeleteTable(string tableName)
{
Console.WriteLine("Deleting table " + tableName + "...");
client.DeleteTable(new DeleteTableRequest
{
TableName = tableName
});
WaitForTableToBeDeleted(tableName);
}
private static void WaitUntilTableReady(string tableName)
{
string status = null;
// Let us wait until table is created. Call DescribeTable.
do
{
System.Threading.Thread.Sleep(5000); // Wait 5 seconds.
try
{
var res = client.DescribeTable(new DescribeTableRequest
{
TableName = tableName
});
Console.WriteLine("Table name: {0}, status: {1}",
res.Table.TableName,
res.Table.TableStatus);
status = res.Table.TableStatus;
}
catch (ResourceNotFoundException)
{
// DescribeTable is eventually consistent. So you might
// get resource not found. So we handle the potential exception.
}
} while (status != "ACTIVE");
}
private static void WaitForTableToBeDeleted(string tableName)
{
bool tablePresent = true;
while (tablePresent)
{
System.Threading.Thread.Sleep(5000); // Wait 5 seconds.
try
{
var res = client.DescribeTable(new DescribeTableRequest
{
TableName = tableName
});
Console.WriteLine("Table name: {0}, status: {1}",
res.Table.TableName,
res.Table.TableStatus);
}
catch (ResourceNotFoundException)
{
tablePresent = false;
}
}
}
}
}
```
# Arbeiten mit globalen sekundären Indizes in DynamoDB mithilfe der AWS CLI
Sie können die AWS CLI zum Erstellen einer Amazon-DynamoDB-Tabelle mit einem oder mehreren globalen sekundären Indizes, zum Beschreiben der Indizes in der Tabelle und zur Ausführung von Abfragen mithilfe des Indizes, verwenden.
**Topics**
+ [Erstellen einer Tabelle mit einem globalen sekundären Index](#GCICli.CreateTableWithIndex)
+ [Hinzufügen eines globalen sekundären Indexes zu einer vorhandenen Tabelle](#GCICli.CreateIndexAfterTable)
+ [Beschreiben einer Tabelle mit einem globalen sekundären Index](#GCICli.DescribeTableWithIndex)
+ [Abfragen eines globalen sekundären Indexes](#GCICli.QueryAnIndex)
## Erstellen einer Tabelle mit einem globalen sekundären Index
Globale sekundäre Indizes können gleichzeitig mit der Tabelle erstellt werden. Zu diesem Zweck verwenden Sie den `create-table`-Parameter und geben Ihre Spezifikationen für ein oder mehrere globale sekundäre Indizes an. Im folgenden Beispiel wird eine Tabelle mit dem Namen `GameScores` mit einem globalen sekundären Index `GameTitleIndex` erstellt. Die Basistabelle hat einen Partitionsschlüssel von `UserId` und einen Sortierschlüssel von `GameTitle`, mit dem Sie effizient die beste Punktzahl eines einzelnen Benutzers für ein bestimmtes Spiel finden können, während die GSI einen Partitionsschlüssel von `GameTitle` und einen Sortierschlüssel von `TopScore` hat, mit dem Sie finden Sie schnell die höchste Gesamtpunktzahl für ein bestimmtes Spiel.
```
aws dynamodb create-table \
--table-name GameScores \
--attribute-definitions AttributeName=UserId,AttributeType=S \
AttributeName=GameTitle,AttributeType=S \
AttributeName=TopScore,AttributeType=N \
--key-schema AttributeName=UserId,KeyType=HASH \
AttributeName=GameTitle,KeyType=RANGE \
--provisioned-throughput ReadCapacityUnits=10,WriteCapacityUnits=5 \
--global-secondary-indexes \
"[
{
\"IndexName\": \"GameTitleIndex\",
\"KeySchema\": [{\"AttributeName\":\"GameTitle\",\"KeyType\":\"HASH\"},
{\"AttributeName\":\"TopScore\",\"KeyType\":\"RANGE\"}],
\"Projection\":{
\"ProjectionType\":\"INCLUDE\",
\"NonKeyAttributes\":[\"UserId\"]
},
\"ProvisionedThroughput\": {
\"ReadCapacityUnits\": 10,
\"WriteCapacityUnits\": 5
}
}
]"
```
Sie müssen warten bis DynamoDB die Tabelle erstellt und den Tabellenstatus auf `ACTIVE` setzt. Im Anschluss können Sie die Daten in der Tabelle ablegen. Mit [describe-table](https://docs.aws.amazon.com/cli/latest/reference/dynamodb/describe-table.html) können Sie den Status der Tabellenerstellung ermitteln.
## Hinzufügen eines globalen sekundären Indexes zu einer vorhandenen Tabelle
Globale sekundäre Indizes können auch nach der Tabellenerstellung hinzugefügt oder geändert werden. Zu diesem Zweck verwenden Sie den `update-table`-Parameter und geben Ihre Spezifikationen für ein oder mehrere globale sekundäre Indizes an. Im folgenden Beispiel wird dasselbe Schema wie im vorherigen Beispiel verwendet, es wird jedoch davon ausgegangen, dass die Tabelle bereits erstellt wurde und die GSI später hinzugefügt wird.
```
aws dynamodb update-table \
--table-name GameScores \
--attribute-definitions AttributeName=TopScore,AttributeType=N \
--global-secondary-index-updates \
"[
{
\"Create\": {
\"IndexName\": \"GameTitleIndex\",
\"KeySchema\": [{\"AttributeName\":\"GameTitle\",\"KeyType\":\"HASH\"},
{\"AttributeName\":\"TopScore\",\"KeyType\":\"RANGE\"}],
\"Projection\":{
\"ProjectionType\":\"INCLUDE\",
\"NonKeyAttributes\":[\"UserId\"]
}
}
}
]"
```
## Beschreiben einer Tabelle mit einem globalen sekundären Index
Um Informationen zu globalen sekundären Indizes in einer Tabelle zu erhalten, verwenden Sie den Parameter `describe-table`. Sie können auf den Namen, das Schlüsselschema und die projizierten Attribute von jedem Index zugreifen.
```
aws dynamodb describe-table --table-name GameScores
```
## Abfragen eines globalen sekundären Indexes
Sie können die Operation `query` für einen globalen sekundären Index genauso nutzen, wie Sie `query` für eine Tabelle nutzen. Sie müssen den Indexnamen, die Abfragekriterien für den Indexsortierschlüssel und die Attribute angeben, die Sie zurückgeben möchten. In diesem Beispiel ist der Index `GameTitleIndex` und der Indexsortierschlüssel `GameTitle`.
Die einzigen zurückgegebenen Attribute sind die, die in den Index projiziert wurden. Sie könnten diese Abfrage ändern, um auch Nicht-Schlüsselattribute auszuwählen, aber dies würde eine Tabellenabrufaktivität erfordern, die relativ teuer ist. Weitere Informationen zum Abrufen von Tabellen finden Sie unter [Attributprojektionen](GSI.md#GSI.Projections).
```
aws dynamodb query --table-name GameScores\
--index-name GameTitleIndex \
--key-condition-expression "GameTitle = :v_game" \
--expression-attribute-values '{":v_game":{"S":"Alien Adventure"} }'
```
# Lokale sekundäre Indizes
Einige Anwendungen müssen Daten nur mithilfe der Basistabelle des Primärschlüssels abfragen. Es kann jedoch Situationen geben, in denen ein alternativer Sortierschlüssel hilfreich wäre. Um Ihrer Anwendung verschiedene Sortierschlüssel zur Auswahl anzubieten, können Sie einen oder mehrere lokale sekundäre Indizes in einer Amazon-DynamoDB-Tabelle erstellen und `Query`- oder `Scan`-Anforderungen für diese Indizes generieren.
**Topics**
+ [Schritt 6: Verwenden eines lokalenx sekundären Indexes](#LSI.Scenario)
+ [Attributprojektionen](#LSI.Projections)
+ [Erstellen eines lokalen sekundären Index](#LSI.Creating)
+ [Lesen von Daten aus einem lokalen sekundären Index](#LSI.Reading)
+ [Schreibvorgänge und lokale sekundäre Indizes](#LSI.Writes)
+ [Überlegungen im Hinblick auf die bereitgestellte Durchsatzkapazität für lokale sekundäre Indizes](#LSI.ThroughputConsiderations)
+ [Speicherüberlegungen für lokale sekundäre Indizes](#LSI.StorageConsiderations)
+ [Elementauflistungen in lokalen sekundären Indizes](#LSI.ItemCollections)
+ [Arbeiten mit lokalen sekundären Indizes: Java](LSIJavaDocumentAPI.md)
+ [Arbeiten mit lokalen sekundären Indizes: .NET](LSILowLevelDotNet.md)
+ [Arbeiten mit lokalen sekundären Indizes in der DynamoDB-AWS CLI](LCICli.md)
## Schritt 6: Verwenden eines lokalenx sekundären Indexes
Betrachten Sie als Beispiel die `Thread`-Tabelle. Diese Tabelle ist nützlich für eine Anwendung wie [AWS -Diskussionsforen](https://forums.aws.amazon.com/). Das folgende Diagramm zeigt, wie die Elemente in der Tabelle organisiert wären. (Es werden nicht alle Attribute angezeigt.)
![\[Thread-Tabelle mit einer Liste von Forumnamen, Themen, Uhrzeit des letzten Beitrags und Anzahl der Antworten.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/LSI_01.png)
DynamoDB speichert alle Elemente mit demselben Partitionsschlüsselwert fortlaufend. In diesem Beispiel könnte mit einem bestimmten `ForumName` eine `Query`-Operation sofort alle Threads für dieses Forum ermitteln. Innerhalb einer Gruppe von Elementen mit demselben Partitionsschlüsselwert werden die Elemente nach Sortierschlüsselwert sortiert. Wenn der Sortierschlüssel (`Subject`) in der Abfrage auch angegeben ist, kann DynamoDB die Ergebnisse, die zurückgegeben werden, einschränken und z. B. alle Threads im Forum „S3“ mit einem `Subject`, der mit „A“ beginnt, zurückgeben.
Einige Anforderungen erfordern komplexere Datenzugriffsmuster. Zum Beispiel:
+ Welche Forum-Threads erhalten die meisten Ansichten und Antworten?
+ Welcher Thread in einem bestimmten Forum enthält die meisten Nachrichten?
+ Wie viele Threads wurden in einem bestimmten Forum in einem angegebenen Zeitraum gepostet?
Um diese Fragen zu beantworten, würde die `Query`-Aktion nicht ausreichen. Stattdessen müssen Sie die gesamte Tabelle `Scan`. Bei einer Tabelle mit Millionen von Elementen würde dabei der bereitgestellte Lesedurchsatz größtenteils aufgebraucht und der Vorgang würde sehr lange dauern.
Sie können jedoch einen oder mehrere lokale sekundäre Indizes für Nicht-Schlüsselattribute angeben, z. B. `Replies` oder `LastPostDateTime`.
Ein *lokaler sekundärer Index* verwaltet einen alternativen Sortierschlüssel für einen bestimmten Partitionsschlüsselwert. Ein lokaler sekundärer Index enthält auch eine Kopie einiger oder aller Attribute aus seiner Basistabelle. Sie geben beim Erstellen der Tabelle an, welche Attribute in den lokalen sekundären Index projiziert werden. Die Daten in einem lokalen sekundären Index werden durch denselben Partitionsschlüssel strukturiert wie die Basistabelle, jedoch mit einem anderen Sortierschlüssel. Auf diese Weise können Sie in dieser anderen Dimension effizient auf Datenelemente zugreifen. Wenn Sie eine größere Abfrage- oder Scanflexibilität benötigen, können Sie bis zu fünf lokale sekundäre Indizes pro Tabelle erstellen.
Angenommen, eine Anwendung muss alle Threads ermitteln, die in den letzten drei Monaten in einem bestimmten Forum veröffentlicht wurden. Ohne lokalen sekundären Index müsste die Anwendung eine `Scan`-Aktion für die gesamte `Thread`-Tabelle ausführen und alle Beiträge, die nicht innerhalb des Zeitraums gepostet wurden, verwerfen. Mit einem lokalen sekundären Index könnte eine `Query`-Operation `LastPostDateTime` verwenden, um Daten schnell zu finden.
Das folgende Diagramm zeigt einen lokalen sekundären Index mit dem Namen `LastPostIndex`. Beachten Sie, dass der Partitionsschlüssel mit dem Schlüssel der `Thread`-Tabelle übereinstimmt, der Sortierschlüssel jedoch `LastPostDateTime` ist.
![\[LastPostIndex Tabelle mit einer Liste von Forennamen, Themen und der Zeit des letzten Beitrags.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/LSI_02.png)
Jeder lokale sekundäre Index muss die folgenden Bedingungen erfüllen:
+ Der Partitionsschlüssel ist mit dem Schlüssel der Basistabelle identisch.
+ Der Sortierschlüssel besteht aus genau einem skalaren Attribut.
+ Der Sortierschlüssel der Basistabelle wird in den Index projiziert, wo er als Nicht-Schlüsselattribut fungiert.
In diesem Beispiel lautet der Partitionsschlüssel `ForumName` und der Sortierschlüssel des lokalen sekundären Indexes lautet `LastPostDateTime`. Darüber hinaus wird der Sortierschlüsselwert der Basistabelle (in diesem Beispiel `Subject`) in den Index projiziert, ist jedoch kein Bestandteil des Indexschlüssels. Wenn eine Anwendung eine Liste basierend auf `ForumName` und `LastPostDateTime` benötigt, kann sie eine `Query`-Anforderung für `LastPostIndex` erstellen. Die Abfrageergebnisse sind nach `LastPostDateTime` sortiert und können in auf- oder absteigender Reihenfolge zurückgegeben werden. Die Abfrage kann auch Schlüsselbedingungen anwenden, z. B. nur Elemente zurückgeben mit einem `LastPostDateTime` innerhalb einer bestimmten Zeitspanne.
Jeder lokale sekundäre Index enthält automatisch die Partitions- und Sortierschlüssel der Basistabelle. Nicht-Schlüsselattribute können Sie optional in den Index projizieren. Wenn Sie den Index abfragen, kann DynamoDB diese projizierten Attribute effizient abrufen. Beim Abfragen eines lokalen sekundären Indizes können auch Attribute abgerufen werden, die *nicht* in den Index projiziert sind. DynamoDB ruft diese Attribute automatisch aus der Basistabelle ab, jedoch mit größerer Latenz und höheren Kosten für den bereitgestellten Durchsatz.
Für alle lokale sekundäre Indizes können Sie bis zu 10 GB Daten pro eindeutigem Partitionsschlüsselwert speichern. Diese Abbildung enthält alle Elemente in der Basistabelle sowie alle Elemente in den Indizes, die denselben Partitionsschlüsselwert haben. Weitere Informationen finden Sie unter [Elementauflistungen in lokalen sekundären Indizes](#LSI.ItemCollections).
## Attributprojektionen
Mit `LastPostIndex` könnte eine Anwendung `ForumName` und `LastPostDateTime` als Abfragekriterien verwenden. Um jedoch zusätzliche Attribute abzurufen, muss DynamoDB zusätzliche Lesevorgänge für die `Thread`-Tabelle ausführen. Diese zusätzlichen Lesevorgänge werden als *Abrufe* bezeichnet. Diese können die Gesamtgröße des bereitgestellten Durchsatzes, der für eine Abfrage erforderlich ist, erhöhen.
Angenommen, Sie möchten eine Webseite mit einer Liste aller Threads in „S3“ und der Anzahl der Antworten für jeden Thread füllen, sortiert nach der letzten Antwort, date/time beginnend mit der neuesten Antwort. Zum Auffüllen dieser Liste benötigen Sie die folgenden Attribute:
+ `Subject`
+ `Replies`
+ `LastPostDateTime`
Die beste Möglichkeit, diese Daten abzufragen und Abrufoperationen zu vermeiden, ist, das Attribut `Replies` aus der Tabelle in den lokalen sekundären Index zu projizieren, wie in diesem Diagramm dargestellt:
![\[LastPostIndex Tabelle mit einer Liste von Forennamen, Zeiten der letzten Beiträge, Themen und Antworten.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/LSI_03.png)
Eine *Projektion* ist der Satz von Attributen, die aus einer Tabelle in einen sekundären Index kopiert werden. Der Partitionsschlüssel und der Sortierschlüssel der Tabelle werden immer in den Index projiziert. Sie können andere Attribute projizieren, um die Abfrageanforderungen Ihrer Anwendung zu unterstützen. Wenn Sie einen Index abfragen, kann Amazon DynamoDB auf jedes Attribut in der Projektion zugreifen, als ob sich diese Attribute in einer eigenen Tabelle befinden.
Wenn Sie einen sekundären Index erstellen, müssen Sie die Attribute angeben, die in den Index projiziert werden. DynamoDB bietet hierfür drei verschiedene Optionen:
+ *KEYS\$1ONLY* – Jeder Eintrag im Index besteht nur aus dem Tabellenpartitionsschlüssel und Sortierschlüsselwerten, sowie den Indexschlüsselwerten. Die Option `KEYS_ONLY` führt zu dem kleinstmöglichen sekundären Index.
+ *INCLUDE* – Zusätzlich zu den in `KEYS_ONLY` beschriebenen Attributen, enthält der sekundäre Index andere Nicht-Schlüsselattribute, die Sie angeben.
+ *ALL* – Der sekundäre Index enthält alle Attribute der Quelltabelle. Da alle Tabellendaten im Index dupliziert werden, wird führt eine `ALL`-Projektion zu dem größtmöglichen sekundären Index.
Im vorherigen Diagramm wird das Nicht-Schlüsselattribut in `Replies` in `LastPostIndex` projiziert. Eine Anwendung kann `LastPostIndex` anstelle der vollständigen `Thread`-Tabelle abfragen, um eine Webseite mi t`Subject`, `Replies` und `LastPostDateTime` auszufüllen. Wenn alle anderen Nicht-Schlüsselattribute abgefragt werden, muss DynamoDB diese Attribute aus der `Thread`-Tabelle abrufen.
Von der Anwendungsseite aus betrachtet, ist das Abrufen zusätzlicher Attribute aus der Basistabelle automatisch und transparent. Es muss keine Anwendungslogik umgeschrieben werden. Beachten Sie jedoch, dass dieses Abrufen den Leistungsvorteil, den ein lokaler sekundärer Index bietet, erheblich einschränken kann.
Wenn Sie die Attribute zum Projizieren in einen lokalen sekundären Index auswählen, müssen Sie die Differenz der Kosten des bereitgestellten Durchsatzes und der Speicherkosten berücksichtigen:
+ Wenn Sie nur auf wenige Attribute mit möglichst niedriger Latenz zugreifen müssen, erwägen Sie, nur diese Attribute in einen lokalen sekundären Index zu projizieren. Je kleiner der Index, desto geringer die Speicher- und somit die Schreibkosten. Wenn Sie Attribute gelegentlich abrufen müssen, können die Kosten für den bereitgestellten Durchsatz die längerfristigen Kosten für die Speicherung dieser Attribute aufwiegen.
+ Greift Ihre Anwendung häufig auf einige Nicht-Schlüsselattribute zu, sollten Sie erwägen, diese Attribute in einen lokalen sekundären Index zu projizieren. Die zusätzlichen Speicherkosten für den lokalen sekundären Index wiegen die Kosten für die Durchführung häufiger Tabellen-Scans auf.
+ Wenn Sie auf die meisten Nicht-Schlüsselattribute in regelmäßigen Abständen zugreifen müssen, können Sie diese Attribute – oder sogar die gesamte Basistabelle – in einen lokalen sekundären Index projizieren. Auf diese Weise erhalten Sie maximale Flexibilität und den niedrigsten Verbrauch des bereitgestellten Durchsatzes, da kein Abrufen erforderlich ist. Die Speicherkosten erhöhen oder verdoppeln sich allerdings sogar, wenn Sie alle Attribute projizieren.
+ Wenn Ihre Anwendung eine Tabelle selten abfragen, jedoch viele Schreibvorgänge oder Updates für die Daten in der Tabelle durchführen muss, erwägen Sie das Projizieren von *KEYS\$1ONLY*. Der wäre nur klein, stünde aber weiterhin bei Bedarf für Abfrageaktivitäten zur Verfügung.
## Erstellen eines lokalen sekundären Index
Um einen oder mehrere lokale sekundäre Indizes für eine Tabelle zu erstellen, verwenden Sie den `LocalSecondaryIndexes`-Parameter der Operation `CreateTable`. Lokale sekundäre Indizes für eine Tabelle werden erstellt, wenn die Tabelle erstellt wird. Wenn Sie eine Tabelle löschen, werden alle lokalen sekundären Indizes in dieser Tabelle ebenfalls gelöscht.
Sie müssen ein Nicht-Schlüsselattribut angeben, das als Sortierschlüssel des lokalen sekundären Indizes dient. Das Attribut, das Sie auswählen, muss ein skalarer `String`, `Number` oder `Binary` sein. Andere Skalar-, Dokument- und Satztypen sind nicht zulässig. Eine vollständige Liste der Datentypen finden Sie unter [Datentypen](HowItWorks.NamingRulesDataTypes.md#HowItWorks.DataTypes).
**Wichtig**
Für Tabellen mit lokalen sekundären Indizes besteht eine Größenbeschränkung von 10 GB pro Partitionsschlüsselwert. Eine Tabelle mit lokalem sekundärem Index kann eine beliebige Anzahl von Elementen speichern, solange die Gesamtgröße eines Partitionsschlüsselwerts 10 GB nicht überschreitet. Weitere Informationen finden Sie unter [Größenlimit der Elementauflistung](#LSI.ItemCollections.SizeLimit).
Sie können Attribute jeden Datentyps in einen lokalen sekundären Index projizieren. Dazu zählen skalare Werte, Dokumente und Sätze. Eine vollständige Liste der Datentypen finden Sie unter [Datentypen](HowItWorks.NamingRulesDataTypes.md#HowItWorks.DataTypes).
## Lesen von Daten aus einem lokalen sekundären Index
Sie können Elemente aus einem lokalen sekundären Index mit dem Befehl `Query` und `Scan` verwenden. Die `GetItem`- und `BatchGetItem`-Operationen können für einen lokalen sekundären Index nicht verwendet werden.
### Abfragen eines lokalen sekundären Indexes
In einer DynamoDB-Tabelle müssen der kombinierte Partitionsschlüsselwert und der Sortierschlüsselwert für jedes Element eindeutig sein. In einem lokalen sekundären Index müssen die Sortierschlüsselwerte für einen bestimmten Partitionsschlüsselwert jedoch nicht eindeutig sein. Wenn mehrere Elemente mit demselben Sortierschlüsselwert im lokalen sekundären Index vorhanden sind, gibt eine `Query`-Operation alle Elemente mit demselben Partitionsschlüsselwert zurück. In der Antwort werden die übereinstimmenden Elemente nicht in einer bestimmten Reihenfolge zurückgegeben.
Sie können einen lokalen sekundären Index mit Eventually-Consistent- oder Strongly-Consistent-Lesevorgängen abfragen. Um die Art der Konsistenz anzugeben, verwenden Sie den Parameter `ConsistentRead` der `Query`-Operation. Bei einem Strongly-Consistent-Lesevorgang von einem lokalen sekundären Index werden immer die zuletzt aktualisierten Werte zurückgegeben. Wenn die Abfrage weitere Attribute aus der Basistabelle abrufen muss, sind diese Attribute in Bezug auf den Index konsistent.
**Example**
Betrachten Sie die folgenden Daten, die von einer `Query`-Operation zum Abfragen von Daten aus den Diskussionsbeiträgen in einem bestimmten Forum zurückgegeben werden:
```
{
"TableName": "Thread",
"IndexName": "LastPostIndex",
"ConsistentRead": false,
"ProjectionExpression": "Subject, LastPostDateTime, Replies, Tags",
"KeyConditionExpression":
"ForumName = :v_forum and LastPostDateTime between :v_start and :v_end",
"ExpressionAttributeValues": {
":v_start": {"S": "2015-08-31T00:00:00.000Z"},
":v_end": {"S": "2015-11-31T00:00:00.000Z"},
":v_forum": {"S": "EC2"}
}
}
```
Vorgänge in dieser Abfrage:
+ DynamoDB greift auf `LastPostIndex` mit dem Partitionsschlüssel `ForumName` zu, um die Indexelemente für „EC2“ zu ermitteln. Alle Indexelemente mit diesem Schlüssel werden nebeneinander gespeichert, um ein schnelles Abrufen zu ermöglichen.
+ In diesem Forum verwendet DynamoDB den Index, um die Schlüssel, die der angegebenen `LastPostDateTime`-Bedingung entsprechen, zu suchen.
+ Da das Attribut `Replies` in den Index projiziert wird, kann DynamoDB dieses Attribut abrufen, ohne zusätzlichen bereitgestellten Durchsatz zu verbrauchen.
+ Das Attribut `Tags` wird nicht in den Index projiziert, sodass DynamoDB auf die `Thread`-Tabelle zugreifen muss, um dieses Attribut abzurufen.
+ Die Ergebnisse werden sortiert nach `LastPostDateTime`. Die Indexeinträge sind nach Partitionsschlüsselwert und dann nach Sortierschlüsselwert sortiert und `Query` gibt sie in der Reihenfolge, in der sie gespeichert werden, zurück. (Sie können den Parameter `ScanIndexForward` verwenden, um die Ergebnisse in absteigender Reihenfolge anzuzeigen.)
Da das Attribut `Tags` nicht in den lokalen sekundären Index projiziert wird, muss DynamoDB zusätzliche Lesekapazitätseinheiten verbrauchen, um dieses Attribut aus der Basistabelle abzurufen. Wenn Sie diese Abfrage häufig ausführen müssen, sollten Sie `Tags` in `LastPostIndex` verwenden, um das Abrufen von der Basistabelle zu vermeiden. Wenn Sie jedoch nur gelegentlich auf `Tags` zugreifen müssen, lohnen sich die zusätzlichen Speicherkosten für das Projizieren von `Tags` in den Index möglicherweise nicht.
### Scannen eines lokalen sekundären Indexes
Sie können `Scan` verwenden, um alle Daten aus einem lokalen sekundären Index abzurufen. Geben Sie dazu den Namen der Basistabelle sowie den Indexnamen in der Abfrage an. Mit einer `Scan`-Operation liest DynamoDB alle Daten im Index und gibt sie an die Anwendung zurück. Sie können auch anfordern, dass nur einige der Daten zurückgegeben und die verbleibenden Daten verworfen werden. Verwenden Sie dazu den Parameter `FilterExpression` der `Scan`-API. Weitere Informationen finden Sie unter [Filterausdrücke für Scan](Scan.md#Scan.FilterExpression).
## Schreibvorgänge und lokale sekundäre Indizes
DynamoDB synchronisiert automatisch alle lokalen sekundären Indizes mit ihren jeweiligen Basistabellen. Anwendungen schreiben niemals direkt in einen Index. Allerdings ist es wichtig, zu wissen, welche Auswirkungen es hat, wie DynamoDB diese Indizes verwaltet.
Beim Erstellen eines lokalen sekundären Indizes geben Sie ein Attribut als Sortierschlüssel für den Index an. Außerdem bestimmen Sie einen Datentyp für dieses Attribut. Das bedeutet, dass wenn Sie ein Element in die Basistabelle schreiben und das Element ein Indexschlüsselattribut definiert, der entsprechende Typ dem Datentyp des Indexschlüsselschemas entsprechen muss. Im Fall von `LastPostIndex` wird der Sortierschlüssel `LastPostDateTime` im Index als Datentyp `String` definiert. Wenn Sie versuchen, der Tabelle `Thread` ein Element hinzuzufügen und einen anderen Datentyp für `LastPostDateTime` (wie z. B. `Number`) anzugeben, gibt DynamoDB eine `ValidationException` aufgrund der fehlenden Übereinstimmung des Datentyps zurück.
Es ist keine one-to-one Beziehung zwischen den Elementen in einer Basistabelle und den Elementen in einem lokalen sekundären Index erforderlich. In der Tat kann dieses Verhalten für viele Anwendungen vorteilhaft sein.
Eine Tabelle mit vielen lokalen sekundären Indizes verursacht höhere Kosten für Schreibaktivitäten als Tabellen mit weniger Indizes. Weitere Informationen finden Sie unter [Überlegungen im Hinblick auf die bereitgestellte Durchsatzkapazität für lokale sekundäre Indizes](#LSI.ThroughputConsiderations).
**Wichtig**
Für Tabellen mit lokalen sekundären Indizes besteht eine Größenbeschränkung von 10 GB pro Partitionsschlüsselwert. Eine Tabelle mit lokalem sekundärem Index kann eine beliebige Anzahl von Elementen speichern, solange die Gesamtgröße eines Partitionsschlüsselwerts 10 GB nicht überschreitet. Weitere Informationen finden Sie unter [Größenlimit der Elementauflistung](#LSI.ItemCollections.SizeLimit).
## Überlegungen im Hinblick auf die bereitgestellte Durchsatzkapazität für lokale sekundäre Indizes
Wenn Sie eine Tabelle in DynamoDB erstellen, stellen Sie Lese- und Schreibkapazitätseinheiten für den erwarteten Workload der Tabelle bereit. Dieser Workload umfasst Lese- und Schreibaktivitäten in den lokalen sekundären Indizes der Tabelle.
Die aktuellen Preise für die bereitgestellte Durchsatzkapazität finden Sie unter [Amazon-DynamoDB-Preise](https://aws.amazon.com/dynamodb/pricing).
### Lesekapazitätseinheiten
Wenn Sie einen lokalen sekundären Index abfragen, hängt die Anzahl der verbrauchten Lesekapazitätseinheiten davon ab, wie auf die Daten zugegriffen wird.
Ähnlich wie Tabellenabfragen kann eine Indexabfrage auch entweder Eventually-Consistent- oder Strongly-Consistent-Lesevorgänge abhängig vom Wert `ConsistentRead` verwenden. Ein Strongly-Consistent-Lesevorgang belegt eine Lesekapazitätseinheit, ein Eventually-Consistent-Lesevorgang verbraucht nur die Hälfte. Daher können Sie Ihre Kosten für Lesekapazitätseinheiten durch Auswählen von Eventually Consistent-Lesevorgängen reduzieren.
Für Indexabfragen, die nur Indexschlüssel und projizierte Attribute anfordern, berechnet DynamoDB die bereitgestellten Leseaktivitäten auf die gleiche Weise wie für Tabellenabfragen. Der einzige Unterschied besteht darin, dass die Berechnung auf der Größe der Indexeinträge und nicht auf der Größe des Elements in der Basistabelle beruht. Die Anzahl der Lesekapazitätseinheiten ist die Summe aller projizierten Attributgrößen sämtlicher zurückgegebener Elemente. Das Ergebnis wird dann auf den nächsten 4 KB-Grenzwert aufgerundet. Weitere Informationen darüber, wie DynamoDB die bereitgestellte Durchsatznutzung berechnet, finden Sie unter [DynamoDB – Modus mit bereitgestellter Kapazität](provisioned-capacity-mode.md).
Bei Indexabfragen, die Attribute lesen, die nicht in den lokalen sekundären Index projiziert werden, muss DynamoDB diese Attribute zusätzlich zum Lesen der projizierten Attribute aus dem Index aus der Basistabelle abrufen. Diese Abrufe treten auf, wenn Sie nicht projizierte Attribute in die Parameter `Select` oder `ProjectionExpression` der `Query`-Operation einbeziehen. Das Abrufen verursacht zusätzliche Latenz bei Abfrageantworten und verursacht auch höhere Kosten für den bereitgestellten Durchsatz: Zusätzlich zu den zuvor beschriebenen Lesevorgängen aus dem lokalen sekundären Index werden Ihnen Lesekapazitätseinheiten für jedes abgerufene Basistabellenelement in Rechnung gestellt. Diese Kosten fallen nicht nur für die angeforderten Attribute an, sondern für jedes Element, das aus der Tabelle gelesen wird.
Die maximale Größe der von einer `Query`-Operation zurückgegebenen Ergebnisse beträgt 1 MB. Diese umfasst die Größen aller Attributnamen und Werte sämtlicher zurückgegebenen Elemente. Wenn jedoch eine Abfrage für einen lokalen sekundären Index veranlasst, dass DynamoDB Elementattribute aus der Basistabelle abruft, kann die maximale Größe der Daten in den Ergebnissen niedriger sein. In diesem Fall setzt sich die Ergebnisgröße aus folgender Summe zusammen:
+ Die Größe der übereinstimmenden Elemente im Index wird auf die nächste 4 KB aufgerundet.
+ Die Größe der einzelnen übereinstimmenden Elemente in der Basistabelle wird für jedes einzelne Element auf die nächste 4 KB aufgerundet.
Mit dieser Formel beträgt die maximale Größe der von einer Abfrageoperation zurückgegebenen Ergebnisse 1 MB.
Nehmen wir als Beispiel eine Tabelle, in der die Größe jedes Element 300 Byte beträgt. Es gibt einen lokalen sekundären Index in dieser Tabelle, aber nur 200 Byte pro Element werden in den Index projiziert. Angenommen, Sie führen eine `Query`-Operation für diesen Index aus, die Abfrage erfordert Tabellenabrufe für jedes Element und die Abfrage gibt vier Elemente zurück. DynamoDB fasst Folgendes zusammen:
+ Die Größe der übereinstimmenden Elemente im Index: 200 Byte × 4 Elemente = 800 Byte. Dieser Wert wird dann auf 4 KB aufgerundet.
+ Die Größe der einzelnen übereinstimmenden Elemente in der Basistabelle: (300 Byte, auf 4 KB aufgerundet) × 4 Elemente = 16 KB.
Die Gesamtgröße der Daten im Ergebnis beträgt somit 20 KB.
### Schreibkapazitätseinheiten
Wenn ein Element in einer Tabelle hinzugefügt, aktualisiert oder gelöscht wird, verbraucht die Aktualisierung der lokalen sekundären Indizes bereitgestellte Schreibkapazitätseinheiten für die Tabelle. Die gesamten bereitgestellten Durchsatzkosten für einen Schreibvorgang sind die Summe der Schreibkapazitätseinheiten, die durch das Schreiben in die Tabelle verbraucht werden, und denjenigen, die durch die Aktualisierung der lokalen sekundären Indizes verbraucht werden.
Die Kosten für das Schreiben eines Elements in einen lokalen Sekundärindex hängen von mehreren Faktoren ab:
+ Wenn Sie ein neues Element in die Tabelle schreiben, die ein indiziertes Attribut definiert, oder ein vorhandenes Element zum Definieren eines zuvor nicht definierten indizierten Attributs aktualisieren, ist ein Schreibvorgang erforderlich, um das Element in den Index einzufügen.
+ Wenn eine Aktualisierung der Tabelle den Wert eines indizierten Schlüsselattributs (von A in B) ändert, sind zwei Schreibvorgänge erforderlich, und zwar einer zum Löschen des vorherigen Elements aus dem Index und einer zum Schreiben des neuen Elements in den Index.
+ Wenn ein Element im Index vorhanden war, ein Schreibvorgang in der Tabelle jedoch dazu führte, dass das indizierte Attribut gelöscht wurde, ist ein Schreibvorgang erforderlich, um die alte Elementprojektion im Index zu löschen.
+ Wenn ein Element nicht im Index vorhanden ist, bevor oder nachdem das Element aktualisiert wird, fallen keine zusätzlichen Kosten für das Schreiben in den Index an.
Alle diese Faktoren setzen voraus, dass die Größe der einzelnen Elemente im Index kleiner oder gleich der 1-KB- Elementgröße für das Berechnen der Schreibkapazitätseinheiten ist. Größere Indexeinträge erfordern zusätzliche Schreibkapazitätseinheiten. Sie können Ihre Kosten für Schreibvorgänge minimieren, indem Sie überlegen, welche Attribute Ihre Abfragen zurückgeben müssen, und nur diese Attribute in den Index projizieren.
## Speicherüberlegungen für lokale sekundäre Indizes
Wenn eine Anwendung ein Element in eine Tabelle schreibt, kopiert DynamoDB automatisch die richtige Teilmenge der Attribute in den lokalen sekundären Index, in dem diese Attribute angezeigt werden sollen. Ihrem AWS Konto werden sowohl die Speicherung des Elements in der Basistabelle als auch die Speicherung von Attributen in allen lokalen Sekundärindizes dieser Tabelle in Rechnung gestellt.
Der Speicherplatz, der von einem Indexelement belegt wird, ergibt sich aus der Summe von folgenden Werten:
+ Die Größe in Byte des Primärschlüssels der Basistabelle (Partitionsschlüssel und Sortierschlüssel)
+ Die Größe in Byte des Indexschlüsselattributs
+ Die Größe in Byte der projizierten Attribute (sofern vorhanden)
+ 100 Bytes des Overheads pro Indexelement
Um den Speicherbedarf für einen lokalen sekundären Index zu schätzen, können Sie die durchschnittliche Größe eines Elements im Index schätzen und dann mit der Anzahl der Elemente im Index multiplizieren.
Wenn eine Tabelle ein Element enthält, in dem ein bestimmtes Attribut nicht definiert ist, dieses Attribut aber als Indexsortierschlüssel festgelegt ist, schreibt DynamoDB keine Daten für dieses Element in den Index.
## Elementauflistungen in lokalen sekundären Indizes
**Anmerkung**
Dieser Abschnitt betrifft nur Tabellen mit lokalen sekundären Indizes.
In DynamoDB ist eine *Elementsammlung* eine beliebige Gruppe von Elementen, die denselben Partitionsschlüsselwert in einer Tabelle und allen ihren lokalen sekundären Indizes aufweisen. In den Beispielen in diesem Abschnitt lautet der Partitionsschlüssel für die `Thread`-Tabelle `ForumName` und der Partitionsschlüssel für `LastPostIndex` ist ebenfalls `ForumName`. Alle Tabellen- und Indexelemente mit demselben `ForumName` gehören zur selben Elementauflistung. In der `Thread`-Tabelle und dem `LastPostIndex`- ist beispielsweise eine Elementauflistung für das `EC2`-Forum und eine andere Elementauflistung für das `RDS`-Forum vorhanden.
Das folgende Diagramm zeigt die Elementauflistung für das `S3`-Forum:
![\[Eine DynamoDB-Elementauflistung, die denselben Partitionsschlüsselwert von S3 in einer Tabelle und allen ihren lokalen sekundären Indizes aufweisen.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/LSI_04.png)
In diesem Diagramm enthält die Elementauflistung alle Elemente von `Thread` und `LastPostIndex`, wobei der Partitionsschlüsselwert `ForumName` „S3“ lautet. Wenn die Tabelle andere lokale sekundäre Indizes enthält, wären alle Elemente in diesen Indizes mit `ForumName` gleich „S3“ ebenfalls Teil der Elementsammlung.
Sie können eine der folgenden Operationen in DynamoDB verwenden, um Informationen zu Elementauflistungen zu erhalten:
+ `BatchWriteItem`
+ `DeleteItem`
+ `PutItem`
+ `UpdateItem`
+ `TransactWriteItems`
Jede dieser Operationen unterstützt den Parameter `ReturnItemCollectionMetrics`. Wenn Sie diesen Parameter auf `SIZE` festlegen, können Sie Informationen über die Größe der einzelnen Elementauflistung im Index anzeigen.
**Example**
Nachfolgend finden Sie ein Beispiel aus der Ausgabe einer `UpdateItem`-Operation für die `Thread`-Tabelle, mit `ReturnItemCollectionMetrics` auf `SIZE`. Das Element, das aktualisiert wurde, hatte den `ForumName` „EC2“, sodass die Ausgabe Informationen über diese Elementauflistung enthält.
```
{
ItemCollectionMetrics: {
ItemCollectionKey: {
ForumName: "EC2"
},
SizeEstimateRangeGB: [0.0, 1.0]
}
}
```
Das `SizeEstimateRangeGB`-Objekt zeigt, dass die Größe dieser Elementauflistung zwischen 0 und 1 GB beträgt. DynamoDB aktualisiert diese Größenschätzung in regelmäßigen Abständen, sodass die Zahlen bei der nächsten Änderung des Elements anders lauten können.
### Größenlimit der Elementauflistung
Die maximale Größe einer Elementauflistung für eine Tabelle mit einem oder mehreren lokalen sekundären Indizes beträgt 10 GB. Dies gilt nicht für Elementauflistungen in Tabellen ohne lokale sekundäre Indizes und auch nicht für Elementauflistungen in globalen sekundären Indizes. Es sind nur Tabellen mit einem oder mehreren lokalen sekundären Indizes betroffen.
Wenn eine Artikelsammlung den Grenzwert von 10 GB überschreitet, gibt DynamoDB möglicherweise eine zurück`ItemCollectionSizeLimitExceededException`, und Sie können der Artikelsammlung möglicherweise keine weiteren Artikel hinzufügen oder die Größe der Elemente in der Artikelsammlung erhöhen. (Lese- und Schreibvorgänge, die die Größe der Elementauflistung reduzieren, sind nach wie vor zulässig.) Sie können weiterhin Elemente zu anderen Elementauflistungen hinzufügen.
Um die Größe einer Elementauflistung zu reduzieren, können Sie einen der folgenden Schritte ausführen:
+ Löschen Sie alle unnötigen Elemente mit dem betreffenden Partitionsschlüsselwert. Wenn Sie diese Elemente aus der Basistabelle löschen, entfernt DynamoDB auch alle Indexeinträge, die denselben Partitionsschlüsselwert aufweisen.
+ Aktualisieren Sie die Elemente durch Entfernen von Attributen oder durch die Reduzierung der Größe der Attribute. Wenn diese Attribute in lokale sekundäre Indizes projiziert werden, reduziert DynamoDB auch die Größe der entsprechenden Indexeinträge.
+ Erstellen Sie eine neue Tabelle mit demselben Partitions- und Sortierschlüssel und verschieben Sie die Elemente von der alten in die neue Tabelle. Dies ist ein guter Ansatz, wenn eine Tabelle über historische Daten verfügt, auf die selten zugegriffen wird. Sie können auch in Betracht ziehen, diese historischen Daten in Amazon Simple Storage Service (Amazon S3) zu archivieren.
Wenn die Gesamtgröße der Elementsammlung unter 10 GB sinkt, können Sie erneut Elemente mit demselben Partitionsschlüsselwert hinzufügen.
Wir empfehlen als bewährte Methode, Ihre Anwendung zu instrumentieren, um die Größe Ihrer Elementauflistungen zu überwachen. Eine Möglichkeit dazu ist, den Parameter `ReturnItemCollectionMetrics` auf `SIZE` festzulegen, sobald Sie `BatchWriteItem`, `DeleteItem`, `PutItem` oder `UpdateItem`. verwenden. Ihre Anwendung sollte das `ReturnItemCollectionMetrics`-Objekt in der Ausgabe untersuchen und eine Fehlermeldung protokollieren, wenn eine Elementauflistung einen benutzerdefinierten Grenzwert (z. B. 8 GB) überschreitet. Wenn Sie einen geringeren Wert als 10 GB als Limit festlegen, ist dies ein Frühwarnsystem, da Sie so rechtzeitig erfahren, dass sich eine Elementauflistung dem Limit nähert, und entsprechende Maßnahmen ergreifen können.
### Elementauflistungen und Partitionen
In einer Tabelle mit einem oder mehreren lokalen sekundären Indizes wird jede Elementauflistung in einer Partition gespeichert. Die Gesamtgröße einer solchen Elementauflistung ist auf die Kapazität dieser Partition beschränkt: 10 GB. Für eine Anwendung, bei der das Datenmodell Elementauflistungen enthält, deren Größe unbegrenzt ist oder bei denen Sie vernünftigerweise davon ausgehen können, dass einige Elementauflistungen in Zukunft auf mehr als 10 GB anwachsen werden, sollten Sie stattdessen einen globalen sekundären Index verwenden.
Sie sollten Ihre Anwendungen so konzipieren, dass Tabellendaten gleichmäßig auf unterschiedliche Partitionsschlüsselwerte verteilt werden. Für Tabellen mit lokalen sekundären Indizes sollten Ihre Anwendungen keine „Hotspots“ für Lese- und Schreibaktivitäten innerhalb einer einzigen Elementauflistung in einer einzelnen Partition erstellen.
# Arbeiten mit lokalen sekundären Indizes: Java
Sie können die AWS SDK für Java Document-API verwenden, um eine Amazon DynamoDB-Tabelle mit einem oder mehreren lokalen Sekundärindizes zu erstellen, die Indizes in der Tabelle zu beschreiben und Abfragen mithilfe der Indizes durchzuführen.
Im Folgenden werden die üblichen Schritte für Tabellenoperationen mit der Document-API beschrieben. AWS SDK für Java
1. Erstellen Sie eine Instance der `DynamoDB`-Klasse.
1. Stellen Sie den erforderlichen und optionalen Parameter für die Operation bereit, indem Sie die entsprechenden Anforderungsobjekte erstellen.
1. Rufen Sie die entsprechende Methode auf, die vom Client, den Sie im vorhergehenden Schritt erstellt haben, bereitgestellt wird.
**Topics**
+ [Erstellen einer Tabelle mit einem lokalen sekundären Index](#LSIJavaDocumentAPI.CreateTableWithIndex)
+ [Beschreiben einer Tabelle mit einem lokalen sekundären Index](#LSIJavaDocumentAPI.DescribeTableWithIndex)
+ [Abfragen eines lokalen sekundären Indexes](#LSIJavaDocumentAPI.QueryAnIndex)
+ [Beispiel: Lokale sekundäre Indizes mit der Java-Dokument-API](LSIJavaDocumentAPI.Example.md)
## Erstellen einer Tabelle mit einem lokalen sekundären Index
Lokale sekundäre Indizes müssen gleichzeitig mit dem Erstellen einer Tabelle erstellt werden. Verwenden Sie dazu die Methode `createTable` und geben Sie Ihre Angaben für einen oder mehrere lokale Sekundärindizes an. Das folgende Java-Codebeispiel erstellt eine Tabelle, die Informationen über Songs in einer Musiksammlung enthält. Der Partitionsschlüssel ist `Artist` und der Sortierschlüssel `SongTitle`. Der sekundäre Index, `AlbumTitleIndex`, vereinfacht Abfragen von Albumtiteln.
Im Folgenden werden die Schritte zum Erstellen einer Tabelle mit einem lokalen sekundären Index mithilfe der DynamoDB-Dokument-API dargelegt.
1. Erstellen Sie eine Instance der `DynamoDB`-Klasse.
1. Erstellen Sie eine Instance der `CreateTableRequest`-Klasse, um die Anforderungsinformationen bereitzustellen.
Sie müssen den Tabellennamen, seinen zugehörigen Primärschlüssel und die Werte des bereitgestellten Durchsatzes angeben. Für den lokalen sekundären Index müssen Sie den Indexnamen, den Namen und den Datentyp des Indexsortierschlüssels, des Schlüsselschemas für den Index und der Attributprojektion angeben.
1. Rufen Sie die `createTable`-Methode auf, indem das Anforderungsobjekt als Parameter festgelegt wird.
Im folgenden Java-Codebeispiel werden die vorherigen Schritte veranschaulicht. Der Codeerstellt eine Tabelle (`Music`) mit einem sekundären Index auf dem `AlbumTitle`-Attribut. Der Tabellenpartitionsschlüssel und der Sortierschlüssel, sowie der Indexsortierschlüssel sind die einzigen in den Index projizierten Attribute.
```
AmazonDynamoDB client = AmazonDynamoDBClientBuilder.standard().build();
DynamoDB dynamoDB = new DynamoDB(client);
String tableName = "Music";
CreateTableRequest createTableRequest = new CreateTableRequest().withTableName(tableName);
//ProvisionedThroughput
createTableRequest.setProvisionedThroughput(new ProvisionedThroughput().withReadCapacityUnits((long)5).withWriteCapacityUnits((long)5));
//AttributeDefinitions
ArrayList attributeDefinitions= new ArrayList();
attributeDefinitions.add(new AttributeDefinition().withAttributeName("Artist").withAttributeType("S"));
attributeDefinitions.add(new AttributeDefinition().withAttributeName("SongTitle").withAttributeType("S"));
attributeDefinitions.add(new AttributeDefinition().withAttributeName("AlbumTitle").withAttributeType("S"));
createTableRequest.setAttributeDefinitions(attributeDefinitions);
//KeySchema
ArrayList tableKeySchema = new ArrayList();
tableKeySchema.add(new KeySchemaElement().withAttributeName("Artist").withKeyType(KeyType.HASH)); //Partition key
tableKeySchema.add(new KeySchemaElement().withAttributeName("SongTitle").withKeyType(KeyType.RANGE)); //Sort key
createTableRequest.setKeySchema(tableKeySchema);
ArrayList indexKeySchema = new ArrayList();
indexKeySchema.add(new KeySchemaElement().withAttributeName("Artist").withKeyType(KeyType.HASH)); //Partition key
indexKeySchema.add(new KeySchemaElement().withAttributeName("AlbumTitle").withKeyType(KeyType.RANGE)); //Sort key
Projection projection = new Projection().withProjectionType(ProjectionType.INCLUDE);
ArrayList nonKeyAttributes = new ArrayList();
nonKeyAttributes.add("Genre");
nonKeyAttributes.add("Year");
projection.setNonKeyAttributes(nonKeyAttributes);
LocalSecondaryIndex localSecondaryIndex = new LocalSecondaryIndex()
.withIndexName("AlbumTitleIndex").withKeySchema(indexKeySchema).withProjection(projection);
ArrayList localSecondaryIndexes = new ArrayList();
localSecondaryIndexes.add(localSecondaryIndex);
createTableRequest.setLocalSecondaryIndexes(localSecondaryIndexes);
Table table = dynamoDB.createTable(createTableRequest);
System.out.println(table.getDescription());
```
Sie müssen warten bis DynamoDB die Tabelle erstellt und den Tabellenstatus auf `ACTIVE` setzt. Im Anschluss können Sie die Daten in der Tabelle ablegen.
## Beschreiben einer Tabelle mit einem lokalen sekundären Index
Um Informationen zu lokalen sekundären Indizes in einer Tabelle zu erhalten, verwenden Sie die Methode `describeTable`. Sie können auf den Namen, das Schlüsselschema und die projizierten Attribute von jedem Index zugreifen.
Im Folgenden sind die Schritte für den Zugriff auf lokale sekundäre Indexinformationen einer Tabelle mithilfe der AWS SDK für Java -Dokument-API aufgeführt.
1. Erstellen Sie eine Instance der `DynamoDB`-Klasse.
1. Erstellen Sie eine Instance der `Table`-Klasse. Sie müssen den Tabellennamen angeben.
1. Rufen Sie die `describeTable`-Methode für das `Table`-Objekt auf.
Im folgenden Java-Codebeispiel werden die vorherigen Schritte veranschaulicht.
**Example**
```
AmazonDynamoDB client = AmazonDynamoDBClientBuilder.standard().build();
DynamoDB dynamoDB = new DynamoDB(client);
String tableName = "Music";
Table table = dynamoDB.getTable(tableName);
TableDescription tableDescription = table.describe();
List localSecondaryIndexes
= tableDescription.getLocalSecondaryIndexes();
// This code snippet will work for multiple indexes, even though
// there is only one index in this example.
Iterator lsiIter = localSecondaryIndexes.iterator();
while (lsiIter.hasNext()) {
LocalSecondaryIndexDescription lsiDescription = lsiIter.next();
System.out.println("Info for index " + lsiDescription.getIndexName() + ":");
Iterator kseIter = lsiDescription.getKeySchema().iterator();
while (kseIter.hasNext()) {
KeySchemaElement kse = kseIter.next();
System.out.printf("\t%s: %s\n", kse.getAttributeName(), kse.getKeyType());
}
Projection projection = lsiDescription.getProjection();
System.out.println("\tThe projection type is: " + projection.getProjectionType());
if (projection.getProjectionType().toString().equals("INCLUDE")) {
System.out.println("\t\tThe non-key projected attributes are: " + projection.getNonKeyAttributes());
}
}
```
## Abfragen eines lokalen sekundären Indexes
Sie können die Operation `Query` für einen lokalen sekundären Index genauso nutzen, wie Sie `Query` für eine Tabelle nutzen. Sie müssen den Indexnamen, die Abfragekriterien für den Indexsortierschlüssel und die Attribute angeben, die Sie zurückgeben möchten. In diesem Beispiel ist der Index `AlbumTitleIndex` und der Indexsortierschlüssel `AlbumTitle`.
Die einzigen zurückgegebenen Attribute sind die, die in den Index projiziert wurden. Sie könnten diese Abfrage ändern, um auch Nicht-Schlüsselattribute auszuwählen, aber dies würde eine Tabellenabrufaktivität erfordern, die relativ teuer ist. Weitere Informationen zum Abrufen von Tabellen finden Sie unter [Attributprojektionen](LSI.md#LSI.Projections).
Im Folgenden werden die Schritte zum Abfragen eines lokalen sekundären Indexes mithilfe der AWS SDK für Java Dokument-API beschrieben.
1. Erstellen Sie eine Instance der `DynamoDB`-Klasse.
1. Erstellen Sie eine Instance der `Table`-Klasse. Sie müssen den Tabellennamen angeben.
1. Erstellen Sie eine Instance der `Index`-Klasse. Sie müssen den Indexnamen angeben.
1. Rufen Sie die `query`-Methode für die `Index`-Klasse auf.
Im folgenden Java-Codebeispiel werden die vorherigen Schritte veranschaulicht.
**Example**
```
AmazonDynamoDB client = AmazonDynamoDBClientBuilder.standard().build();
DynamoDB dynamoDB = new DynamoDB(client);
String tableName = "Music";
Table table = dynamoDB.getTable(tableName);
Index index = table.getIndex("AlbumTitleIndex");
QuerySpec spec = new QuerySpec()
.withKeyConditionExpression("Artist = :v_artist and AlbumTitle = :v_title")
.withValueMap(new ValueMap()
.withString(":v_artist", "Acme Band")
.withString(":v_title", "Songs About Life"));
ItemCollection items = index.query(spec);
Iterator
- itemsIter = items.iterator();
while (itemsIter.hasNext()) {
Item item = itemsIter.next();
System.out.println(item.toJSONPretty());
}
```
### Konsistente Lesevorgänge auf einem lokalen sekundären Index
Im Gegensatz zu globalen Sekundärindizes, die nur eventuell konsistente Lesevorgänge unterstützen, unterstützt ein lokaler sekundärer Index sowohl letztlich konsistente als auch stark konsistente Lesevorgänge. Bei einem Strongly-Consistent-Lesevorgang von einem lokalen sekundären Index werden immer die zuletzt aktualisierten Werte zurückgegeben. Wenn die Abfrage zusätzliche Attribute aus der Basistabelle abrufen muss, sind diese abgerufenen Attribute auch in Bezug auf den Index konsistent.
`Query`Verwendet standardmäßig eventuell konsistente Lesevorgänge. Um einen stark konsistenten Lesevorgang anzufordern, setzen Sie `true` in der `ConsistentRead` auf`QuerySpec`. Im folgenden Beispiel wird für `AlbumTitleIndex` Abfragen ein stark konsistenter Lesevorgang verwendet:
**Example**
```
QuerySpec spec = new QuerySpec()
.withKeyConditionExpression("Artist = :v_artist and AlbumTitle = :v_title")
.withValueMap(new ValueMap()
.withString(":v_artist", "Acme Band")
.withString(":v_title", "Songs About Life"))
.withConsistentRead(true);
```
**Anmerkung**
Ein stark konsistenter Lesevorgang verbraucht eine Lesekapazitätseinheit pro 4 KB zurückgegebener Daten (aufgerundet), wohingegen ein eventuell konsistenter Lesevorgang die Hälfte davon verbraucht. Beispielsweise verbraucht ein stark konsistenter Lesevorgang, der 9 KB an Daten zurückgibt, 3 Lesekapazitätseinheiten (9 KB/4 KB = 2,25, aufgerundet auf 3), während dieselbe Abfrage, die einen eventuell konsistenten Lesevorgang verwendet, 1,5 Lesekapazitätseinheiten verbraucht. Wenn Ihre Anwendung das Lesen von Daten verträgt, die möglicherweise etwas veraltet sind, verwenden Sie eventuell konsistente Lesevorgänge, um Ihre Lesekapazitätsnutzung zu reduzieren. Weitere Informationen finden Sie unter [Lesekapazitätseinheiten](LSI.md#LSI.ThroughputConsiderations.Reads).
# Beispiel: Lokale sekundäre Indizes mit der Java-Dokument-API
Das folgende Java-Codebeispiel zeigt, wie Sie mit lokalen sekundären Indizes in Amazon DynamoDB arbeiten. Das Beispiel erstellt eine Tabelle mit dem Namen `CustomerOrders` mit `CustomerId` als Partitionsschlüssel und `OrderId` als Sortierschlüssel. Es gibt zwei lokale sekundäre Indizes in dieser Tabelle:
+ `OrderCreationDateIndex` – der Sortierschlüssel ist `OrderCreationDate` und die folgenden Attribute werden in den Index projiziert:
+ `ProductCategory`
+ `ProductName`
+ `OrderStatus`
+ `ShipmentTrackingId`
+ `IsOpenIndex` – der Sortierschlüssel ist `IsOpen` und alle Tabellenattribute werden in den Index projiziert.
Nachdem die `CustomerOrders`-Tabelle erstellt wurde, lädt das Programm die Tabelle mit Daten, die Kundenaufträge darstellen. Mit If Then werden die Daten unter Verwendung der lokalen sekundären Indizes abgefragt. Schließlich löscht das Programm die `CustomerOrders`-Tabelle.
step-by-stepAnweisungen zum Testen des folgenden Beispiels finden Sie unter[Java-Codebeispiele](CodeSamples.Java.md).
**Example**
```
package com.example.dynamodb;
import software.amazon.awssdk.core.waiters.WaiterResponse;
import software.amazon.awssdk.services.dynamodb.DynamoDbClient;
import software.amazon.awssdk.services.dynamodb.model.*;
import software.amazon.awssdk.services.dynamodb.waiters.DynamoDbWaiter;
import java.util.HashMap;
import java.util.Map;
public class DocumentAPILocalSecondaryIndexExample {
static DynamoDbClient client = DynamoDbClient.create();
public static String tableName = "CustomerOrders";
public static void main(String[] args) {
createTable();
loadData();
query(null);
query("IsOpenIndex");
query("OrderCreationDateIndex");
deleteTable(tableName);
}
public static void createTable() {
CreateTableRequest request = CreateTableRequest.builder()
.tableName(tableName)
.provisionedThroughput(ProvisionedThroughput.builder()
.readCapacityUnits(1L)
.writeCapacityUnits(1L)
.build())
.attributeDefinitions(
AttributeDefinition.builder().attributeName("CustomerId").attributeType(ScalarAttributeType.S).build(),
AttributeDefinition.builder().attributeName("OrderId").attributeType(ScalarAttributeType.N).build(),
AttributeDefinition.builder().attributeName("OrderCreationDate").attributeType(ScalarAttributeType.N).build(),
AttributeDefinition.builder().attributeName("IsOpen").attributeType(ScalarAttributeType.N).build())
.keySchema(
KeySchemaElement.builder().attributeName("CustomerId").keyType(KeyType.HASH).build(),
KeySchemaElement.builder().attributeName("OrderId").keyType(KeyType.RANGE).build())
.localSecondaryIndexes(
LocalSecondaryIndex.builder()
.indexName("OrderCreationDateIndex")
.keySchema(
KeySchemaElement.builder().attributeName("CustomerId").keyType(KeyType.HASH).build(),
KeySchemaElement.builder().attributeName("OrderCreationDate").keyType(KeyType.RANGE).build())
.projection(Projection.builder()
.projectionType(ProjectionType.INCLUDE)
.nonKeyAttributes("ProductCategory", "ProductName")
.build())
.build(),
LocalSecondaryIndex.builder()
.indexName("IsOpenIndex")
.keySchema(
KeySchemaElement.builder().attributeName("CustomerId").keyType(KeyType.HASH).build(),
KeySchemaElement.builder().attributeName("IsOpen").keyType(KeyType.RANGE).build())
.projection(Projection.builder()
.projectionType(ProjectionType.ALL)
.build())
.build())
.build();
System.out.println("Creating table " + tableName + "...");
client.createTable(request);
try (DynamoDbWaiter waiter = client.waiter()) {
WaiterResponse response = waiter.waitUntilTableExists(r -> r.tableName(tableName));
response.matched().response().ifPresent(System.out::println);
}
}
public static void query(String indexName) {
System.out.println("\n***********************************************************\n");
System.out.println("Querying table " + tableName + "...");
if ("IsOpenIndex".equals(indexName)) {
System.out.println("\nUsing index: '" + indexName + "': Bob's orders that are open.");
System.out.println("Only a user-specified list of attributes are returned\n");
Map values = new HashMap<>();
values.put(":v_custid", AttributeValue.builder().s("bob@example.com").build());
values.put(":v_isopen", AttributeValue.builder().n("1").build());
QueryRequest request = QueryRequest.builder()
.tableName(tableName)
.indexName(indexName)
.keyConditionExpression("CustomerId = :v_custid and IsOpen = :v_isopen")
.expressionAttributeValues(values)
.projectionExpression("OrderCreationDate, ProductCategory, ProductName, OrderStatus")
.build();
System.out.println("Query: printing results...");
client.query(request).items().forEach(System.out::println);
} else if ("OrderCreationDateIndex".equals(indexName)) {
System.out.println("\nUsing index: '" + indexName + "': Bob's orders that were placed after 01/31/2015.");
System.out.println("Only the projected attributes are returned\n");
Map values = new HashMap<>();
values.put(":v_custid", AttributeValue.builder().s("bob@example.com").build());
values.put(":v_orddate", AttributeValue.builder().n("20150131").build());
QueryRequest request = QueryRequest.builder()
.tableName(tableName)
.indexName(indexName)
.keyConditionExpression("CustomerId = :v_custid and OrderCreationDate >= :v_orddate")
.expressionAttributeValues(values)
.select(Select.ALL_PROJECTED_ATTRIBUTES)
.build();
System.out.println("Query: printing results...");
client.query(request).items().forEach(System.out::println);
} else {
System.out.println("\nNo index: All of Bob's orders, by OrderId:\n");
Map values = new HashMap<>();
values.put(":v_custid", AttributeValue.builder().s("bob@example.com").build());
QueryRequest request = QueryRequest.builder()
.tableName(tableName)
.keyConditionExpression("CustomerId = :v_custid")
.expressionAttributeValues(values)
.build();
System.out.println("Query: printing results...");
client.query(request).items().forEach(System.out::println);
}
}
public static void deleteTable(String tableName) {
System.out.println("Deleting table " + tableName + "...");
client.deleteTable(DeleteTableRequest.builder().tableName(tableName).build());
try (DynamoDbWaiter waiter = client.waiter()) {
waiter.waitUntilTableNotExists(r -> r.tableName(tableName));
}
}
public static void loadData() {
System.out.println("Loading data into table " + tableName + "...");
putItem(Map.of(
"CustomerId", AttributeValue.builder().s("alice@example.com").build(),
"OrderId", AttributeValue.builder().n("1").build(),
"IsOpen", AttributeValue.builder().n("1").build(),
"OrderCreationDate", AttributeValue.builder().n("20150101").build(),
"ProductCategory", AttributeValue.builder().s("Book").build(),
"ProductName", AttributeValue.builder().s("The Great Outdoors").build(),
"OrderStatus", AttributeValue.builder().s("PACKING ITEMS").build()));
putItem(Map.of(
"CustomerId", AttributeValue.builder().s("alice@example.com").build(),
"OrderId", AttributeValue.builder().n("2").build(),
"IsOpen", AttributeValue.builder().n("1").build(),
"OrderCreationDate", AttributeValue.builder().n("20150221").build(),
"ProductCategory", AttributeValue.builder().s("Bike").build(),
"ProductName", AttributeValue.builder().s("Super Mountain").build(),
"OrderStatus", AttributeValue.builder().s("ORDER RECEIVED").build()));
putItem(Map.of(
"CustomerId", AttributeValue.builder().s("alice@example.com").build(),
"OrderId", AttributeValue.builder().n("3").build(),
"OrderCreationDate", AttributeValue.builder().n("20150304").build(),
"ProductCategory", AttributeValue.builder().s("Music").build(),
"ProductName", AttributeValue.builder().s("A Quiet Interlude").build(),
"OrderStatus", AttributeValue.builder().s("IN TRANSIT").build(),
"ShipmentTrackingId", AttributeValue.builder().s("176493").build()));
putItem(Map.of(
"CustomerId", AttributeValue.builder().s("bob@example.com").build(),
"OrderId", AttributeValue.builder().n("1").build(),
"OrderCreationDate", AttributeValue.builder().n("20150111").build(),
"ProductCategory", AttributeValue.builder().s("Movie").build(),
"ProductName", AttributeValue.builder().s("Calm Before The Storm").build(),
"OrderStatus", AttributeValue.builder().s("SHIPPING DELAY").build(),
"ShipmentTrackingId", AttributeValue.builder().s("859323").build()));
putItem(Map.of(
"CustomerId", AttributeValue.builder().s("bob@example.com").build(),
"OrderId", AttributeValue.builder().n("2").build(),
"OrderCreationDate", AttributeValue.builder().n("20150124").build(),
"ProductCategory", AttributeValue.builder().s("Music").build(),
"ProductName", AttributeValue.builder().s("E-Z Listening").build(),
"OrderStatus", AttributeValue.builder().s("DELIVERED").build(),
"ShipmentTrackingId", AttributeValue.builder().s("756943").build()));
putItem(Map.of(
"CustomerId", AttributeValue.builder().s("bob@example.com").build(),
"OrderId", AttributeValue.builder().n("3").build(),
"OrderCreationDate", AttributeValue.builder().n("20150221").build(),
"ProductCategory", AttributeValue.builder().s("Music").build(),
"ProductName", AttributeValue.builder().s("Symphony 9").build(),
"OrderStatus", AttributeValue.builder().s("DELIVERED").build(),
"ShipmentTrackingId", AttributeValue.builder().s("645193").build()));
putItem(Map.of(
"CustomerId", AttributeValue.builder().s("bob@example.com").build(),
"OrderId", AttributeValue.builder().n("4").build(),
"IsOpen", AttributeValue.builder().n("1").build(),
"OrderCreationDate", AttributeValue.builder().n("20150222").build(),
"ProductCategory", AttributeValue.builder().s("Hardware").build(),
"ProductName", AttributeValue.builder().s("Extra Heavy Hammer").build(),
"OrderStatus", AttributeValue.builder().s("PACKING ITEMS").build()));
putItem(Map.of(
"CustomerId", AttributeValue.builder().s("bob@example.com").build(),
"OrderId", AttributeValue.builder().n("5").build(),
"OrderCreationDate", AttributeValue.builder().n("20150309").build(),
"ProductCategory", AttributeValue.builder().s("Book").build(),
"ProductName", AttributeValue.builder().s("How To Cook").build(),
"OrderStatus", AttributeValue.builder().s("IN TRANSIT").build(),
"ShipmentTrackingId", AttributeValue.builder().s("440185").build()));
putItem(Map.of(
"CustomerId", AttributeValue.builder().s("bob@example.com").build(),
"OrderId", AttributeValue.builder().n("6").build(),
"OrderCreationDate", AttributeValue.builder().n("20150318").build(),
"ProductCategory", AttributeValue.builder().s("Luggage").build(),
"ProductName", AttributeValue.builder().s("Really Big Suitcase").build(),
"OrderStatus", AttributeValue.builder().s("DELIVERED").build(),
"ShipmentTrackingId", AttributeValue.builder().s("893927").build()));
putItem(Map.of(
"CustomerId", AttributeValue.builder().s("bob@example.com").build(),
"OrderId", AttributeValue.builder().n("7").build(),
"OrderCreationDate", AttributeValue.builder().n("20150324").build(),
"ProductCategory", AttributeValue.builder().s("Golf").build(),
"ProductName", AttributeValue.builder().s("PGA Pro II").build(),
"OrderStatus", AttributeValue.builder().s("OUT FOR DELIVERY").build(),
"ShipmentTrackingId", AttributeValue.builder().s("383283").build()));
}
private static void putItem(Map item) {
client.putItem(PutItemRequest.builder().tableName(tableName).item(item).build());
}
}
```
# Arbeiten mit lokalen sekundären Indizes: .NET
**Topics**
+ [Erstellen einer Tabelle mit einem lokalen sekundären Index](#LSILowLevelDotNet.CreateTableWithIndex)
+ [Beschreiben einer Tabelle mit einem lokalen sekundären Index](#LSILowLevelDotNet.DescribeTableWithIndex)
+ [Abfragen eines lokalen sekundären Indexes](#LSILowLevelDotNet.QueryAnIndex)
+ [Beispiel: Lokale sekundäre Indizes mithilfe der Low-Level-API AWS SDK für .NET](LSILowLevelDotNet.Example.md)
Sie können die AWS SDK für .NET Low-Level-API verwenden, um eine Amazon DynamoDB-Tabelle mit einem oder mehreren lokalen Sekundärindizes zu erstellen, die Indizes in der Tabelle zu beschreiben und Abfragen mithilfe der Indizes durchzuführen. Diese Operationen entsprechen den Low-Level-DynamoDB-API-Aktionen. Weitere Informationen finden Sie unter [.NET-Codebeispiele](CodeSamples.DotNet.md).
Folgende sind die allgemeinen Schritte für Tabellenoperationen mithilfe der .NET-Low-Level-API.
1. Erstellen Sie eine Instance der `AmazonDynamoDBClient`-Klasse.
1. Stellen Sie den erforderlichen und optionalen Parameter für die Operation bereit, indem Sie die entsprechenden Anforderungsobjekte erstellen.
Erstellen Sie beispielsweise ein `CreateTableRequest`-Objekt, um eine Tabelle zu erstellen und ein `QueryRequest`-Objekt, um eine Tabelle oder einen Index abzufragen.
1. Rufen Sie die entsprechende Methode auf, die vom Client, den Sie im vorhergehenden Schritt erstellt haben, bereitgestellt wird.
## Erstellen einer Tabelle mit einem lokalen sekundären Index
Lokale sekundäre Indizes müssen gleichzeitig beim Erstellen einer Tabelle erstellt werden. Zu diesem Zweck verwenden Sie `CreateTable` und geben Ihre Spezifikationen für ein oder mehrere lokale sekundäre Indizes an. Das folgende C\$1-Codebeispiel erstellt eine Tabelle, die Informationen über Songs in einer Musiksammlung enthält. Der Partitionsschlüssel ist `Artist` und der Sortierschlüssel `SongTitle`. Der sekundäre Index, `AlbumTitleIndex`, vereinfacht Abfragen von Albumtiteln.
Im Folgenden sind die Schritte zum Erstellen einer Tabelle mit einem lokalen sekundären Index unter Verwendung der .NET-API auf niedriger Ebene aufgeführt.
1. Erstellen Sie eine Instance der `AmazonDynamoDBClient`-Klasse.
1. Erstellen Sie eine Instance der `CreateTableRequest`-Klasse, um die Anforderungsinformationen bereitzustellen.
Sie müssen den Tabellennamen, seinen zugehörigen Primärschlüssel und die Werte des bereitgestellten Durchsatzes angeben. Für den lokalen sekundären Index müssen Sie den Indexnamen, den Namen und den Datentyp des Indexsortierschlüssels, das Schlüsselschema für den Index und die Attributprojektion angeben.
1. Führen Sie die `CreateTable`-Methode aus, indem das Anforderungsobjekt als Parameter festgelegt wird.
Im folgenden C\$1-Codebeispiel werden die vorherigen Schritte veranschaulicht. Der Codeerstellt eine Tabelle (`Music`) mit einem sekundären Index auf dem `AlbumTitle`-Attribut. Der Tabellenpartitionsschlüssel und der Sortierschlüssel, sowie der Indexsortierschlüssel sind die einzigen in den Index projizierten Attribute.
```
AmazonDynamoDBClient client = new AmazonDynamoDBClient();
string tableName = "Music";
CreateTableRequest createTableRequest = new CreateTableRequest()
{
TableName = tableName
};
//ProvisionedThroughput
createTableRequest.ProvisionedThroughput = new ProvisionedThroughput()
{
ReadCapacityUnits = (long)5,
WriteCapacityUnits = (long)5
};
//AttributeDefinitions
List attributeDefinitions = new List();
attributeDefinitions.Add(new AttributeDefinition()
{
AttributeName = "Artist",
AttributeType = "S"
});
attributeDefinitions.Add(new AttributeDefinition()
{
AttributeName = "SongTitle",
AttributeType = "S"
});
attributeDefinitions.Add(new AttributeDefinition()
{
AttributeName = "AlbumTitle",
AttributeType = "S"
});
createTableRequest.AttributeDefinitions = attributeDefinitions;
//KeySchema
List tableKeySchema = new List();
tableKeySchema.Add(new KeySchemaElement() { AttributeName = "Artist", KeyType = "HASH" }); //Partition key
tableKeySchema.Add(new KeySchemaElement() { AttributeName = "SongTitle", KeyType = "RANGE" }); //Sort key
createTableRequest.KeySchema = tableKeySchema;
List indexKeySchema = new List();
indexKeySchema.Add(new KeySchemaElement() { AttributeName = "Artist", KeyType = "HASH" }); //Partition key
indexKeySchema.Add(new KeySchemaElement() { AttributeName = "AlbumTitle", KeyType = "RANGE" }); //Sort key
Projection projection = new Projection() { ProjectionType = "INCLUDE" };
List nonKeyAttributes = new List();
nonKeyAttributes.Add("Genre");
nonKeyAttributes.Add("Year");
projection.NonKeyAttributes = nonKeyAttributes;
LocalSecondaryIndex localSecondaryIndex = new LocalSecondaryIndex()
{
IndexName = "AlbumTitleIndex",
KeySchema = indexKeySchema,
Projection = projection
};
List localSecondaryIndexes = new List();
localSecondaryIndexes.Add(localSecondaryIndex);
createTableRequest.LocalSecondaryIndexes = localSecondaryIndexes;
CreateTableResponse result = client.CreateTable(createTableRequest);
Console.WriteLine(result.CreateTableResult.TableDescription.TableName);
Console.WriteLine(result.CreateTableResult.TableDescription.TableStatus);
```
Sie müssen warten bis DynamoDB die Tabelle erstellt und den Tabellenstatus auf `ACTIVE` setzt. Im Anschluss können Sie die Daten in der Tabelle ablegen.
## Beschreiben einer Tabelle mit einem lokalen sekundären Index
Um Informationen zu lokalen sekundären Indizes in einer Tabelle zu erhalten, verwenden Sie die `DescribeTable`-API. Sie können auf den Namen, das Schlüsselschema und die projizierten Attribute von jedem Index zugreifen.
Im Folgenden finden Sie die Schritte zum Zugreifen auf lokale sekundäre Indexinformationen einer Tabelle mithilfe der .NET-Low-Level-API.
1. Erstellen Sie eine Instance der `AmazonDynamoDBClient`-Klasse.
1. Erstellen Sie eine Instance der `DescribeTableRequest`-Klasse, um die Anforderungsinformationen bereitzustellen. Sie müssen den Tabellennamen angeben.
1. Führen Sie die `describeTable`-Methode aus, indem das Anforderungsobjekt als Parameter festgelegt wird.
Im folgenden C\$1-Codebeispiel werden die vorherigen Schritte veranschaulicht.
**Example**
```
AmazonDynamoDBClient client = new AmazonDynamoDBClient();
string tableName = "Music";
DescribeTableResponse response = client.DescribeTable(new DescribeTableRequest() { TableName = tableName });
List localSecondaryIndexes =
response.DescribeTableResult.Table.LocalSecondaryIndexes;
// This code snippet will work for multiple indexes, even though
// there is only one index in this example.
foreach (LocalSecondaryIndexDescription lsiDescription in localSecondaryIndexes)
{
Console.WriteLine("Info for index " + lsiDescription.IndexName + ":");
foreach (KeySchemaElement kse in lsiDescription.KeySchema)
{
Console.WriteLine("\t" + kse.AttributeName + ": key type is " + kse.KeyType);
}
Projection projection = lsiDescription.Projection;
Console.WriteLine("\tThe projection type is: " + projection.ProjectionType);
if (projection.ProjectionType.ToString().Equals("INCLUDE"))
{
Console.WriteLine("\t\tThe non-key projected attributes are:");
foreach (String s in projection.NonKeyAttributes)
{
Console.WriteLine("\t\t" + s);
}
}
}
```
## Abfragen eines lokalen sekundären Indexes
Sie können `Query` für einen lokalen sekundären Index genauso nutzen, wie Sie `Query` für eine Tabelle nutzen. Sie müssen den Indexnamen, die Abfragekriterien für den Indexsortierschlüssel und die Attribute angeben, die Sie zurückgeben möchten. In diesem Beispiel ist der Index `AlbumTitleIndex` und der Indexsortierschlüssel `AlbumTitle`.
Die einzigen zurückgegebenen Attribute sind die, die in den Index projiziert wurden. Sie könnten diese Abfrage ändern, um auch Nicht-Schlüsselattribute auszuwählen, aber dies würde eine Tabellenabrufaktivität erfordern, die relativ teuer ist. Weitere Informationen zum Abrufen von Tabellen finden Sie unter [Attributprojektionen](LSI.md#LSI.Projections)
Im Folgenden werden die Schritte zur Abfrage eines lokalen sekundären Indizes mithilfe der .NET-Low-Level-API dargelegt.
1. Erstellen Sie eine Instance der `AmazonDynamoDBClient`-Klasse.
1. Erstellen Sie eine Instance der `QueryRequest`-Klasse, um die Anforderungsinformationen bereitzustellen.
1. Führen Sie die `query`-Methode aus, indem das Anforderungsobjekt als Parameter festgelegt wird.
Im folgenden C\$1-Codebeispiel werden die vorherigen Schritte veranschaulicht.
**Example**
```
QueryRequest queryRequest = new QueryRequest
{
TableName = "Music",
IndexName = "AlbumTitleIndex",
Select = "ALL_ATTRIBUTES",
ScanIndexForward = true,
KeyConditionExpression = "Artist = :v_artist and AlbumTitle = :v_title",
ExpressionAttributeValues = new Dictionary()
{
{":v_artist",new AttributeValue {S = "Acme Band"}},
{":v_title",new AttributeValue {S = "Songs About Life"}}
},
};
QueryResponse response = client.Query(queryRequest);
foreach (var attribs in response.Items)
{
foreach (var attrib in attribs)
{
Console.WriteLine(attrib.Key + " ---> " + attrib.Value.S);
}
Console.WriteLine();
}
```
# Beispiel: Lokale sekundäre Indizes mithilfe der Low-Level-API AWS SDK für .NET
Das folgende C\$1-Codebeispiel zeigt, wie Sie mit lokalen sekundären Indizes in Amazon DynamoDB arbeiten. Das Beispiel erstellt eine Tabelle mit dem Namen `CustomerOrders` mit `CustomerId` als Partitionsschlüssel und `OrderId` als Sortierschlüssel. Es gibt zwei lokale sekundäre Indizes in dieser Tabelle:
+ `OrderCreationDateIndex` – der Sortierschlüssel ist `OrderCreationDate` und die folgenden Attribute werden in den Index projiziert:
+ `ProductCategory`
+ `ProductName`
+ `OrderStatus`
+ `ShipmentTrackingId`
+ `IsOpenIndex` – der Sortierschlüssel ist `IsOpen` und alle Tabellenattribute werden in den Index projiziert.
Nachdem die `CustomerOrders`-Tabelle erstellt wurde, lädt das Programm die Tabelle mit Daten, die Kundenaufträge darstellen. Mit If Then werden die Daten unter Verwendung der lokalen sekundären Indizes abgefragt. Schließlich löscht das Programm die `CustomerOrders`-Tabelle.
step-by-stepAnweisungen zum Testen des folgenden Beispiels finden Sie unter. [.NET-Codebeispiele](CodeSamples.DotNet.md)
**Example**
```
using System;
using System.Collections.Generic;
using System.Linq;
using Amazon.DynamoDBv2;
using Amazon.DynamoDBv2.DataModel;
using Amazon.DynamoDBv2.DocumentModel;
using Amazon.DynamoDBv2.Model;
using Amazon.Runtime;
using Amazon.SecurityToken;
namespace com.amazonaws.codesamples
{
class LowLevelLocalSecondaryIndexExample
{
private static AmazonDynamoDBClient client = new AmazonDynamoDBClient();
private static string tableName = "CustomerOrders";
static void Main(string[] args)
{
try
{
CreateTable();
LoadData();
Query(null);
Query("IsOpenIndex");
Query("OrderCreationDateIndex");
DeleteTable(tableName);
Console.WriteLine("To continue, press Enter");
Console.ReadLine();
}
catch (AmazonDynamoDBException e) { Console.WriteLine(e.Message); }
catch (AmazonServiceException e) { Console.WriteLine(e.Message); }
catch (Exception e) { Console.WriteLine(e.Message); }
}
private static void CreateTable()
{
var createTableRequest =
new CreateTableRequest()
{
TableName = tableName,
ProvisionedThroughput =
new ProvisionedThroughput()
{
ReadCapacityUnits = (long)1,
WriteCapacityUnits = (long)1
}
};
var attributeDefinitions = new List()
{
// Attribute definitions for table primary key
{ new AttributeDefinition() {
AttributeName = "CustomerId", AttributeType = "S"
} },
{ new AttributeDefinition() {
AttributeName = "OrderId", AttributeType = "N"
} },
// Attribute definitions for index primary key
{ new AttributeDefinition() {
AttributeName = "OrderCreationDate", AttributeType = "N"
} },
{ new AttributeDefinition() {
AttributeName = "IsOpen", AttributeType = "N"
}}
};
createTableRequest.AttributeDefinitions = attributeDefinitions;
// Key schema for table
var tableKeySchema = new List()
{
{ new KeySchemaElement() {
AttributeName = "CustomerId", KeyType = "HASH"
} }, //Partition key
{ new KeySchemaElement() {
AttributeName = "OrderId", KeyType = "RANGE"
} } //Sort key
};
createTableRequest.KeySchema = tableKeySchema;
var localSecondaryIndexes = new List();
// OrderCreationDateIndex
LocalSecondaryIndex orderCreationDateIndex = new LocalSecondaryIndex()
{
IndexName = "OrderCreationDateIndex"
};
// Key schema for OrderCreationDateIndex
var indexKeySchema = new List()
{
{ new KeySchemaElement() {
AttributeName = "CustomerId", KeyType = "HASH"
} }, //Partition key
{ new KeySchemaElement() {
AttributeName = "OrderCreationDate", KeyType = "RANGE"
} } //Sort key
};
orderCreationDateIndex.KeySchema = indexKeySchema;
// Projection (with list of projected attributes) for
// OrderCreationDateIndex
var projection = new Projection()
{
ProjectionType = "INCLUDE"
};
var nonKeyAttributes = new List()
{
"ProductCategory",
"ProductName"
};
projection.NonKeyAttributes = nonKeyAttributes;
orderCreationDateIndex.Projection = projection;
localSecondaryIndexes.Add(orderCreationDateIndex);
// IsOpenIndex
LocalSecondaryIndex isOpenIndex
= new LocalSecondaryIndex()
{
IndexName = "IsOpenIndex"
};
// Key schema for IsOpenIndex
indexKeySchema = new List()
{
{ new KeySchemaElement() {
AttributeName = "CustomerId", KeyType = "HASH"
}}, //Partition key
{ new KeySchemaElement() {
AttributeName = "IsOpen", KeyType = "RANGE"
}} //Sort key
};
// Projection (all attributes) for IsOpenIndex
projection = new Projection()
{
ProjectionType = "ALL"
};
isOpenIndex.KeySchema = indexKeySchema;
isOpenIndex.Projection = projection;
localSecondaryIndexes.Add(isOpenIndex);
// Add index definitions to CreateTable request
createTableRequest.LocalSecondaryIndexes = localSecondaryIndexes;
Console.WriteLine("Creating table " + tableName + "...");
client.CreateTable(createTableRequest);
WaitUntilTableReady(tableName);
}
public static void Query(string indexName)
{
Console.WriteLine("\n***********************************************************\n");
Console.WriteLine("Querying table " + tableName + "...");
QueryRequest queryRequest = new QueryRequest()
{
TableName = tableName,
ConsistentRead = true,
ScanIndexForward = true,
ReturnConsumedCapacity = "TOTAL"
};
String keyConditionExpression = "CustomerId = :v_customerId";
Dictionary expressionAttributeValues = new Dictionary {
{":v_customerId", new AttributeValue {
S = "bob@example.com"
}}
};
if (indexName == "IsOpenIndex")
{
Console.WriteLine("\nUsing index: '" + indexName
+ "': Bob's orders that are open.");
Console.WriteLine("Only a user-specified list of attributes are returned\n");
queryRequest.IndexName = indexName;
keyConditionExpression += " and IsOpen = :v_isOpen";
expressionAttributeValues.Add(":v_isOpen", new AttributeValue
{
N = "1"
});
// ProjectionExpression
queryRequest.ProjectionExpression = "OrderCreationDate, ProductCategory, ProductName, OrderStatus";
}
else if (indexName == "OrderCreationDateIndex")
{
Console.WriteLine("\nUsing index: '" + indexName
+ "': Bob's orders that were placed after 01/31/2013.");
Console.WriteLine("Only the projected attributes are returned\n");
queryRequest.IndexName = indexName;
keyConditionExpression += " and OrderCreationDate > :v_Date";
expressionAttributeValues.Add(":v_Date", new AttributeValue
{
N = "20130131"
});
// Select
queryRequest.Select = "ALL_PROJECTED_ATTRIBUTES";
}
else
{
Console.WriteLine("\nNo index: All of Bob's orders, by OrderId:\n");
}
queryRequest.KeyConditionExpression = keyConditionExpression;
queryRequest.ExpressionAttributeValues = expressionAttributeValues;
var result = client.Query(queryRequest);
var items = result.Items;
foreach (var currentItem in items)
{
foreach (string attr in currentItem.Keys)
{
if (attr == "OrderId" || attr == "IsOpen"
|| attr == "OrderCreationDate")
{
Console.WriteLine(attr + "---> " + currentItem[attr].N);
}
else
{
Console.WriteLine(attr + "---> " + currentItem[attr].S);
}
}
Console.WriteLine();
}
Console.WriteLine("\nConsumed capacity: " + result.ConsumedCapacity.CapacityUnits + "\n");
}
private static void DeleteTable(string tableName)
{
Console.WriteLine("Deleting table " + tableName + "...");
client.DeleteTable(new DeleteTableRequest()
{
TableName = tableName
});
WaitForTableToBeDeleted(tableName);
}
public static void LoadData()
{
Console.WriteLine("Loading data into table " + tableName + "...");
Dictionary item = new Dictionary();
item["CustomerId"] = new AttributeValue
{
S = "alice@example.com"
};
item["OrderId"] = new AttributeValue
{
N = "1"
};
item["IsOpen"] = new AttributeValue
{
N = "1"
};
item["OrderCreationDate"] = new AttributeValue
{
N = "20130101"
};
item["ProductCategory"] = new AttributeValue
{
S = "Book"
};
item["ProductName"] = new AttributeValue
{
S = "The Great Outdoors"
};
item["OrderStatus"] = new AttributeValue
{
S = "PACKING ITEMS"
};
/* no ShipmentTrackingId attribute */
PutItemRequest putItemRequest = new PutItemRequest
{
TableName = tableName,
Item = item,
ReturnItemCollectionMetrics = "SIZE"
};
client.PutItem(putItemRequest);
item = new Dictionary();
item["CustomerId"] = new AttributeValue
{
S = "alice@example.com"
};
item["OrderId"] = new AttributeValue
{
N = "2"
};
item["IsOpen"] = new AttributeValue
{
N = "1"
};
item["OrderCreationDate"] = new AttributeValue
{
N = "20130221"
};
item["ProductCategory"] = new AttributeValue
{
S = "Bike"
};
item["ProductName"] = new AttributeValue
{
S = "Super Mountain"
};
item["OrderStatus"] = new AttributeValue
{
S = "ORDER RECEIVED"
};
/* no ShipmentTrackingId attribute */
putItemRequest = new PutItemRequest
{
TableName = tableName,
Item = item,
ReturnItemCollectionMetrics = "SIZE"
};
client.PutItem(putItemRequest);
item = new Dictionary();
item["CustomerId"] = new AttributeValue
{
S = "alice@example.com"
};
item["OrderId"] = new AttributeValue
{
N = "3"
};
/* no IsOpen attribute */
item["OrderCreationDate"] = new AttributeValue
{
N = "20130304"
};
item["ProductCategory"] = new AttributeValue
{
S = "Music"
};
item["ProductName"] = new AttributeValue
{
S = "A Quiet Interlude"
};
item["OrderStatus"] = new AttributeValue
{
S = "IN TRANSIT"
};
item["ShipmentTrackingId"] = new AttributeValue
{
S = "176493"
};
putItemRequest = new PutItemRequest
{
TableName = tableName,
Item = item,
ReturnItemCollectionMetrics = "SIZE"
};
client.PutItem(putItemRequest);
item = new Dictionary();
item["CustomerId"] = new AttributeValue
{
S = "bob@example.com"
};
item["OrderId"] = new AttributeValue
{
N = "1"
};
/* no IsOpen attribute */
item["OrderCreationDate"] = new AttributeValue
{
N = "20130111"
};
item["ProductCategory"] = new AttributeValue
{
S = "Movie"
};
item["ProductName"] = new AttributeValue
{
S = "Calm Before The Storm"
};
item["OrderStatus"] = new AttributeValue
{
S = "SHIPPING DELAY"
};
item["ShipmentTrackingId"] = new AttributeValue
{
S = "859323"
};
putItemRequest = new PutItemRequest
{
TableName = tableName,
Item = item,
ReturnItemCollectionMetrics = "SIZE"
};
client.PutItem(putItemRequest);
item = new Dictionary();
item["CustomerId"] = new AttributeValue
{
S = "bob@example.com"
};
item["OrderId"] = new AttributeValue
{
N = "2"
};
/* no IsOpen attribute */
item["OrderCreationDate"] = new AttributeValue
{
N = "20130124"
};
item["ProductCategory"] = new AttributeValue
{
S = "Music"
};
item["ProductName"] = new AttributeValue
{
S = "E-Z Listening"
};
item["OrderStatus"] = new AttributeValue
{
S = "DELIVERED"
};
item["ShipmentTrackingId"] = new AttributeValue
{
S = "756943"
};
putItemRequest = new PutItemRequest
{
TableName = tableName,
Item = item,
ReturnItemCollectionMetrics = "SIZE"
};
client.PutItem(putItemRequest);
item = new Dictionary();
item["CustomerId"] = new AttributeValue
{
S = "bob@example.com"
};
item["OrderId"] = new AttributeValue
{
N = "3"
};
/* no IsOpen attribute */
item["OrderCreationDate"] = new AttributeValue
{
N = "20130221"
};
item["ProductCategory"] = new AttributeValue
{
S = "Music"
};
item["ProductName"] = new AttributeValue
{
S = "Symphony 9"
};
item["OrderStatus"] = new AttributeValue
{
S = "DELIVERED"
};
item["ShipmentTrackingId"] = new AttributeValue
{
S = "645193"
};
putItemRequest = new PutItemRequest
{
TableName = tableName,
Item = item,
ReturnItemCollectionMetrics = "SIZE"
};
client.PutItem(putItemRequest);
item = new Dictionary();
item["CustomerId"] = new AttributeValue
{
S = "bob@example.com"
};
item["OrderId"] = new AttributeValue
{
N = "4"
};
item["IsOpen"] = new AttributeValue
{
N = "1"
};
item["OrderCreationDate"] = new AttributeValue
{
N = "20130222"
};
item["ProductCategory"] = new AttributeValue
{
S = "Hardware"
};
item["ProductName"] = new AttributeValue
{
S = "Extra Heavy Hammer"
};
item["OrderStatus"] = new AttributeValue
{
S = "PACKING ITEMS"
};
/* no ShipmentTrackingId attribute */
putItemRequest = new PutItemRequest
{
TableName = tableName,
Item = item,
ReturnItemCollectionMetrics = "SIZE"
};
client.PutItem(putItemRequest);
item = new Dictionary();
item["CustomerId"] = new AttributeValue
{
S = "bob@example.com"
};
item["OrderId"] = new AttributeValue
{
N = "5"
};
/* no IsOpen attribute */
item["OrderCreationDate"] = new AttributeValue
{
N = "20130309"
};
item["ProductCategory"] = new AttributeValue
{
S = "Book"
};
item["ProductName"] = new AttributeValue
{
S = "How To Cook"
};
item["OrderStatus"] = new AttributeValue
{
S = "IN TRANSIT"
};
item["ShipmentTrackingId"] = new AttributeValue
{
S = "440185"
};
putItemRequest = new PutItemRequest
{
TableName = tableName,
Item = item,
ReturnItemCollectionMetrics = "SIZE"
};
client.PutItem(putItemRequest);
item = new Dictionary();
item["CustomerId"] = new AttributeValue
{
S = "bob@example.com"
};
item["OrderId"] = new AttributeValue
{
N = "6"
};
/* no IsOpen attribute */
item["OrderCreationDate"] = new AttributeValue
{
N = "20130318"
};
item["ProductCategory"] = new AttributeValue
{
S = "Luggage"
};
item["ProductName"] = new AttributeValue
{
S = "Really Big Suitcase"
};
item["OrderStatus"] = new AttributeValue
{
S = "DELIVERED"
};
item["ShipmentTrackingId"] = new AttributeValue
{
S = "893927"
};
putItemRequest = new PutItemRequest
{
TableName = tableName,
Item = item,
ReturnItemCollectionMetrics = "SIZE"
};
client.PutItem(putItemRequest);
item = new Dictionary();
item["CustomerId"] = new AttributeValue
{
S = "bob@example.com"
};
item["OrderId"] = new AttributeValue
{
N = "7"
};
/* no IsOpen attribute */
item["OrderCreationDate"] = new AttributeValue
{
N = "20130324"
};
item["ProductCategory"] = new AttributeValue
{
S = "Golf"
};
item["ProductName"] = new AttributeValue
{
S = "PGA Pro II"
};
item["OrderStatus"] = new AttributeValue
{
S = "OUT FOR DELIVERY"
};
item["ShipmentTrackingId"] = new AttributeValue
{
S = "383283"
};
putItemRequest = new PutItemRequest
{
TableName = tableName,
Item = item,
ReturnItemCollectionMetrics = "SIZE"
};
client.PutItem(putItemRequest);
}
private static void WaitUntilTableReady(string tableName)
{
string status = null;
// Let us wait until table is created. Call DescribeTable.
do
{
System.Threading.Thread.Sleep(5000); // Wait 5 seconds.
try
{
var res = client.DescribeTable(new DescribeTableRequest
{
TableName = tableName
});
Console.WriteLine("Table name: {0}, status: {1}",
res.Table.TableName,
res.Table.TableStatus);
status = res.Table.TableStatus;
}
catch (ResourceNotFoundException)
{
// DescribeTable is eventually consistent. So you might
// get resource not found. So we handle the potential exception.
}
} while (status != "ACTIVE");
}
private static void WaitForTableToBeDeleted(string tableName)
{
bool tablePresent = true;
while (tablePresent)
{
System.Threading.Thread.Sleep(5000); // Wait 5 seconds.
try
{
var res = client.DescribeTable(new DescribeTableRequest
{
TableName = tableName
});
Console.WriteLine("Table name: {0}, status: {1}",
res.Table.TableName,
res.Table.TableStatus);
}
catch (ResourceNotFoundException)
{
tablePresent = false;
}
}
}
}
}
```
# Arbeiten mit lokalen sekundären Indizes in der DynamoDB-AWS CLI
Sie können die AWS CLI zum Erstellen einer Amazon-DynamoDB-Tabelle mit einem oder mehreren lokalen sekundären Indizes, zum Beschreiben der Indizes in der Tabelle und zur Ausführung von Abfragen mithilfe des Indizes, verwenden.
**Topics**
+ [Erstellen einer Tabelle mit einem lokalen sekundären Index](#LCICli.CreateTableWithIndex)
+ [Beschreiben einer Tabelle mit einem lokalen sekundären Index](#LCICli.DescribeTableWithIndex)
+ [Abfragen eines lokalen sekundären Indexes](#LCICli.QueryAnIndex)
## Erstellen einer Tabelle mit einem lokalen sekundären Index
Lokale sekundäre Indizes müssen gleichzeitig mit dem Erstellen einer Tabelle erstellt werden. Zu diesem Zweck verwenden Sie den `create-table`-Parameter und geben Ihre Spezifikationen für ein oder mehrere lokale sekundäre Indizes an. Das folgende Beispiel erstellt eine Tabelle (`Music`), die Informationen über Songs in einer Musiksammlung enthält. Der Partitionsschlüssel ist `Artist` und der Sortierschlüssel `SongTitle`. Ein sekundärer Index, `AlbumTitleIndex` auf dem `AlbumTitle`-Attribut, erleichtert Abfragen nach Albumtitel.
```
aws dynamodb create-table \
--table-name Music \
--attribute-definitions AttributeName=Artist,AttributeType=S AttributeName=SongTitle,AttributeType=S \
AttributeName=AlbumTitle,AttributeType=S \
--key-schema AttributeName=Artist,KeyType=HASH AttributeName=SongTitle,KeyType=RANGE \
--provisioned-throughput \
ReadCapacityUnits=10,WriteCapacityUnits=5 \
--local-secondary-indexes \
"[{\"IndexName\": \"AlbumTitleIndex\",
\"KeySchema\":[{\"AttributeName\":\"Artist\",\"KeyType\":\"HASH\"},
{\"AttributeName\":\"AlbumTitle\",\"KeyType\":\"RANGE\"}],
\"Projection\":{\"ProjectionType\":\"INCLUDE\", \"NonKeyAttributes\":[\"Genre\", \"Year\"]}}]"
```
Sie müssen warten bis DynamoDB die Tabelle erstellt und den Tabellenstatus auf `ACTIVE` setzt. Im Anschluss können Sie die Daten in der Tabelle ablegen. Mit [describe-table](https://docs.aws.amazon.com/cli/latest/reference/dynamodb/describe-table.html) können Sie den Status der Tabellenerstellung ermitteln.
## Beschreiben einer Tabelle mit einem lokalen sekundären Index
Um Informationen zu lokalen sekundären Indizes in einer Tabelle zu erhalten, verwenden Sie den Parameter `describe-table`. Sie können auf den Namen, das Schlüsselschema und die projizierten Attribute von jedem Index zugreifen.
```
aws dynamodb describe-table --table-name Music
```
## Abfragen eines lokalen sekundären Indexes
Sie können die Operation `query` für einen lokalen sekundären Index genauso nutzen, wie Sie `query` für eine Tabelle nutzen. Sie müssen den Indexnamen, die Abfragekriterien für den Indexsortierschlüssel und die Attribute angeben, die Sie zurückgeben möchten. In diesem Beispiel ist der Index `AlbumTitleIndex` und der Indexsortierschlüssel `AlbumTitle`.
Die einzigen zurückgegebenen Attribute sind die, die in den Index projiziert wurden. Sie könnten diese Abfrage ändern, um auch Nicht-Schlüsselattribute auszuwählen, aber dies würde eine Tabellenabrufaktivität erfordern, die relativ teuer ist. Weitere Informationen zum Abrufen von Tabellen finden Sie unter [Attributprojektionen](LSI.md#LSI.Projections).
```
aws dynamodb query \
--table-name Music \
--index-name AlbumTitleIndex \
--key-condition-expression "Artist = :v_artist and AlbumTitle = :v_title" \
--expression-attribute-values '{":v_artist":{"S":"Acme Band"},":v_title":{"S":"Songs About Life"} }'
```
# Verwalten komplexer Workflows mit DynamoDB-Transaktionen
Amazon DynamoDB-Transaktionen vereinfachen die Entwicklererfahrung, wenn sie koordinierte all-or-nothing Änderungen an mehreren Elementen sowohl innerhalb als auch tabellenübergreifend vornehmen müssen. Transaktionen ermöglichen in DynamoDB Atomarität, Konsistenz, Isolation und Haltbarkeit (ACID), wodurch Sie die Richtigkeit der Daten in Ihren Anwendungen einfacher verwalten können.
Sie können das transaktionale Lesen und Schreiben von DynamoDB verwenden, APIs um komplexe Geschäftsabläufe zu verwalten, bei denen mehrere Elemente in einem einzigen Vorgang hinzugefügt, aktualisiert oder gelöscht werden müssen. all-or-nothing Ein Entwickler von Videospielen kann so beispielsweise gewährleisten, dass die Profile der Spieler korrekt aktualisiert werden, wenn sie Elemente in einem Spiel austauschen oder Käufe aus einem Spiel heraus tätigen.
Mit der transaktionalen Schreib-API können Sie mehrere `Put`, `Update`-, `Delete`- und `ConditionCheck`-Aktionen gruppieren. Anschließend können Sie sie als eine einzige `TransactWriteItems`-Operation übermitteln, die entweder als Ganzes erfolgreich ist oder fehlschlägt. Dies gilt auch für mehrere `Get`-Aktionen, die Sie als einzige `TransactGetItems`-Operation gruppieren und übermitteln können.
Es fallen keine zusätzlichen Kosten für das Aktivieren von Transaktionen für Ihre DynamoDB-Tabellen an. Sie zahlen nur für Lese- oder Schreibvorgänge, die Teil Ihrer Transaktion sind. DynamoDB führt zwei zugrunde liegende Lese- oder Schreibvorgänge für jedes Element in der Transaktion aus: einen zum Vorbereiten der Transaktion und einen zum Festschreiben der Transaktion. Diese beiden zugrunde liegenden read/write Operationen sind in Ihren CloudWatch Amazon-Metriken sichtbar.
Um mit DynamoDB-Transaktionen zu beginnen, laden Sie das neueste AWS SDK oder das AWS Command Line Interface ()AWS CLI herunter. Befolgen Sie dann das Verfahren unter [DynamoDB-Transaktionen-Beispiel](transaction-example.md).
Die folgenden Abschnitte bieten einen detaillierten Überblick über die Transaktion APIs und darüber, wie Sie sie in DynamoDB verwenden können.
**Topics**
+ [Funktionsweise](transaction-apis.md)
+ [Verwenden von IAM mit Transaktionen](transaction-apis-iam.md)
+ [Beispiel-Code](transaction-example.md)
# Amazon DynamoDB Transactions: Funktionsweise
Mit Amazon DynamoDB-Transaktionen können Sie mehrere Aktionen gruppieren und sie als einzelne all-or-nothing `TransactWriteItems` oder `TransactGetItems` Operation einreichen. Die folgenden Abschnitte beschreiben API-Produktionen, Kapazitätsverwaltung, bewährte Methoden und andere Details zur Verwendung von Transaktionsoperationen in DynamoDB.
**Topics**
+ [TransactWriteItems API](#transaction-apis-txwriteitems)
+ [TransactGetItems API](#transaction-apis-txgetitems)
+ [Isolationsstufen für DynamoDB-Transaktionen](#transaction-isolation)
+ [Handhabung von Transaktionskonflikten in DynamoDB](#transaction-conflict-handling)
+ [Verwenden von Transactional APIs in DynamoDB Accelerator (DAX)](#transaction-apis-dax)
+ [Kapazitätsverwaltung für Transaktionen](#transaction-capacity-handling)
+ [Bewährte Methoden für Transaktionen](#transaction-best-practices)
+ [Verwenden Sie transaktionale Tabellen APIs mit globalen Tabellen](#transaction-integration)
+ [DynamoDB-Transaktionen im Vergleich zur AWSLabs Transactions-Clientbibliothek](#transaction-vs-library)
## TransactWriteItems API
`TransactWriteItems`ist eine synchrone und idempotente Schreiboperation, die bis zu 100 Schreibaktionen in einer einzigen Operation gruppiert. all-or-nothing Diese Aktionen können auf bis zu 100 verschiedene Elemente in einer oder mehreren DynamoDB-Tabellen innerhalb desselben AWS Kontos und in derselben Region abzielen. Die aggregierte Größe der Elemente in der Transaktion darf 4 MB nicht übersteigen. Die Aktionen werden atomarisch ausgeführt, d. h. entweder sind alle von ihnen oder keine von ihnen erfolgreich.
**Anmerkung**
Eine `TransactWriteItems`-Operation unterscheidet sich darin von einer `BatchWriteItem`-Operation, dass alle darin enthaltenen Aktionen erfolgreich ausgeführt werden müssen, damit irgendwelche Änderungen vorgenommen werden. Bei einer `BatchWriteItem`-Operation ist es dagegen möglich, dass nur einige der Aktionen im Stapel erfolgreich sind und andere fehlschlagen.
Transaktionen können nicht mit Indizes ausgeführt werden.
Sie können nicht in derselben Transaktion mit mehreren Operationen auf das gleiche Element abzielen. Beispiel: In derselben Transaktion ist es nicht möglich eine `ConditionCheck`- sowie eine `Update`-Aktion für dasselbe Element auszuführen.
Sie können die folgenden Aktionstypen zu einer Transaktion hinzufügen:
+ `Put` – Initiiert eine `PutItem`-Produktion, um bedingungsabhängig oder bedingungslos ein neues Element zu erstellen oder ein altes Element durch ein neues Element zu ersetzen.
+ `Update` – Initiiert eine `UpdateItem`-Produktion, um die Attribute eines vorhandenen Elements zu bearbeiten oder ein neues Element zur Tabelle hinzuzufügen, sofern noch nicht vorhanden. Mit dieser Aktion können Sie Attribute für ein vorhandenes Element bedingungsabhängig oder bedingungslos hinzufügen, löschen oder aktualisieren.
+ `Delete` – Initiiert eine `DeleteItem`-Produktion,, um ein einzelnes Element über seinen Primärschlüssel in einer Tabelle zu löschen.
+ `ConditionCheck` – Überprüft, ob ein Element vorhanden ist, oder überprüft die Bedingung bestimmter Attribute des Elements.
Wenn eine Transaktion in DynamoDB abgeschlossen ist, werden ihre Änderungen an globale Sekundärindizes (GSIs), Streams und Backups weitergegeben. Diese Übertragung erfolgt schrittweise: Stream-Datensätze aus derselben Transaktion können zu unterschiedlichen Zeiten erscheinen und sich mit Datensätzen aus anderen Transaktionen überlappen. Stream-Konsumenten sollten nicht davon ausgehen, dass Transaktionen vollständig sind oder dass es sich um Bestellgarantien handelt.
Um eine atomare Momentaufnahme der in einer Transaktion geänderten Elemente sicherzustellen, verwenden Sie den TransactGetItems Vorgang, um alle relevanten Elemente zusammen zu lesen. Dieser Vorgang bietet eine konsistente Ansicht der Daten, sodass Sie entweder alle Änderungen einer abgeschlossenen Transaktion oder gar keine sehen.
Da die Weitergabe nicht unmittelbar erfolgt, kann eine Tabelle, wenn sie aus Backup ([RestoreTableFromBackup](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_RestoreTableFromBackup.html)) wiederhergestellt oder zu einem Zeitpunkt ([ExportTableToPointInTime](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_ExportTableToPointInTime.html)) während der Weitergabe exportiert wird, nur einige der Änderungen enthalten, die während einer kürzlich durchgeführten Transaktion vorgenommen wurden.
### Idempotenz
Sie können optional ein Client-Token einschließen, wenn Sie einen `TransactWriteItems`-Aufruf machen, um sicherzustellen, dass die Anforderung *idempotent* ist. Durch idempotente Transaktionen lassen sich Anwendungsfehler vermeiden, falls dieselbe Operation aufgrund einer Verbindungszeitüberschreitung oder sonstiger Konnektivitätsprobleme mehrmals übermittelt wird.
Wenn der ursprüngliche `TransactWriteItems`-Aufruf erfolgreich war, werden nachfolgende `TransactWriteItems`-Aufrufe mit demselben Client-Token als erfolgreich zurückgegeben, ohne Änderungen vorzunehmen. Wenn der Parameter `ReturnConsumedCapacity` eingestellt ist, gibt der erstmalige `TransactWriteItems`-Aufruf die Anzahl an Schreibkapazitätseinheiten zurück, die beim Vornehmen der Änderungen verbraucht wurden. Nachfolgende `TransactWriteItems`-Aufrufe mit demselben Client-Token geben die Anzahl der Lesekapazitätseinheiten zurück, die beim Lesen des Elements verbraucht wurden.
**Wichtige Punkte bezüglich Idempotenz**
+ Ein Client-Token ist weitere 10 Minuten lang gültig, nachdem die Anforderung, die davon Gebrauch gemacht hat, beendet wurde. Nach 10 Minuten werden alle Anforderungen, die dasselbe Client-Token nutzen, als neue Anforderung angesehen. Deshalb sollten Sie dasselbe Client-Token nach 10 Minuten nicht erneut für dieselbe Anwendung verwenden.
+ Wenn Sie eine Anforderung mit demselben Client-Token innerhalb des 10-minütigen Idempotenzfenster wiederholen, aber einen anderen Anforderungsparameter ändern, gibt DynamoDB die Ausnahme `IdempotentParameterMismatch` zurück.
### Fehlerbehandlung beim Schreiben
Schreibtransaktionen schlagen unter den folgenden Umständen fehl:
+ Wenn eine Bedingung in einem der Bedingungsausdrücke nicht erfüllt wird.
+ Wenn ein Transaktionsvalidierungsfehler auftritt, da mehr als eine Aktion in derselben `TransactWriteItems`-Operation auf dasselbe Element abzielt.
+ Wenn eine `TransactWriteItems`-Anforderung mit einer andauernden `TransactWriteItems`-Operation an mindestens einem Element in der `TransactWriteItems`-Anforderung in Konflikt steht. In diesem Fall schlägt die Anfrage mit der Ausnahme `TransactionCanceledException` fehl.
+ Wenn für die durchzuführende Transaktion nicht genügend Kapazität bereitgestellt wird.
+ Wenn ein Element zu groß wird (größer als 400 KB) oder wenn ein lokaler sekundärer Index (LSI) zu groß wird oder wenn aufgrund der durch die Transaktion vorgenommenen Änderungen ein ähnlicher Validierungsfehler auftritt.
+ Wenn ein Benutzerfehler, wie z. B. ein ungültiges Datenformat, auftritt.
Weitere Informationen zum Umgang mit Konflikten mit `TransactWriteItems`-Operationen finden Sie unter [Handhabung von Transaktionskonflikten in DynamoDB](#transaction-conflict-handling).
## TransactGetItems API
`TransactGetItems` ist ein synchroner Lesevorgang, der bis zu 100 `Get`-Aktionen zusammengruppiert. Diese Aktionen können auf bis zu 100 verschiedene Elemente in einer oder mehreren DynamoDB-Tabellen innerhalb desselben AWS Kontos und derselben Region abzielen. Die aggregierte Größe der Elemente in der Transaktion darf 4 MB nicht überschreiten.
Die `Get`-Aktionen werden atomarisch durchgeführt, d. h. entweder sind alle von ihnen oder keine von ihnen erfolgreich:
+ `Get` – Initiiert eine `GetItem`-Operation, um einen Satz von Attributen für das Elemente mit dem angegebenen Primärschlüssel abzurufen. Wenn kein passendes Element gefunden wird, gibt `Get` keine Daten zurück.
### Fehlerbehandlung beim Lesen
Lesetransaktionen schlagen unter den folgenden Umständen fehl:
+ Wenn eine `TransactGetItems`-Anforderung mit einer andauernden `TransactWriteItems`-Operation an mindestens einem Element in der `TransactGetItems`-Anforderung in Konflikt steht. In diesem Fall schlägt die Anfrage mit der Ausnahme `TransactionCanceledException` fehl.
+ Wenn für die durchzuführende Transaktion nicht genügend Kapazität bereitgestellt wird.
+ Wenn ein Benutzerfehler, wie z. B. ein ungültiges Datenformat, auftritt.
Weitere Informationen zum Umgang mit Konflikten mit `TransactGetItems`-Operationen finden Sie unter [Handhabung von Transaktionskonflikten in DynamoDB](#transaction-conflict-handling).
## Isolationsstufen für DynamoDB-Transaktionen
Die Isolationsstufen von Transaktionsoperationen (`TransactWriteItems` oder `TransactGetItems`) und anderen Operationen sind folgende:
### SERIALIZABLE
Durch die Isolationsstufe *serializable* wird sichergestellt, dass die Ergebnisse mehrerer gleichzeitiger Operationen die gleichen sind, als würde eine Operation erst beginnen, nachdem die vorherige Operation beendet wurde.
Die serialisierbare Isolation findet zwischen den folgenden Arten von Operationen statt:
+ Zwischen Transaktionsoperationen und Standardschreibvorgängen (`PutItem`, `UpdateItem` oder `DeleteItem`).
+ Zwischen Transaktionsoperationen und Standardlesevorgängen (`GetItem`).
+ Zwischen einer `TransactWriteItems`-Operation und einer `TransactGetItems`-Operation.
Obwohl eine serialisierbare Isolation zwischen Transaktionsoperationen und einzelnen Standardschreibvorgängen in einer `BatchWriteItem`-Operation auftritt, findet keine serialisierbare Isolation zwischen der Transaktion und der `BatchWriteItem`-Operation als Einheit statt.
Dementsprechend ist die Isolationsstufe zwischen einer Transaktionsoperation und einzelnen `GetItems` in einer `BatchGetItem`-Operation serialisierbar. Die Isoloationsstufe zwischen der Transaktion und der `BatchGetItem`-Operation als Einheit ist aber *read-committed*.
Eine einzelne `GetItem`-Anforderung kann in Bezug auf eine `TransactWriteItems`-Anforderung auf eine von zwei Arten serialisiert werden, entweder vor oder nach der `TransactWriteItems`-Anforderung. Mehrere `GetItem`-Anforderungen, gegen Schlüssel in einem gleichzeitigen `TransactWriteItems`-Anfragen können in beliebiger Reihenfolge ausgeführt werden, und daher sind die Ergebnisse *read-committed*.
Wenn beispielsweise `GetItem`-Anforderungen für Element A und Element B gleichzeitig mit einer `TransactWriteItems`-Anforderung ausgeführt werden, die sowohl Element A als auch Element B ändert, gibt es vier Möglichkeiten:
+ Beide `GetItem`-Anforderungen werden vor der `TransactWriteItems`-Anforderung ausgeführt.
+ Beide `GetItem`-Anforderungen werden nach der `TransactWriteItems`-Anforderung ausgeführt.
+ `GetItem`-Anforderung für Element A wird vor der `TransactWriteItems`-Anforderung ausgeführt. Für Element B wird die `GetItem` nach `TransactWriteItems` ausgeführt.
+ `GetItem`-Anforderung für Element B wird vor der `TransactWriteItems`-Anforderung ausgeführt. Für Element A wird die `GetItem` nach `TransactWriteItems` ausgeführt.
Wenn die serialisierbare Isolationsstufe für mehrere `GetItem`-Anfragen bevorzugt wird, verwenden Sie `TransactGetItems`.
Wenn mehrere Elemente, die während der Übertragung Teil derselben Transaktionsschreibanfrage waren, nicht transaktionell gelesen werden, ist es möglich, dass Sie den neuen Status einiger Elemente und den alten Status der anderen Elemente lesen können. Sie können den neuen Status aller Elemente, die Teil der Transaktionsschreibanfrage waren, nur lesen, wenn eine erfolgreiche Antwort für den transaktionalen Schreibvorgang eingegangen ist, was darauf hinweist, dass die Transaktion abgeschlossen wurde.
Sobald die Transaktion erfolgreich abgeschlossen wurde und eine Antwort eingegangen ist, können nachfolgende, *letztendlich konsistente* Lesevorgänge aufgrund des Konsistenzmodells von DynamoDB für kurze Zeit immer noch den alten Status zurückgeben. Um sicherzustellen, dass unmittelbar nach einer Transaktion möglichst up-to-date viele Daten gelesen werden, sollten Sie Strongly [*Consistent Reads verwenden*](HowItWorks.ReadConsistency.md#HowItWorks.ReadConsistency.Strongly), indem Sie den Wert `ConsistentRead` auf true setzen.
### READ-COMMITTED
Durch die Isolation *Read-committed* wird sichergestellt, dass Lesevorgänge immer festgeschriebene Werte für ein Element zurückgeben – der Lesevorgang wird niemals eine Sicht auf das Element präsentieren, die einen Zustand aus einem letztlich nicht erfolgreichen transaktionalen Schreibvorgang darstellt. Die Isolation "Read-committed" verhindert keine Änderungen am Element direkt nach dem Lesevorgang.
Die Isolationsstufe ist read-committed zwischen allen Transaktionsoperationen und allen Lesevorgängen, die mehrere Standard-Lesevorgänge (`BatchGetItem`, `Query` oder `Scan`) umfassen. Wenn bei einem transaktionalen Schreibvorgang ein Element mitten in einer `BatchGetItem`-, `Query`- oder `Scan`-Operation aktualisiert wird, gibt der nachfolgende Teil des Lesevorgangs den neu festgeschriebenen Wert zurück (mit `ConsistentRead)` oder möglicherweise einem zuvor festgeschriebenem Wert (letztendlich konsistente Lesevorgänge).
### Zusammenfassung des Vorgangs
Die folgende Tabelle gibt einen Überblick über die Isolationsstufen zwischen einer Transaktionsoperation (`TransactWriteItems` oder `TransactGetItems`) und anderen Operationen.
| Operation | Isolationsstufe |
| --- | --- |
| `DeleteItem` | *Serializable* |
| `PutItem` | *Serializable* |
| `UpdateItem` | *Serializable* |
| `GetItem` | *Serializable* |
| `BatchGetItem` | *Read-committed*\$1 |
| `BatchWriteItem` | *NICHT Serializable*\$1 |
| `Query` | *Read-committed* |
| `Scan` | *Read-committed* |
| Andere Transaktionsoperationen | *Serializable* |
Mit einem Sternchen (\$1) markierte Stufen gelten für die Operation als Einheit. Einzelne Aktionen innerhalb dieser Operationen besitzen jedoch die Isolationsstufe *serializable*.
## Handhabung von Transaktionskonflikten in DynamoDB
Bei Anforderungen auf Elementebene kann für ein Element in einer Transaktion ein Transaktionskonflikt auftreten. Transaktionskonflikte können in den folgenden Szenarien auftreten:
+ Eine `PutItem`-, `UpdateItem`- oder `DeleteItem`-Anforderung für ein Element konfligiert mit einer laufenden `TransactWriteItems`-Anforderung, die dasselbe Element enthält.
+ Ein Element in einer `TransactWriteItems`-Anforderung ist Teil einer anderen laufenden `TransactWriteItems`-Anforderung.
+ Ein Element in einer `TransactGetItems`-Anforderung ist Teil einer laufenden `TransactWriteItems`-, `BatchWriteItem`-, `PutItem`-, `UpdateItem`- oder `DeleteItem`-Anforderung.
**Anmerkung**
Wenn eine `PutItem`-, `UpdateItem`- oder `DeleteItem`-Anforderung abgelehnt wird, schlägt die Anforderung mit einer `TransactionConflictException` fehl.
Wenn irgendeine Anforderung auf Elementebene in `TransactWriteItems` oder `TransactGetItems` abgelehnt wird, schlägt die Anforderung mit einer `TransactionCanceledException` fehl. Wenn diese Anfrage fehlschlägt, AWS SDKs wiederholen Sie die Anfrage nicht.
Wenn Sie den verwenden AWS SDK für Java, enthält die Ausnahme die Liste der [CancellationReasons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_CancellationReason.html), sortiert nach der Liste der Elemente im `TransactItems` Anforderungsparameter. Bei anderen Sprachen ist in der Fehlermeldung der Ausnahme eine Zeichenfolgendarstellung der Liste enthalten.
Wenn eine laufende `TransactWriteItems`- oder `TransactGetItems`-Operation mit einer gleichzeitigen `GetItem`-Anforderung im Konflikt steht, können beide Operationen erfolgreich durchgeführt werden.
Die [TransactionConflict CloudWatch Metrik](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html) wird für jede fehlgeschlagene Anfrage auf Elementebene inkrementiert.
## Verwenden von Transactional APIs in DynamoDB Accelerator (DAX)
`TransactWriteItems` und `TransactGetItems` werden in DynamoDB Accelerator (DAX) mit den gleichen Isolierungsstufen wie in DynamoDB unterstützt.
`TransactWriteItems` schreibt über DAX. DAX übergibt eineN `TransactWriteItems`-Aufruf an DynamoDB und gibt die Antwort zurück. Um den Cache nach dem Schreiben aufzufüllen, ruft DAX `TransactGetItems` im Hintergrund für jedes Element im `TransactWriteItems`-Vorgang auf, wodurch zusätzliche Lesekapazitätseinheiten verbraucht werden. (Weitere Informationen finden Sie unter [Kapazitätsverwaltung für Transaktionen](#transaction-capacity-handling).) Diese Funktion ermöglicht es, dass Ihre Anwendungslogik einfach bleibt. Außerdem können Sie so DAX für Transaktionsoperationen sowie für nicht transaktionale Operationen verwenden.
`TransactGetItems`-Aufrufe werden über DAX übergeben, ohne dass Elemente lokal zwischengespeichert werden. Dies ist dasselbe Verhalten wie beim stark konsistenten Lesen in DAX. APIs
## Kapazitätsverwaltung für Transaktionen
Es fallen keine zusätzlichen Kosten für das Aktivieren von Transaktionen für Ihre DynamoDB-Tabellen an. Sie zahlen nur für Lese- oder Schreibvorgänge, die Teil Ihrer Transaktion sind. DynamoDB führt zwei zugrunde liegende Lese- oder Schreibvorgänge für jedes Element in der Transaktion aus: einen zum Vorbereiten der Transaktion und einen zum Festschreiben der Transaktion. Die beiden zugrunde liegenden read/write Operationen sind in Ihren CloudWatch Amazon-Metriken sichtbar.
Planen Sie die zusätzlichen Lese- und Schreibvorgänge ein, die für Transaktionen erforderlich sind APIs , wenn Sie Kapazität für Ihre Tabellen bereitstellen. Angenommen, Ihre Anwendung führt eine Transaktion pro Sekunde aus und jede Transaktion schreibt drei 500-Byte-Elemente in Ihre Tabelle. Für jedes Element sind zwei Schreibkapazitätseinheiten (WCUs) erforderlich: eine für die Vorbereitung der Transaktion und eine für den Commit der Transaktion. Daher müssten Sie sechs für WCUs die Tabelle bereitstellen.
Wenn Sie im vorherigen Beispiel DynamoDB Accelerator (DAX) verwenden würden, würden Sie auch zwei Lesekapazitätseinheiten (RCUs) für jedes Element im `TransactWriteItems` Aufruf verwenden. Sie müssten also sechs weitere RCUs für die Tabelle bereitstellen.
Wenn Ihre Anwendung eine Lesetransaktion pro Sekunde ausführt und jede Transaktion drei 500-Byte-Elemente in Ihrer Tabelle liest, müssten Sie der Tabelle entsprechend sechs Lesekapazitätseinheiten (RCUs) bereitstellen. Zum Lesen jedes Elements sind zwei erforderlich RCUs: eine für die Vorbereitung der Transaktion und eine für die Ausführung der Transaktion.
Außerdem ist das SDK-Standardverhalten, Transaktionen im Falle der Ausnahme `TransactionInProgressException` wiederholt zu versuchen. Planen Sie die zusätzlichen Lesekapazitätseinheiten (RCUs) ein, die diese Wiederholungen verbrauchen. Dies gilt auch, wenn Sie Transaktionen in Ihrem eigenen Code mit einem `ClientRequestToken` wiederholt versuchen.
## Bewährte Methoden für Transaktionen
Erwägen Sie bei der Verwendung von DynamoDB-Transaktionen die folgenden empfohlenen Methoden.
+ Aktivieren Sie für Ihre Tabellen das Auto Scaling oder stellen Sie sicher, dass Sie die von Ihnen bereitgestellte Durchsatzkapazität zum Ausführen der beiden Lese- oder Schreibvorgänge für jedes Element in der Transaktion ausreicht.
+ Wenn Sie kein AWS bereitgestelltes SDK verwenden, fügen Sie bei einem `TransactWriteItems` Aufruf ein `ClientRequestToken` Attribut hinzu, um sicherzustellen, dass die Anfrage idempotent ist.
+ Gruppieren Sie Operationen nur dann als eine Transaktion zusammen, wenn dies wirklich erforderlich ist. Beispiel: Wenn eine einzelne Transaktion mit 10 Operationen in mehrere Transaktionen aufgeteilt werden kann, ohne die korrekte Funktionsweise der Anwendung zu gefährden, wird zur Aufteilung der Transaktion geraten. Weniger komplexe Transaktionen verbessern den Durchsatz und sind mit größerer Wahrscheinlichkeit erfolgreich.
+ Wenn mehrere Transaktionen dieselben Elemente gleichzeitig aktualisieren, können Konflikte entstehen, die zum Abbruch der Transaktionen führen. Wir empfehlen die folgenden bewährten DynamoDB-Methoden für die Datenmodellierung, um solche Konflikte zu minimieren.
+ Wenn ein Satz von Attributen häufig im Rahmen einer einzelnen Transaktion über mehrere Elemente hinweg aktualisiert wird, empfiehlt es sich, die Attribute in einem einzigen Element zusammenzugruppieren, um den Umfang der Transaktion zu reduzieren.
+ Vermeiden Sie es, Transaktionen zur massenweisen Aufnahme von Daten zu verwenden. `BatchWriteItem` eignet sich besser für Massenschreibvorgänge.
## Verwenden Sie transaktionale Tabellen APIs mit globalen Tabellen
Transaktionsoperationen bieten Garantien für Atomizität, Konsistenz, Isolation und Haltbarkeit (ACID) nur innerhalb der AWS Region, in der die Schreib-API aufgerufen wurde. Regionsübergreifende Transaktionen werden in globalen Tabellen nicht unterstützt. Angenommen, Sie haben eine globale Tabelle mit Replikaten in den Regionen USA Ost (Ohio) und USA West (Oregon) und Sie führen einen `TransactWriteItems`-Vorgang in der Region USA Ost (Nord-Virginia) aus. Dann sind möglicherweise teilweise abgeschlossene Transaktionen in der Region USA West (Oregon) zu beobachten, während Änderungen repliziert werden. Die Änderungen werden erst dann in die anderen Regionen repliziert, nachdem sie in der Quellregion in die Datenbank eingetragen wurden.
## DynamoDB-Transaktionen im Vergleich zur AWSLabs Transactions-Clientbibliothek
DynamoDB-Transaktionen bieten einen kostengünstigeren, robusteren und leistungsfähigeren Ersatz für die [AWSLabs](https://github.com/awslabs)Transactions-Clientbibliothek. Wir empfehlen Ihnen, Ihre Anwendungen so zu aktualisieren, dass sie die native, serverseitige Transaktion verwenden. APIs
# Verwenden von IAM mit DynamoDB-Transaktionen
Sie können AWS Identity and Access Management (IAM) verwenden, um die Aktionen einzuschränken, die Transaktionsvorgänge in Amazon DynamoDB ausführen können. Weitere Informationen zur Verwendung der IAM-Richtlinien in DynamoDB finden Sie unter [Identitätsbasierte Richtlinien für DynamoDB](security_iam_service-with-iam.md#security_iam_service-with-iam-id-based-policies).
Die Berechtigungen für die Aktionen `Put`, `Update`, `Delete` und `Get` werden durch die Berechtigungen geregelt, die für die zugrundeliegenden Operationen `PutItem`, `UpdateItem`, `DeleteItem` und `GetItem` verwendet werden. Für die Aktion `ConditionCheck` können Sie die Berechtigung `dynamodb:ConditionCheckItem` in den IAM-Richtlinien verwenden.
Es folgen Beispiele für die IAM-Richtlinien, die Sie zum Konfigurieren der DynamoDB-Transaktionen verwenden können.
## Beispiel 1: Zulassen von Transaktionsoperationen
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:ConditionCheckItem",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:GetItem"
],
"Resource": [
"arn:aws:dynamodb:*:*:table/table04"
]
}
]
}
```
------
## Beispiel 2: Zulassen nur von Transaktionsoperationen
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:ConditionCheckItem",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:GetItem"
],
"Resource": [
"arn:aws:dynamodb:*:*:table/table04"
],
"Condition": {
"ForAnyValue:StringEquals": {
"dynamodb:EnclosingOperation": [
"TransactWriteItems",
"TransactGetItems"
]
}
}
}
]
}
```
------
## Beispiel 3: Zulassen von nicht-transaktionalen Lese- und Schreibvorgängen und Blockieren von transaktionalen Lese- und Schreibvorgängen
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"dynamodb:ConditionCheckItem",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:GetItem"
],
"Resource": [
"arn:aws:dynamodb:*:*:table/table04"
],
"Condition": {
"ForAnyValue:StringEquals": {
"dynamodb:EnclosingOperation": [
"TransactWriteItems",
"TransactGetItems"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"dynamodb:PutItem",
"dynamodb:DeleteItem",
"dynamodb:GetItem",
"dynamodb:UpdateItem"
],
"Resource": [
"arn:aws:dynamodb:*:*:table/table04"
]
}
]
}
```
------
## Beispiel 4: Verhindern Sie, dass Informationen bei einem Fehler zurückgegeben werden ConditionCheck
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:ConditionCheckItem",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:GetItem"
],
"Resource": "arn:aws:dynamodb:*:*:table/table01",
"Condition": {
"StringEqualsIfExists": {
"dynamodb:ReturnValues": "NONE"
}
}
}
]
}
```
------
# DynamoDB-Transaktionen-Beispiel
Als Beispiel für eine Situation, in der Amazon DynamoDB Transactions nützlich sein können, betrachten Sie diese Java-Beispielanwendung für eine Online-Marketplace-Site.
Die Anwendung verfügt über drei DynamoDB-Tabellen im Backend:
+ `Customers` – In dieser Tabelle werden Details zu den Marketplace-Kunden gespeichert. Der Primärschlüssel ist ein `CustomerId` eine eindeutige ID.
+ `ProductCatalog` – In dieser Tabelle werden Details wie Preis und Verfügbarkeit zu den Produkten gespeichert, die auf der Marketplace-Site zum Verkauf angeboten werden. Der Primärschlüssel ist ein `ProductId` eine eindeutige ID.
+ `Orders` – In dieser Tabelle werden Details zu Bestellungen von der Marketplace-Site gespeichert. Der Primärschlüssel ist ein `OrderId` eine eindeutige ID.
## Bestellung
Die folgenden Codeausschnitte veranschaulichen, wie DynamoDB-Transaktionen verwendet werden, um die verschiedenen Schritte zu koordinieren, die zum Erstellen und Verarbeiten eines Auftrags erforderlich sind. Durch die Verwendung eines einzigen all-or-nothing Vorgangs wird sichergestellt, dass, falls ein Teil der Transaktion fehlschlägt, keine Aktionen in der Transaktion ausgeführt und keine Änderungen vorgenommen werden.
In diesem Beispiel richten Sie einen Auftrag eines Kunden ein, dessen `customerId` `09e8e9c8-ec48` ist. Anschließend führen Sie sie als einzelne Transaktion aus, indem Sie den folgenden einfachen Workflow für die Auftragsverarbeitung verwenden:
1. Stellen Sie sicher, dass die Kundennummer gültig ist.
1. Stellen Sie sicher, dass das Produkt `IN_STOCK` ist und aktualisieren Sie den Produktstatus auf `SOLD`.
1. Stellen Sie sicher, dass die Bestellung noch nicht vorhanden ist, und erstellen Sie den Auftrag.
### Kunden validieren
Definieren Sie zunächst eine Aktion, um zu überprüfen, ob ein Kunde mit `customerId` gleich `09e8e9c8-ec48` in der Kundentabelle vorhanden ist.
```
final String CUSTOMER_TABLE_NAME = "Customers";
final String CUSTOMER_PARTITION_KEY = "CustomerId";
final String customerId = "09e8e9c8-ec48";
final HashMap customerItemKey = new HashMap<>();
customerItemKey.put(CUSTOMER_PARTITION_KEY, new AttributeValue(customerId));
ConditionCheck checkCustomerValid = new ConditionCheck()
.withTableName(CUSTOMER_TABLE_NAME)
.withKey(customerItemKey)
.withConditionExpression("attribute_exists(" + CUSTOMER_PARTITION_KEY + ")");
```
### Aktualisieren des Produktstatus
Definieren Sie als Nächstes eine Aktion, um den Produktstatus auf `SOLD` zu aktualisieren, wenn die Bedingung, auf die der Produktstatus als `IN_STOCK`derzeit festgelegt ist, `true` ist. Das Festlegen des `ReturnValuesOnConditionCheckFailure`-Parameters gibt den Artikel zurück, wenn das Produktstatusattribut des Artikels nicht gleich `IN_STOCK` war.
```
final String PRODUCT_TABLE_NAME = "ProductCatalog";
final String PRODUCT_PARTITION_KEY = "ProductId";
HashMap productItemKey = new HashMap<>();
productItemKey.put(PRODUCT_PARTITION_KEY, new AttributeValue(productKey));
Map expressionAttributeValues = new HashMap<>();
expressionAttributeValues.put(":new_status", new AttributeValue("SOLD"));
expressionAttributeValues.put(":expected_status", new AttributeValue("IN_STOCK"));
Update markItemSold = new Update()
.withTableName(PRODUCT_TABLE_NAME)
.withKey(productItemKey)
.withUpdateExpression("SET ProductStatus = :new_status")
.withExpressionAttributeValues(expressionAttributeValues)
.withConditionExpression("ProductStatus = :expected_status")
.withReturnValuesOnConditionCheckFailure(ReturnValuesOnConditionCheckFailure.ALL_OLD);
```
### Bestellung erstellen
Schließlich erstellen Sie die Bestellung, solange eine Bestellung mit diesem `OrderId` nicht bereits existiert.
```
final String ORDER_PARTITION_KEY = "OrderId";
final String ORDER_TABLE_NAME = "Orders";
HashMap orderItem = new HashMap<>();
orderItem.put(ORDER_PARTITION_KEY, new AttributeValue(orderId));
orderItem.put(PRODUCT_PARTITION_KEY, new AttributeValue(productKey));
orderItem.put(CUSTOMER_PARTITION_KEY, new AttributeValue(customerId));
orderItem.put("OrderStatus", new AttributeValue("CONFIRMED"));
orderItem.put("OrderTotal", new AttributeValue("100"));
Put createOrder = new Put()
.withTableName(ORDER_TABLE_NAME)
.withItem(orderItem)
.withReturnValuesOnConditionCheckFailure(ReturnValuesOnConditionCheckFailure.ALL_OLD)
.withConditionExpression("attribute_not_exists(" + ORDER_PARTITION_KEY + ")");
```
### Ausführen der Transaktion
Das folgende Beispiel zeigt, wie die zuvor als einzelne all-or-nothing Operation definierten Aktionen ausgeführt werden.
```
Collection actions = Arrays.asList(
new TransactWriteItem().withConditionCheck(checkCustomerValid),
new TransactWriteItem().withUpdate(markItemSold),
new TransactWriteItem().withPut(createOrder));
TransactWriteItemsRequest placeOrderTransaction = new TransactWriteItemsRequest()
.withTransactItems(actions)
.withReturnConsumedCapacity(ReturnConsumedCapacity.TOTAL);
// Run the transaction and process the result.
try {
client.transactWriteItems(placeOrderTransaction);
System.out.println("Transaction Successful");
} catch (ResourceNotFoundException rnf) {
System.err.println("One of the table involved in the transaction is not found" + rnf.getMessage());
} catch (InternalServerErrorException ise) {
System.err.println("Internal Server Error" + ise.getMessage());
} catch (TransactionCanceledException tce) {
System.out.println("Transaction Canceled " + tce.getMessage());
}
```
## Lesen der Bestelldetails
Das folgende Beispiel zeigt, wie der abgeschlossene Auftrag transaktional über die `Orders`- und `ProductCatalog`-Tabellen gelesen wird.
```
HashMap productItemKey = new HashMap<>();
productItemKey.put(PRODUCT_PARTITION_KEY, new AttributeValue(productKey));
HashMap orderKey = new HashMap<>();
orderKey.put(ORDER_PARTITION_KEY, new AttributeValue(orderId));
Get readProductSold = new Get()
.withTableName(PRODUCT_TABLE_NAME)
.withKey(productItemKey);
Get readCreatedOrder = new Get()
.withTableName(ORDER_TABLE_NAME)
.withKey(orderKey);
Collection getActions = Arrays.asList(
new TransactGetItem().withGet(readProductSold),
new TransactGetItem().withGet(readCreatedOrder));
TransactGetItemsRequest readCompletedOrder = new TransactGetItemsRequest()
.withTransactItems(getActions)
.withReturnConsumedCapacity(ReturnConsumedCapacity.TOTAL);
// Run the transaction and process the result.
try {
TransactGetItemsResult result = client.transactGetItems(readCompletedOrder);
System.out.println(result.getResponses());
} catch (ResourceNotFoundException rnf) {
System.err.println("One of the table involved in the transaction is not found" + rnf.getMessage());
} catch (InternalServerErrorException ise) {
System.err.println("Internal Server Error" + ise.getMessage());
} catch (TransactionCanceledException tce) {
System.err.println("Transaction Canceled" + tce.getMessage());
}
```
# Ändern der Datenerfassung mit Amazon DynamoDB
Viele Anwendungen können zum Zeitpunkt einer Änderung von der Funktion zum Erfassen der Änderungen an den in einer DynamoDB-Tabelle gespeicherten Elementen profitieren. Im Folgenden sehen Sie einige Beispielanwendungsfälle.
+ Eine beliebte mobile App modifiziert Daten in einer DynamoDB-Tabelle mit einer Geschwindigkeit von Tausenden von Aktualisierungen pro Sekunde. Eine andere Anwendung erfasst und speichert Daten über diese Updates und stellt near-real-time Nutzungsmetriken für die mobile App bereit.
+ Eine Finanzanwendung ändert Börsendaten in einer DynamoDB-Tabelle. Verschiedene Anwendungen, die parallel laufen, verfolgen diese Veränderungen in Echtzeit value-at-risk, berechnen Portfolios und gleichen sie automatisch auf der Grundlage von Aktienkursbewegungen neu aus.
+ Sensoren in Transportfahrzeugen und Industrieanlagen senden Daten an eine DynamoDB-Tabelle. Verschiedene Anwendungen überwachen die Leistung und senden Messaging-Warnungen, wenn ein Problem erkannt wird, prognostizieren potenzielle Fehler durch Anwendung von Algorithmen für Machine Learning und komprimieren und archivieren Daten in Amazon Simple Storage Service (Amazon S3).
+ Eine Anwendung sendet Benachrichtigungen automatisch an die Mobilgeräte aller Freunde in einer Gruppe, sobald ein Freund ein neues Bild hochlädt.
+ Ein neuer Kunde fügt einer DynamoDB-Tabelle Daten hinzu. Dieses Ereignis ruft eine andere Anwendung auf, die eine Begrüßungs-E-Mail an den neuen Kunden sendet.
DynamoDB unterstützt das Streaming von Datensätzen für Änderungsdaten auf Elementebene in nahezu Echtzeit. Sie können Anwendungen erstellen, die diese Streams nutzen, und basierend auf dem Inhalt Maßnahmen ergreifen.
**Anmerkung**
Das Hinzufügen von Tags zu DynamoDB Streams und das Verwenden der [attributbasierte Zugriffskontrolle (ABAC)](access-control-resource-based.md) bei DynamoDB Streams werden nicht unterstützt.
Das folgende Video gibt Ihnen einen einführenden Einblick in das „Change Data Capture“-Konzept.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/VVv_-mZ5Ge8)
**Topics**
+ [Streaming-Optionen für die Erfassung der Änderung von Daten](#streamsmain.choose)
+ [Verwenden von Kinesis Data Streams zum Erfassen von Änderungen an DynamoDB](kds.md)
+ [Ändern Sie die Datenerfassung für DynamoDB Streams](Streams.md)
## Streaming-Optionen für die Erfassung der Änderung von Daten
DynamoDB bietet zwei Streaming-Modelle für die Erfassung der Änderung von Daten: Kinesis Data Streams für DynamoDB und DynamoDB Streams.
Um Ihnen bei der Auswahl der richtigen Lösung für Ihre Anwendung zu helfen, werden die Funktionen der einzelnen Streaming-Modelle in der folgenden Tabelle zusammengefasst.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/streamsmain.html)
Sie können beide Streaming-Modelle in derselben DynamoDB-Tabelle aktivieren.
Im folgenden Video wird mehr über die Unterschiede zwischen den beiden Optionen gesprochen.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/UgG17Wh2y0g)
# Verwenden von Kinesis Data Streams zum Erfassen von Änderungen an DynamoDB
Sie können Amazon Kinesis Data Streams verwenden, um Änderungen an Amazon DynamoDB zu erfassen.
Kinesis Data Streams erfasst Änderungen auf Elementebene in jeder DynamoDB-Tabelle und repliziert sie in einen [Kinesis Data Stream](https://docs.aws.amazon.com/streams/latest/dev/introduction.html). Ihre Anwendungen können auf diesen Stream zugreifen und die Änderungen auf Elementebene nahezu in Echtzeit anzeigen. Sie können kontinuierlich Terabyte an Daten pro Stunde erfassen und speichern. Sie können eine längere Datenaufbewahrungszeit nutzen, und mit der Funktion für erweiterte Rundsendungen können Sie gleichzeitig zwei oder mehr nachgelagerte Anwendungen erreichen. Weitere Vorteile sind zusätzliche Prüfungen und Sicherheitstransparenz.
Mit Kinesis Data Streams haben Sie auch Zugriff auf [Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html) und [Amazon Managed Service für Apache Flink](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/what-is.html). Diese Services können Sie bei der Erstellung von Anwendungen unterstützen, die Echtzeit-Dashboards betreiben, Warnungen generieren, dynamische Preisgestaltung und Werbung implementieren und ausgefeilte Datenanalysen sowie Algorithmen für maschinelles Lernen umsetzen.
**Anmerkung**
Die Verwendung von Kinesis-Datenströmen für DynamoDB unterliegt sowohl den [Kinesis Data Streams-Preisen für den Datenstream](https://aws.amazon.com/kinesis/data-streams/pricing/) als auch den [DynamoDB-Preisen](https://aws.amazon.com/dynamodb/pricing/) für die Quelltabelle.
Informationen zum Aktivieren von Kinesis-Streaming in einer DynamoDB-Tabelle mithilfe der Konsole oder des Java-SDK finden Sie unter. AWS CLI[Erste Schritte mit Kinesis Data Streams für Amazon DynamoDB](kds_gettingstarted.md)
**Topics**
+ [Wie Kinesis Data Streams mit DynamoDB funktioniert](#kds_howitworks)
+ [Erste Schritte mit Kinesis Data Streams für Amazon DynamoDB](kds_gettingstarted.md)
+ [Verwenden von Shards und Metriken mit DynamoDB Streams und Kinesis Data Streams](kds_using-shards-and-metrics.md)
+ [Verwendung von IAM-Richtlinien für Amazon Kinesis Data Streams und Amazon DynamoDB](kds_iam.md)
## Wie Kinesis Data Streams mit DynamoDB funktioniert
Wenn ein Kinesis Data Stream für eine DynamoDB-Tabelle aktiviert ist, sendet die Tabelle einen Datensatz, der alle Änderungen an den Daten dieser Tabelle erfasst. Dieser Datensatz beinhaltet:
+ Die spezifische Uhrzeit, zu der ein Element kürzlich erstellt, aktualisiert oder gelöscht wurde
+ den Primärschlüssel dieses Elements
+ einen Snapshot des Datensatzes vor der Änderung
+ einen Snapshot des Datensatzes nach der Änderung
Diese Datensätze werden nahezu in Echtzeit erfasst und veröffentlicht. Nachdem sie in den Kinesis Data Stream geschrieben wurden, können sie wie jeder andere Datensatz gelesen werden. Sie können die Kinesis Client Library verwenden AWS Lambda, die Kinesis Data Streams Streams-API verwenden, aufrufen und andere verbundene Dienste verwenden. Weitere Informationen finden Sie unter [Lesen von Daten aus Amazon Kinesis Data Streams](https://docs.aws.amazon.com/streams/latest/dev/building-consumers.html) im Amazon-Kinesis-Data-Streams-Entwicklerhandbuch.
Diese Änderungen an Daten werden ebenfalls asynchron erfasst. Kinesis hat keine Auswirkungen auf die Leistung einer Tabelle, von der es streamt. Die in Ihrem Kinesis Data Stream gespeicherten Streamdatensätze werden auch im Ruhezustand verschlüsselt. Weitere Informationen finden Sie unter [Datenschutz in Amazon Kinesis Data Streams](https://docs.aws.amazon.com/streams/latest/dev/server-side-encryption.html).
Die Kinesis-Data-Stream-Datensätze werden möglicherweise in einer anderen Reihenfolge angezeigt als vor den Elementänderungen. Dieselben Elementbenachrichtigungen werden möglicherweise auch mehrmals im Stream angezeigt. Sie können das Attribut `ApproximateCreationDateTime` überprüfen, um die Reihenfolge zu ermitteln, in der die Elementänderungen aufgetreten sind, und um doppelte Datensätze zu identifizieren.
Wenn Sie einen Kinesis Data Stream als Streaming-Ziel einer DynamoDB-Tabelle aktivieren, können Sie die Genauigkeit der `ApproximateCreationDateTime`-Werte entweder in Millisekunden oder Mikrosekunden konfigurieren. Standardmäßig gibt `ApproximateCreationDateTime` den Zeitpunkt der Änderung in Millisekunden an. Darüber hinaus können Sie diesen Wert für ein aktives Streaming-Ziel ändern. Nach einer solchen Aktualisierung weisen in Kinesis geschriebene Stream-Datensätze `ApproximateCreationDateTime`-Werte mit der gewünschten Genauigkeit auf.
In DynamoDB geschriebene Binärwerte müssen im [Base64-codierten Format](HowItWorks.NamingRulesDataTypes.md) codiert sein. Wenn Datensätze jedoch in einen Kinesis-Datenstrom geschrieben werden, erfolgt eine zweite Codierung dieser codierten Binärwerte mit der Base64-Codierung. Beim Lesen dieser Datensätze aus einem Kinesis-Datenstrom müssen Anwendungen diese Werte zweimal dekodieren, um die rohen Binärwerte abzurufen.
DynamoDB erhebt Gebühren für die Verwendung von Kinesis Data Streams in Änderungsdatenerfassungseinheiten. 1 KB Änderung pro Einzelelement gilt als eine Änderungsdatenerfassungseinheit. Die KB der Änderung in jedem Element wird durch das Größere der „Vorher“- und „Nachher“-Images des in den Stream geschriebenen Elements berechnet, wobei dieselbe Logik wie [capacity unit consumption for write operations](read-write-operations.md#write-operation-consumption) (Verbrauch der Kapazitätseinheit für Schreibvorgänge) verwendet wird. Sie müssen keinen Kapazitätsdurchsatz für Änderungsdatenerfassungseinheiten bereitstellen, ähnlich wie der DynamoDB [on-demand](capacity-mode.md#capacity-mode-on-demand)-Modus funktioniert.
### Aktivieren eines Kinesis Data Streams für Ihre DynamoDB-Tabelle
Sie können das Streaming zu Kinesis von Ihrer vorhandenen DynamoDB-Tabelle aus aktivieren oder deaktivieren, indem Sie das AWS-Managementkonsole, das AWS SDK oder das AWS Command Line Interface () verwenden.AWS CLI
+ Sie können nur Daten von DynamoDB zu Kinesis Data Streams in demselben AWS Konto und derselben AWS Region streamen wie Ihre Tabelle.
+ Sie können nur Daten von einer DynamoDB-Tabelle in einen Kinesis Data Stream streamen.
### Vornehmen von Änderungen an einem Kinesis-Data-Streams-Ziel in Ihrer DynamoDB-Tabelle
Standardmäßig enthalten alle Kinesis-Data-Stream-Datensätze ein `ApproximateCreationDateTime`-Attribut. Dieses Attribut stellt einen Zeitstempel in Millisekunden der ungefähren Zeit dar, zu der jeder Datensatz erstellt wurde. Sie können die Genauigkeit dieser Werte ändern, indem Sie [https://console.aws.amazon.com/kinesis, das SDK oder](https://console.aws.amazon.com/kinesis) das AWS CLI
# Erste Schritte mit Kinesis Data Streams für Amazon DynamoDB
In diesem Abschnitt wird beschrieben, wie Kinesis Data Streams für Amazon DynamoDB-Tabellen mit der Amazon DynamoDB DynamoDB-Konsole, der AWS Command Line Interface (AWS CLI) und der API verwendet wird.
## Erstellen eines aktiven Amazon-Kinesis-Daten-Streams
Alle diese Beispiele verwenden die `Music`-DynamoDB-Tabelle, die als Teil des [Erste Schritte mit DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GettingStartedDynamoDB.html)-Tutorials erstellt wurde.
Weitere Informationen zum Erstellen von Konsumenten und zum Verbinden Ihres Kinesis Data Streams mit anderen AWS -Services finden Sie unter [Lesen von Daten aus Amazon Kinesis Data Streams](https://docs.aws.amazon.com/streams/latest/dev/building-consumers.html) im *Amazon-Kinesis-Data-Streams-Entwicklerhandbuch*.
**Anmerkung**
Wenn Sie zum ersten Mal KDS-Shards verwenden, empfehlen wir, Ihre Shards so einzustellen, dass sie den Nutzungsmustern entsprechend hoch- und herunterskaliert werden. Nachdem Sie mehr Daten zu den Nutzungsmustern gesammelt haben, können Sie die Shards in Ihrem Datenstrom entsprechend anpassen.
------
#### [ Console ]
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Kinesis-Konsole unter [https://console.aws.amazon.com/kinesis/](https://console.aws.amazon.com/kinesis/).
1. Klicken Sie auf **Create data stream** (Datenstrom erstellen) und befolgen Sie die Anweisungen, um einen Stream mit dem Namen `samplestream` zu erstellen.
1. Öffnen Sie die DynamoDB-Konsole unter. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)
1. Klicken Sie im Navigationsbereich auf der linken Seite der Konsole auf **Tables** (Tabellen).
1. Wählen Sie die Tabelle **Music** (Musik).
1. Wählen Sie die Registerkarte **Exports and streams** (Exporte und Streams).
1. (Optional) Unter **Details zu Amazon-Kinesis-Daten-Streams** können Sie die Zeitstempelgenauigkeit des Datensatzes von Mikrosekunde (Standard) auf Millisekunde ändern.
1. Klicken Sie auf **samplestream** aus der Dropdown-Liste.
1. Klicken Sie auf die Schaltfläche **Einschalten**.
------
#### [ AWS CLI ]
1. Erstellen Sie einen Kinesis Data Stream mit dem Namen `samplestream`, indem Sie den [Befehl create-stream](https://docs.aws.amazon.com/cli/latest/reference/kinesis/create-stream.html) wählen.
```
aws kinesis create-stream --stream-name samplestream --shard-count 3
```
Sehen Sie sich [Überlegungen zur Shard-Verwaltung für Kinesis Data Streams](kds_using-shards-and-metrics.md#kds_using-shards-and-metrics.shardmanagment) an, bevor Sie die Anzahl der Shards für den Kinesis Data Stream festlegen.
1. Überprüfen Sie, ob der Kinesis Stream aktiv und einsatzbereit ist, indem Sie den [Befehl Stream beschreiben](https://docs.aws.amazon.com/cli/latest/reference/kinesis/describe-stream.html) auswählen.
```
aws kinesis describe-stream --stream-name samplestream
```
1. Aktivieren Sie Kinesis-Streaming für die DynamoDB-Tabelle mithilfe des DynamoDB-Befehls `enable-kinesis-streaming-destination`. Ersetzen Sie den `stream-arn`-Wert durch den Wert, der im vorherigen Schritt von `describe-stream` zurückgegeben wurde. Aktivieren Sie optional das Streaming mit einer höheren Genauigkeit (Mikrosekunden) der für jeden Datensatz zurückgegebenen Zeitstempelwerte.
So aktivieren Sie das Streaming mit einer Zeitstempelgenauigkeit im Mikrosekundenbereich:
```
aws dynamodb enable-kinesis-streaming-destination \
--table-name Music \
--stream-arn arn:aws:kinesis:us-west-2:12345678901:stream/samplestream
--enable-kinesis-streaming-configuration ApproximateCreationDateTimePrecision=MICROSECOND
```
So aktivieren Sie das Streaming mit der standardmäßigen Zeitstempelgenauigkeit (Millisekunde):
```
aws dynamodb enable-kinesis-streaming-destination \
--table-name Music \
--stream-arn arn:aws:kinesis:us-west-2:12345678901:stream/samplestream
```
1. Überprüfen Sie, ob Kinesis-Streaming in der Tabelle aktiv ist, mithilfe des DynamoDB-`describe-kinesis-streaming-destination`-Befehls.
```
aws dynamodb describe-kinesis-streaming-destination --table-name Music
```
1. Schreiben Sie Daten in die DynamoDB-Tabelle mithilfe der `put-item`, wie in dem [Entwicklerhandbuch von DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/getting-started-step-2.html) angegeben ist.
```
aws dynamodb put-item \
--table-name Music \
--item \
'{"Artist": {"S": "No One You Know"}, "SongTitle": {"S": "Call Me Today"}, "AlbumTitle": {"S": "Somewhat Famous"}, "Awards": {"N": "1"}}'
aws dynamodb put-item \
--table-name Music \
--item \
'{"Artist": {"S": "Acme Band"}, "SongTitle": {"S": "Happy Day"}, "AlbumTitle": {"S": "Songs About Life"}, "Awards": {"N": "10"} }'
```
1. Verwenden Sie den Kinesis-CLI-Befehl [get-records](https://docs.aws.amazon.com/cli/latest/reference/kinesis/get-records.html), um den Inhalt des Kinesis Streams abzurufen. Verwenden Sie dann den folgenden Codeausschnitt, um den Streaminhalt zu deserialisieren.
```
/**
* Takes as input a Record fetched from Kinesis and does arbitrary processing as an example.
*/
public void processRecord(Record kinesisRecord) throws IOException {
ByteBuffer kdsRecordByteBuffer = kinesisRecord.getData();
JsonNode rootNode = OBJECT_MAPPER.readTree(kdsRecordByteBuffer.array());
JsonNode dynamoDBRecord = rootNode.get("dynamodb");
JsonNode oldItemImage = dynamoDBRecord.get("OldImage");
JsonNode newItemImage = dynamoDBRecord.get("NewImage");
Instant recordTimestamp = fetchTimestamp(dynamoDBRecord);
/**
* Say for example our record contains a String attribute named "stringName" and we want to fetch the value
* of this attribute from the new item image. The following code fetches this value.
*/
JsonNode attributeNode = newItemImage.get("stringName");
JsonNode attributeValueNode = attributeNode.get("S"); // Using DynamoDB "S" type attribute
String attributeValue = attributeValueNode.textValue();
System.out.println(attributeValue);
}
private Instant fetchTimestamp(JsonNode dynamoDBRecord) {
JsonNode timestampJson = dynamoDBRecord.get("ApproximateCreationDateTime");
JsonNode timestampPrecisionJson = dynamoDBRecord.get("ApproximateCreationDateTimePrecision");
if (timestampPrecisionJson != null && timestampPrecisionJson.equals("MICROSECOND")) {
return Instant.EPOCH.plus(timestampJson.longValue(), ChronoUnit.MICROS);
}
return Instant.ofEpochMilli(timestampJson.longValue());
}
```
------
#### [ Java ]
1. Befolgen Sie die Anweisungen im Kinesis-Data-Streams-Entwicklerhandbuch, um einen Kinesis Data Stream mit `samplestream` Java-Namen zu [erstellen](https://docs.aws.amazon.com/streams/latest/dev/kinesis-using-sdk-java-create-stream.html).
Sehen Sie sich [Überlegungen zur Shard-Verwaltung für Kinesis Data Streams](kds_using-shards-and-metrics.md#kds_using-shards-and-metrics.shardmanagment) an, bevor Sie die Anzahl der Shards für den Kinesis Data Stream festlegen.
1. Verwenden Sie den folgenden Codeausschnitt, um Kinesis-Streaming für die DynamoDB-Tabelle zu aktivieren. Aktivieren Sie optional das Streaming mit einer höheren Genauigkeit (Mikrosekunden) der für jeden Datensatz zurückgegebenen Zeitstempelwerte.
So aktivieren Sie das Streaming mit einer Zeitstempelgenauigkeit im Mikrosekundenbereich:
```
EnableKinesisStreamingConfiguration enableKdsConfig = EnableKinesisStreamingConfiguration.builder()
.approximateCreationDateTimePrecision(ApproximateCreationDateTimePrecision.MICROSECOND)
.build();
EnableKinesisStreamingDestinationRequest enableKdsRequest = EnableKinesisStreamingDestinationRequest.builder()
.tableName(tableName)
.streamArn(kdsArn)
.enableKinesisStreamingConfiguration(enableKdsConfig)
.build();
EnableKinesisStreamingDestinationResponse enableKdsResponse = ddbClient.enableKinesisStreamingDestination(enableKdsRequest);
```
So aktivieren Sie das Streaming mit der standardmäßigen Zeitstempelgenauigkeit (Millisekunde):
```
EnableKinesisStreamingDestinationRequest enableKdsRequest = EnableKinesisStreamingDestinationRequest.builder()
.tableName(tableName)
.streamArn(kdsArn)
.build();
EnableKinesisStreamingDestinationResponse enableKdsResponse = ddbClient.enableKinesisStreamingDestination(enableKdsRequest);
```
1. Befolgen Sie die Anweisungen im *Kinesis-Data-Streams-Entwicklerhandbuch*, um aus dem erstellten Datenstrom zu [lesen](https://docs.aws.amazon.com/streams/latest/dev/building-consumers.html).
1. Verwenden Sie dann den folgenden Codeausschnitt, um den Streaminhalt zu deserialisieren
```
/**
* Takes as input a Record fetched from Kinesis and does arbitrary processing as an example.
*/
public void processRecord(Record kinesisRecord) throws IOException {
ByteBuffer kdsRecordByteBuffer = kinesisRecord.getData();
JsonNode rootNode = OBJECT_MAPPER.readTree(kdsRecordByteBuffer.array());
JsonNode dynamoDBRecord = rootNode.get("dynamodb");
JsonNode oldItemImage = dynamoDBRecord.get("OldImage");
JsonNode newItemImage = dynamoDBRecord.get("NewImage");
Instant recordTimestamp = fetchTimestamp(dynamoDBRecord);
/**
* Say for example our record contains a String attribute named "stringName" and we wanted to fetch the value
* of this attribute from the new item image, the below code would fetch this.
*/
JsonNode attributeNode = newItemImage.get("stringName");
JsonNode attributeValueNode = attributeNode.get("S"); // Using DynamoDB "S" type attribute
String attributeValue = attributeValueNode.textValue();
System.out.println(attributeValue);
}
private Instant fetchTimestamp(JsonNode dynamoDBRecord) {
JsonNode timestampJson = dynamoDBRecord.get("ApproximateCreationDateTime");
JsonNode timestampPrecisionJson = dynamoDBRecord.get("ApproximateCreationDateTimePrecision");
if (timestampPrecisionJson != null && timestampPrecisionJson.equals("MICROSECOND")) {
return Instant.EPOCH.plus(timestampJson.longValue(), ChronoUnit.MICROS);
}
return Instant.ofEpochMilli(timestampJson.longValue());
}
```
------
## Vornehmen von Änderungen an einem aktiven Amazon-Kinesis-Daten-Stream
In diesem Abschnitt wird beschrieben, wie Sie mithilfe der Konsole und der API Änderungen an einem aktiven Kinesis Data Streams for DynamoDB-Setup vornehmen. AWS CLI
**AWS-Managementkonsole**
1. Öffnen Sie die DynamoDB-Konsole unter [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)
1. Öffnen Sie die gewünschte Tabelle.
1. Wählen Sie die Option **Exporte und Streams**.
**AWS CLI**
1. Rufen Sie `describe-kinesis-streaming-destination` auf, um zu bestätigen, dass der Stream `ACTIVE` ist.
1. Rufen Sie `UpdateKinesisStreamingDestination` auf, wie in diesem Beispiel:
```
aws dynamodb update-kinesis-streaming-destination --table-name enable_test_table --stream-arn arn:aws:kinesis:us-east-1:12345678901:stream/enable_test_stream --update-kinesis-streaming-configuration ApproximateCreationDateTimePrecision=MICROSECOND
```
1. Rufen Sie `describe-kinesis-streaming-destination` auf, um zu bestätigen, dass der Stream `UPDATING` ist.
1. Rufen Sie `describe-kinesis-streaming-destination` regelmäßig auf, bis der Streaming-Status wieder `ACTIVE` ist. Normalerweise dauert es bis zu 5 Minuten, bis die Aktualisierungen der Zeitstempelgenauigkeit wirksam werden. Sobald der Status aktualisiert wurde, ist die Änderung abgeschlossen, und der neue Genauigkeitswert wird auf künftige Datensätze angewendet.
1. Schreiben Sie mit `putItem` in die Tabelle.
1. Verwenden Sie den Kinesis-Befehl `get-records`, um den Inhalt des Streams abzurufen.
1. Vergewissern Sie sich, dass die `ApproximateCreationDateTime` der Schreibvorgänge die gewünschte Genauigkeit haben.
**Java-API**
1. Stellen Sie einen Codeausschnitt bereit, der eine `UpdateKinesisStreamingDestination`-Anfrage und eine `UpdateKinesisStreamingDestination`-Antwort erstellt.
1. Stellen Sie einen Codeausschnitt bereit, der eine `DescribeKinesisStreamingDestination`-Anfrage und eine `DescribeKinesisStreamingDestination response` erstellt.
1. Rufen Sie `describe-kinesis-streaming-destination` regelmäßig auf, bis der Streaming-Status wieder `ACTIVE` ist. Dies zeigt an, dass die Änderung abgeschlossen ist und der neue Genauigkeitswert auf künftige Datensätze angewendet wird.
1. Führen Sie Schreibvorgänge in der Tabelle durch.
1. Lesen Sie Daten aus dem Stream und deserialisieren Sie den Streaminhalt.
1. Vergewissern Sie sich, dass die `ApproximateCreationDateTime` der Schreibvorgänge die gewünschte Genauigkeit haben.
# Verwenden von Shards und Metriken mit DynamoDB Streams und Kinesis Data Streams
## Überlegungen zur Shard-Verwaltung für Kinesis Data Streams
Ein Kinesis-Daten-Stream zählt seinen Durchsatz in [Shards](https://docs.aws.amazon.com/streams/latest/dev/key-concepts.html). In Amazon Kinesis Data Streams können Sie zwischen einem **On-Demand**-Modus und einem **bereitgestellten** Modus für Ihre Datenströme wählen.
Wir empfehlen, den On-Demand-Modus für Ihren Kinesis-Daten-Stream zu verwenden, wenn Ihre DynamoDB-Schreib-Workload sehr variabel und unvorhersehbar ist. Im On-Demand-Modus ist keine Kapazitätsplanung erforderlich, da Kinesis Data Streams die Shards automatisch verwaltet, um den erforderlichen Durchsatz bereitzustellen.
Bei vorhersehbaren Workloads können Sie den bereitgestellten Modus für Ihren Kinesis-Daten-Stream verwenden. Im bereitgestellten Modus müssen Sie die Anzahl der Shards für den Datenstrom angeben, um die Datenerfassungsdatensätze der Änderungen aus DynamoDB aufzunehmen. Um die Anzahl der Shards zu ermitteln, die der Kinesis-Daten-Stream für die DynamoDB-Tabelle benötigt, sind folgende Eingabewerte erforderlich:
+ Die durchschnittliche Größe des Datensatzes Ihrer DynamoDB-Tabelle in Byte (`average_record_size_in_bytes`).
+ Die maximale Anzahl von Schreibvorgängen, die Ihre DynamoDB-Tabelle pro Sekunde ausführen wird. Dazu gehören das Erstellen, Löschen und Aktualisieren von Vorgängen, die von Ihren Anwendungen ausgeführt werden, sowie automatisch generierte Vorgänge, z. B. von Time to Live generierte Löschvorgänge (`write_throughput`).
+ Der Prozentsatz der Aktualisierungs- und Überschreibvorgänge, die Sie für Ihre Tabelle ausführen, im Vergleich zu Erstellungs- oder Löschvorgängen (`percentage_of_updates`). Aktualisierungs- und Überschreibvorgänge replizieren sowohl die alten als auch die neuen Images des geänderten Elements in den Stream. Dies erzeugt die doppelte DynamoDB-Elementgröße.
Sie können die Anzahl der Shards (`number_of_shards`), die der Kinesis-Daten-Stream benötigt, mit den Eingabewerte in der folgenden Formel berechnen:
```
number_of_shards = ceiling( max( ((write_throughput * (4+percentage_of_updates) * average_record_size_in_bytes) / 1024 / 1024), (write_throughput/1000)), 1)
```
Nehmen wir an, Sie haben einen maximalen Durchsatz von 1 040 Schreibvorgängen pro Sekunde (`write_throughput`) bei einer durchschnittlichen Datensatzgröße von 800 Byte (`average_record_size_in_bytes)`. Wenn 25 Prozent dieser Schreibvorgänge Aktualisierungsvorgänge sind (`percentage_of_updates`), benötigen Sie zwei Shards (`number_of_shards`) für Ihren DynamoDB-Streaming-Durchsatz:
```
ceiling( max( ((1040 * (4+25/100) * 800)/ 1024 / 1024), (1040/1000)), 1).
```
Beachten Sie Folgendes, bevor Sie die Formel verwenden, um die Anzahl der Shards zu berechnen, die im bereitgestellten Modus für Kinesis-Daten-Streams erforderlich sind:
+ Mit dieser Formel können Sie die Anzahl der Shards abschätzen, die für die Aufnahme Ihrer DynamoDB-Änderungsdatensätze erforderlich sind. Sie stellt nicht die Gesamtzahl der Shards dar, die in Ihrem Kinesis-Daten-Stream benötigt werden, z. B. Shards, die zur Unterstützung zusätzlicher Nutzer von Kinesis-Daten-Streams erforderlich sind.
+ Im Bereitstellungsmodus kann es immer noch zu Ausnahmen beim Lese- und Schreibdurchsatz kommen, wenn Sie Ihren Datenstrom nicht für den Spitzendurchsatz konfigurieren. In diesem Fall müssen Sie Ihren Datenstrom manuell skalieren, um den Datenverkehr zu bewältigen.
+ Diese Formel berücksichtigt die zusätzliche Überlastung, die von DynamoDB generiert wird, bevor die Änderungsprotokoll-Datensätze an Kinesis Data Streams gestreamt werden.
Weitere Informationen zu den Kapazitätsmodi in Kinesis Data Streams finden Sie unter [Auswahl des Datenstrom-Kapazitätsmodus](https://docs.aws.amazon.com/streams/latest/dev/how-do-i-size-a-stream.html). Weitere Informationen zu den Preisunterschieden zwischen den verschiedenen Kapazitätsmodi finden Sie unter [Amazon Kinesis Data Streams – Preise](https://aws.amazon.com/kinesis/data-streams/pricing/).
## Änderung der Datenerfassung für Kinesis Data Streams überwachen
DynamoDB bietet mehrere CloudWatch Amazon-Metriken, mit denen Sie die Replikation von Change Data Capture nach Kinesis überwachen können. Eine vollständige Liste der CloudWatch Metriken finden Sie unter. [DynamoDB-Metriken und -Dimensionen](metrics-dimensions.md)
Es wird empfohlen, die folgenden Elemente sowohl während der Stream-Aktivierung als auch in der Produktion zu überwachen, um festzustellen, ob der Stream über ausreichende Kapazität verfügt:
+ `ThrottledPutRecordCount`: Die Anzahl der Datensätze, die von Ihrem Kinesis-Daten-Stream aufgrund unzureichender Kinesis-Daten-Stream-Kapazität gedrosselt wurden. Der `ThrottledPutRecordCount` sollte so niedrig wie möglich bleiben, obwohl sie bei außergewöhnlichen Nutzungsspitzen eine gewisse Drosselung erfahren könnten. DynamoDB versucht erneut, gedrosselte Datensätze in das Kinesis Data Stream zu senden. Dies kann jedoch zu einer höheren Replikationslatenz führen.
Wenn eine übermäßige und regelmäßige Drosselung auftritt, müssen Sie möglicherweise die Anzahl der Kinesis-Stream-Shards proportional zum beobachteten Schreibdurchsatz Ihrer Tabelle erhöhen. Weitere Informationen zur Bestimmung der Größe eines Kinesis Data Streams finden Sie unter [Bestimmen der anfänglichen Größe eines Kinesis Data Streams](https://docs.aws.amazon.com/streams/latest/dev/amazon-kinesis-streams.html#how-do-i-size-a-stream).
+ `AgeOfOldestUnreplicatedRecord`: Die verstrichene Zeit seit der ältesten Änderung auf Elementebene, die noch in den Kinesis Data Stream repliziert wurde, wurde in der DynamoDB-Tabelle angezeigt. Im Normalbetrieb sollte `AgeOfOldestUnreplicatedRecord` in der Reihenfolge von Millisekunden liegen. Diese Zahl wächst aufgrund erfolgloser Replikationsversuche, wenn diese durch kundengesteuerte Konfigurationsoptionen verursacht werden.
Wenn die Metrik `AgeOfOldestUnreplicatedRecord` 168 Stunden überschreitet, wird die Replikation von Änderungen auf Elementebene aus der DynamoDB-Tabelle in den Kinesis-Daten-Stream automatisch deaktiviert.
Kundengesteuerte Konfigurationsbeispiele, die zu erfolglosen Replikationsversuchen führen, sind eine zu gering bereitgestellte Kinesis-Daten-Stream-Kapazität, die zu übermäßiger Drosselung führt, oder eine manuelle Aktualisierung der Zugriffsrichtlinien Ihres Kinesis-Daten-Streams, die DynamoDB das Hinzufügen von Daten zu Ihrem Datenstrom verweigern. Um diese Metrik so niedrig wie möglich zu halten, müssen Sie möglicherweise die richtige Bereitstellung Ihrer Kinesis-Daten-Stream-Kapazität sicherstellen und sicherstellen, dass die Berechtigungen von DynamoDB unverändert bleiben.
+ `FailedToReplicateRecordCount`: Die Anzahl der Datensätze, die DynamoDB nicht in Ihren Kinesis-Datenstrom repliziert hat. Bestimmte Elemente, die größer als 34 KB sind, können sich vergrößern, um Datensätze zu ändern, die größer als die Elementgrößengrenze von 1 MB von Kinesis Data Streams sind. Diese Größenerweiterung tritt auf, wenn diese Elemente, die größer als 34 KB sind, eine große Anzahl von booleschen oder leeren Attributwerten enthalten. Boolesche und leere Attributwerte werden in DynamoDB als 1 Byte gespeichert, erweitern sich jedoch auf bis zu 5 Byte, wenn sie mit Standard-JSON für die Kinesis-Data-Streams-Replikation serialisiert werden. DynamoDB kann solche Änderungsdatensätze nicht in Ihren Kinesis Dats Stream replizieren. DynamoDB überspringt diese Änderungsdatensätze und repliziert automatisch nachfolgende Datensätze.
Sie können CloudWatch Amazon-Alarme erstellen, die eine Amazon Simple Notification Service (Amazon SNS) -Nachricht zur Benachrichtigung senden, wenn eine der oben genannten Metriken einen bestimmten Schwellenwert überschreitet.
# Verwendung von IAM-Richtlinien für Amazon Kinesis Data Streams und Amazon DynamoDB
Wenn Sie Amazon Kinesis Data Streams für Amazon DynamoDB zum ersten Mal aktivieren, erstellt DynamoDB automatisch eine AWS Identity and Access Management (IAM) -Serviceverknüpfte Rolle für Sie. Diese Rolle `AWSServiceRoleForDynamoDBKinesisDataStreamsReplication` ermöglicht DynamoDB, die Replikation von Änderungen auf Elementebene in Kinesis Data Streams in Ihrem Auftrag zu verwalten. Löschen Sie diese serviceverknüpfte Rolle nicht.
Weitere Informationen zu serviceverknüpften Rollen finden Sie unter [Verwenden serviceverknüpfter Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) im *IAM-Benutzerhandbuch*.
**Anmerkung**
DynamoDB unterstützt keine Tag-basierten Bedingungen für IAM-Richtlinien.
Damit Sie Amazon Kinesis Data Streams für Amazon DynamoDB aktivieren können, benötigen Sie die folgenden Berechtigungen für die Tabelle:
+ `dynamodb:EnableKinesisStreamingDestination`
+ `kinesis:ListStreams`
+ `kinesis:PutRecords`
+ `kinesis:DescribeStream`
Wenn Sie Amazon Kinesis Data Streams für Amazon DynamoDB für eine bestimmte DynamoDB-Tabelle beschreiben möchten, benötigen Sie die folgenden Berechtigungen für die Tabelle.
+ `dynamodb:DescribeKinesisStreamingDestination`
+ `kinesis:DescribeStreamSummary`
+ `kinesis:DescribeStream`
Damit Sie Amazon Kinesis Data Streams für Amazon DynamoDB deaktivieren können, benötigen Sie die folgenden Berechtigungen für die Tabelle.
+ `dynamodb:DisableKinesisStreamingDestination`
Damit Sie Amazon Kinesis Data Streams für Amazon DynamoDB aktualisieren können, benötigen Sie die folgenden Berechtigungen für die Tabelle.
+ `dynamodb:UpdateKinesisStreamingDestination`
Die folgenden Beispiele zeigen, wie IAM-Richtlinien verwendet werden, um Berechtigungen für Amazon Kinesis Data Streams für Amazon DynamoDB zu erteilen.
## Beispiel: Aktivieren von Amazon Kinesis Data Streams für Amazon DynamoDB
Über die folgende IAM-Richtlinie werden die nötigen Berechtigungen eingeräumt, um Amazon Kinesis Data Streams für Amazon DynamoDB für die `Music`-Tabelle zu aktivieren. Sie gewährt keine Berechtigungen zum Deaktivieren, Aktualisieren oder Beschreiben von Kinesis Data Streams for DynamoDB für die `Music`-Tabelle.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/kinesisreplication.dynamodb.amazonaws.com/AWSServiceRoleForDynamoDBKinesisDataStreamsReplication",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "kinesisreplication.dynamodb.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"dynamodb:EnableKinesisStreamingDestination"
],
"Resource": "arn:aws:dynamodb:us-west-2:111122223333:table/Music"
}
]
}
```
------
## Beispiel: Aktualisieren von Amazon Kinesis Data Streams für Amazon DynamoDB
Über die folgende IAM-Richtlinie werden die nötigen Berechtigungen eingeräumt, um Amazon Kinesis Data Streams für Amazon DynamoDB für die `Music`-Tabelle zu aktualisieren. Sie gewährt keine Berechtigungen zum Aktivieren, Deaktivieren oder Beschreiben von Amazon Kinesis Data Streams für Amazon DynamoDB für die `Music`-Tabelle.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:UpdateKinesisStreamingDestination"
],
"Resource": "arn:aws:dynamodb:us-west-2:111122223333:table/Music"
}
]
}
```
------
## Beispiel: Deaktivieren von Amazon Kinesis Data Streams für Amazon DynamoDB
Über die folgende IAM-Richtlinie werden die nötigen Berechtigungen eingeräumt, um Amazon Kinesis Data Streams für Amazon DynamoDB für die `Music`-Tabelle zu deaktivieren. Sie gewährt keine Berechtigungen zum Aktivieren, Aktualisieren oder Beschreiben von Amazon Kinesis Data Streams für Amazon DynamoDB für die `Music`-Tabelle.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:DisableKinesisStreamingDestination"
],
"Resource": "arn:aws:dynamodb:us-west-2:111122223333:table/Music"
}
]
}
```
------
## Beispiel: Selektives Anwenden von Berechtigungen für Amazon Kinesis Data Streams für Amazon DynamoDB basierend auf Ressource
Über die folgende IAM-Richtlinie werden Berechtigungen zum Aktivieren und Beschreiben von Amazon Kinesis Data Streams für Amazon DynamoDB für die `Music`-Tabelle eingeräumt und Berechtigungen zum Deaktivieren von Amazon Kinesis Data Streams für Amazon DynamoDB für die Tabelle `Orders` verweigert.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:EnableKinesisStreamingDestination",
"dynamodb:DescribeKinesisStreamingDestination"
],
"Resource": "arn:aws:dynamodb:us-west-2:111122223333:table/Music"
},
{
"Effect": "Deny",
"Action": [
"dynamodb:DisableKinesisStreamingDestination"
],
"Resource": "arn:aws:dynamodb:us-west-2:111122223333:table/Orders"
}
]
}
```
------
## Verwenden von serviceverknüpften Rollen für Kinesis Data Streams für DynamoDB
[Amazon Kinesis Data Streams für Amazon DynamoDB verwendet AWS Identity and Access Management (IAM) service-verknüpfte Rollen.](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) Eine serviceverknüpfte Rolle ist ein spezieller Typ einer IAM-Rolle, die direkt mit Kinesis Data Streams für DynamoDB verknüpft ist. Dienstbezogene Rollen sind von Kinesis Data Streams for DynamoDB vordefiniert und beinhalten alle Berechtigungen, die der Dienst benötigt, um andere AWS Dienste in Ihrem Namen aufzurufen.
Eine serviceverknüpfte Rolle vereinfacht das Einrichten von Kinesis Data Streams für DynamoDB, da Sie die erforderlichen Berechtigungen nicht manuell hinzufügen müssen. Kinesis Data Streams für DynamoDB definiert die Berechtigungen seiner serviceverknüpften Rollen. Sofern keine andere Einstellung festgelegt wurde, können nur Kinesis Data Streams für DynamoDB die Rollen übernehmen. Die definierten Berechtigungen umfassen die Vertrauens- und Berechtigungsrichtlinie. Diese Berechtigungsrichtlinie kann keinen anderen IAM-Entitäten zugewiesen werden.
Informationen zu anderen Services, die serviceverknüpften Rollen unterstützen, finden Sie unter [AWS -Services, die mit IAM funktionieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Suchen Sie nach den Services, für die **Ja** in der Spalte **Serviceverknüpfte Rolle** angegeben ist. Wählen Sie über einen Link **Yes** (Ja) aus, um die Dokumentation zu einer servicegebundenen Rolle für diesen Service anzuzeigen.
### Berechtigungen von serviceverknüpften Rollen für Kinesis Data Streams für DynamoDB
Kinesis Data Streams for DynamoDB verwendet die mit dem Service verknüpfte Rolle namens. **AWSServiceRoleForDynamoDBKinesisDataStreamsReplication** Die serviceverknüpfte Rolle ermöglicht es Amazon DynamoDB, in Ihrem Namen die Replikation von Änderungen auf Elementebene in Kinesis Data Streams zu verwalten.
Die serviceverknüpfte Rolle `AWSServiceRoleForDynamoDBKinesisDataStreamsReplication` vertraut darauf, dass die folgenden Services die Rolle annehmen:
+ `kinesisreplication.dynamodb.amazonaws.com`
Die Richtlinie für Rollenberechtigungen erlaubt Kinesis Data Streams für DynamoDB die folgenden Aktionen auf den angegebenen Ressourcen durchzuführen:
+ Aktion: `Put records and describe` für `Kinesis stream`
+ Aktion: `Generate data keys` aktiviert, um Daten `AWS KMS` in Kinesis-Streams zu speichern, die mit benutzergenerierten AWS KMS Schlüsseln verschlüsselt sind.
[Den genauen Inhalt des Richtliniendokuments finden Sie unter Dynamo. DBKinesis ReplicationServiceRolePolicy](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/aws-service-role/DynamoDBKinesisReplicationServiceRolePolicy)
Sie müssen Berechtigungen konfigurieren, damit eine juristische Stelle von IAM (z. B. Benutzer, Gruppe oder Rolle) eine serviceverknüpfte Rolle erstellen, bearbeiten oder löschen kann. Weitere Informationen finden Sie unter [serviceverknüpfte Rollenberechtigungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/contributorinsights-service-linked-roles.html#service-linked-role-permissions) im *IAM-Benutzerhandbuch*.
### Erstellen einer serviceverknüpften Rolle für Kinesis Data Streams für DynamoDB
Sie müssen eine serviceverknüpfte Rolle nicht manuell erstellen. Wenn Sie Kinesis Data Streams for DynamoDB in der AWS-Managementkonsole, der oder der AWS API aktivieren, erstellt Kinesis Data Streams for DynamoDB die serviceverknüpfte Rolle für Sie. AWS CLI
Wenn Sie diese serviceverknüpfte Rolle löschen und sie dann erneut erstellen müssen, können Sie dasselbe Verfahren anwenden, um die Rolle in Ihrem Konto neu anzulegen. Wenn Sie Kinesis Data Streams für DynamoDB aktivieren, erstellt Kinesis Data Streams für DynamoDB die serviceverknüpfte Rolle erneut für Sie.
### Bearbeiten einer serviceverknüpften Rolle für Kinesis Data Streams für DynamoDB
Kinesis Data Streams für DynamoDB ermöglicht es Ihnen nicht, die mit der `AWSServiceRoleForDynamoDBKinesisDataStreamsReplication` serviceverknüpfte Rolle zu bearbeiten. Da möglicherweise verschiedene Entitäten auf die Rolle verweisen, kann der Rollenname nach dem Erstellen einer serviceverknüpften Rolle nicht mehr geändert werden. Sie können jedoch die Beschreibung der Rolle mit IAM bearbeiten. Weitere Informationen finden Sie unter [Bearbeiten einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/contributorinsights-service-linked-roles.html#edit-service-linked-role) im *IAM-Benutzerhandbuch*.
### Löschen einer serviceverknüpften Rolle für Kinesis Data Streams für DynamoDB
Sie können auch die IAM-Konsole, die AWS CLI oder die API verwenden, um die serviceverknüpfte Rolle manuell zu löschen AWS . Sie müssen jedoch die Ressourcen für Ihre serviceverknüpfte Rolle zuerst manuell bereinigen, bevor Sie diese manuell löschen können.
**Anmerkung**
Wenn der Kinesis Data Streams für DynamoDB-Service die Rolle verwendet, wenn Sie versuchen, die Ressourcen zu löschen, schlägt das Löschen möglicherweise fehl. Wenn dies passiert, warten Sie einige Minuten und versuchen Sie es erneut.
**So löschen Sie die serviceverknüpfte Rolle mit IAM**
Verwenden Sie die IAM-Konsole, die oder die AWS API AWS CLI, um die serviceverknüpfte Rolle zu löschen. `AWSServiceRoleForDynamoDBKinesisDataStreamsReplication` Weitere Informationen finden Sie unter [Löschen einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) im *IAM-Leitfaden*.
# Ändern Sie die Datenerfassung für DynamoDB Streams
DynamoDB Streams erfasst eine zeitlich geordnete Abfolge von Änderungen auf Elementebene in jeder beliebigen DynamoDB-Tabelle und speichert diese Informationen bis zu 24 Stunden. Anwendungen können auf dieses Protokoll zugreifen und die Datenelemente vor und nach der Änderung nahezu in Echtzeit aufrufen.
Die Verschlüsselung ruhender Daten verschlüsselt die Daten in DynamoDB Streams. Weitere Informationen finden Sie unter [Ruhende DynamoDB-Verschlüsselung](EncryptionAtRest.md).
Ein *DynamoDB-Stream* ist ein strukturierter Informationsfluss zu Elementänderungen in einer DynamoDB-Tabelle. Wenn Sie den Stream für eine Tabelle aktivieren, werden von DynamoDB Informationen über jede Änderung an den Datenelementen in der Tabelle erfasst.
Wenn eine Anwendung Elemente in der Tabelle erstellt, aktualisiert oder löscht, schreibt DynamoDB Streams einen Stream-Datensatz mit dem bzw. den Primärschlüsselattributen der Elemente, die geändert wurden. Ein *Stream-Datensatz* enthält Informationen über eine Datenänderung an einem einzelnen Element einer DynamoDB-Tabelle. Sie können den Stream konfigurieren, sodass die Stream-Datensätze zusätzliche Informationen erfassen, z. B. Images der geänderten Elemente vor und nach der Änderung.
Mit DynamoDB Streams wird Folgendes sichergestellt:
+ Jeder Stream-Datensatz erscheint genau einmal im Stream.
+ Für jedes Element, das in einer DynamoDB-Tabelle geändert wird, erscheinen die Stream-Datensätze in der gleichen Reihenfolge wie die tatsächlichen Änderungen des Elements.
DynamoDB Streams schreibt Stream-Datensätze nahezu in Echtzeit, sodass Sie Anwendungen erstellen können, die diese Streams verbrauchen und basierend auf den Inhalten Aktionen einleiten.
**Topics**
+ [Endpunkte für DynamoDB Streams](#Streams.Endpoints)
+ [Aktivieren eines Streams](#Streams.Enabling)
+ [Lesen und Verarbeiten eines Streams](#Streams.Processing)
+ [DynamoDB Streams und Time to Live (TTL)](time-to-live-ttl-streams.md)
+ [Verwenden des DynamoDB-Streams-Kinesis-Adapters zum Verarbeiten von Stream-Datensätzen](Streams.KCLAdapter.md)
+ [DynamoDB-Streams-Low-Level-API: Java-Beispiel](Streams.LowLevel.Walkthrough.md)
+ [DynamoDB Streams und -Trigger AWS Lambda](Streams.Lambda.md)
+ [DynamoDB Streams und Apache Flink](StreamsApacheFlink.xml.md)
## Endpunkte für DynamoDB Streams
AWS verwaltet separate Endpunkte für DynamoDB- und DynamoDB Streams. Für die Arbeit mit Datenbanktabellen und Indexen muss Ihre Anwendung auf einen DynamoDB-Endpunkt zugreifen. Um DynamoDB-Streams-Datensätze zu lesen und zu verarbeiten, muss die Anwendung auf einen DynamoDB-Streams-Endpunkt in derselben Region zugreifen.
DynamoDB Streams bietet zwei Gruppen von Endpunkten. Diese sind:
+ **IPv4-only Endpoints: Endpoints** mit der Benennungskonvention. `streams.dynamodb..amazonaws.com`
+ **Dual-Stack-Endpunkte**: Neue Endpunkte, die sowohl mit als auch kompatibel sind IPv4 und IPv6 der Namenskonvention folgen. `streams-dynamodb..api.aws`
**Anmerkung**
Eine vollständige Liste der DynamoDB- und DynamoDB-Streams-Regionen und Endpunkte finden Sie unter [Regionen und Endpunkte](https://docs.aws.amazon.com/general/latest/gr/rande.html) in der *Allgemeine AWS-Referenz*.
AWS SDKs Sie bieten separate Clients für DynamoDB- und DynamoDB Streams. Je nach Anforderung kann die Anwendung auf einen DynamoDB-Endpunkt, einen DynamoDB-Streams-Endpunkt oder beide gleichzeitig zugreifen. Für die Verbindung mit beiden Endpunkten muss Ihre Anwendung zwei Clients instanziieren, und zwar einen für DynamoDB und einen für DynamoDB Streams.
## Aktivieren eines Streams
Sie können einen Stream in einer neuen Tabelle aktivieren, wenn Sie ihn mit der AWS CLI oder einer der folgenden Optionen erstellen. AWS SDKs Außerdem können Sie einen Stream in einer vorhandenen Tabelle aktivieren oder deaktivieren oder die Einstellungen eines Streams ändern. DynamoDB Streams wird asynchron betrieben. Daher wirkt es sich nicht auf die Leistung der Tabelle aus, wenn Sie einen Stream aktivieren.
Die einfachste Möglichkeit zum Verwalten von DynamoDB Streams bietet die AWS-Managementkonsole.
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die DynamoDB-Konsole unter. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)
1. Wählen Sie im Dashboard der DynamoDB-Konsole die Option **Tables** (Tabellen) aus und wählen Sie eine vorhandene Tabelle aus.
1. Wählen Sie die Registerkarte **Exports and streams** (Exporte und Streams).
1. Wählen Sie im Abschnitt **Details zum DynamoDB-Stream** die Option **Einschalten** aus.
1. Wählen Sie auf der Seite **DynamoDB-Stream einschalten** die Informationen aus, die in den Stream geschrieben werden sollen, sobald Daten in der Tabelle geändert werden:
+ **Nur Schlüsselattribute** – nur die Schlüsselattribute des geänderten Elements.
+ **Neues Image** – das gesamte Element wie es nach der Änderung erscheint.
+ **Altes Image** – das gesamte Element wie es vor der Änderung erscheint.
+ **Neues und altes Image** – sowohl das neue als auch das alte Image des Elements.
Wenn Sie die gewünschten Einstellungen vorgenommen haben, wählen Sie **Stream einschalten** aus.
1. (Optional) Um einen vorhandenen Stream zu deaktivieren, wählen Sie unter **Details zum DynamoDB-Stream** die Option **Deaktivieren** aus.
Sie können auch die `CreateTable`- oder `UpdateTable`-API-Operationen zum Aktivieren oder Ändern eines Streams verwenden. Der Parameter `StreamSpecification` bestimmt, wie der Stream konfiguriert wird:
+ `StreamEnabled` – gibt an, ob ein Stream für die Tabelle aktiviert (`true`) oder deaktiviert (`false`) ist.
+ `StreamViewType` – legt die Informationen fest, die in den Stream geschrieben werden, sobald Daten in der Tabelle geändert werden:
+ `KEYS_ONLY` – nur die Schlüsselattribute des geänderten Elements.
+ `NEW_IMAGE` – das gesamte Element, wie es nach der Änderung erscheint.
+ `OLD_IMAGE` – das gesamte Element, wie es vor der Änderung erscheint.
+ `NEW_AND_OLD_IMAGES` – sowohl das neue als auch das alte Image des Elements.
Sie können einen Stream jederzeit aktivieren oder deaktivieren. Wenn Sie versuchen, einen Stream für eine Tabelle zu aktivieren, die bereits über einen Stream verfügt, erhalten Sie jedoch eine `ValidationException`. Wenn Sie versuchen, einen Stream für eine Tabelle zu deaktivieren, die nicht über einen Stream verfügt, erhalten Sie auch eine `ValidationException`.
Wenn Sie `StreamEnabled` auf `true` festlegen, erstellt DynamoDB einen neuen Stream mit einem zugewiesenen, eindeutigen Stream-Deskriptor. Wenn Sie einen Stream in der Tabelle deaktivieren und anschließend erneut aktivieren, wird ein neuer Stream mit einem anderen Stream-Deskriptor erstellt.
Jeder Stream wird anhand eines Amazon-Ressourcennamens (ARN) eindeutig identifiziert. Nachfolgend ist ein Beispiel-ARN für einen Stream in einer DynamoDB-Tabelle mit dem Namen `TestTable` aufgeführt:
```
arn:aws:dynamodb:us-west-2:111122223333:table/TestTable/stream/2015-05-11T21:21:33.291
```
Um den aktuellen Stream-Deskriptor für eine Tabelle zu bestimmen, erstellen Sie eine DynamoDB-Anforderung `DescribeTable` und suchen das Element `LatestStreamArn` in der Antwort.
**Anmerkung**
Es ist nicht möglich, ein `StreamViewType` zu bearbeiten, sobald ein Stream eingerichtet wurde. Wenn Sie nach der Einrichtung Änderungen an einem Stream vornehmen möchten, müssen Sie den aktuellen Stream deaktivieren und einen neuen erstellen.
## Lesen und Verarbeiten eines Streams
Zum Lesen und Verarbeiten eines Streams muss Ihre Anwendung eine Verbindung mit einem DynamoDB-Streams-Endpunkt herstellen und API-Anforderungen ausgeben.
Ein Stream besteht aus *Stream-Datensätzen*. Jeder Stream-Datensatz stellt eine einzelne Datenänderung in der DynamoDB-Tabelle dar, zu der der Stream gehört. Jedem Stream-Datensatz ist eine Sequenznummer zugewiesen, wodurch die Reihenfolge dargestellt wird, in der der Datensatz im Stream veröffentlicht wurde.
Stream-Datensätze werden in Gruppen oder *Shards* verwaltet. Jeder Shard fungiert als Container für mehrere Stream-Datensätze und enthält Informationen, die zum Abrufen und Durchlaufen dieser Datensätze erforderlich sind. Die Stream-Datensätze in einem Shard werden nach 24 Stunden automatisch entfernt.
Shards sind flüchtig, d. h., sie werden nach Bedarf automatisch erstellt und gelöscht. Jeder Shard kann in mehrere neue Shards unterteilt werden. Dieser Vorgang erfolgt automatisch. (Es ist auch möglich, dass ein übergeordneter Shard nur einen untergeordneten Shard besitzt.) Ein Shard kann aufgrund hoher Schreibaktivitäten in der übergeordneten Tabelle aufgeteilt werden, sodass Anwendungen Datensätze aus mehreren Shards parallel verarbeiten können.
Wenn Sie einen Stream deaktivieren, werden alle offenen Shards geschlossen. Die Daten im Stream bleiben 24 Stunden lang lesbar.
Da Shards hierarchisch (über- und untergeordnet) aufgebaut sind, müssen Anwendungen einen übergeordneten Shard immer vor einem untergeordneten Shard verarbeiten. So wird sichergestellt, dass die Stream-Datensätze ebenfalls in der richtigen Reihenfolge verarbeitet werden. (Wenn Sie den DynamoDB-Streams-Kinesis-Adapter verwenden, wird dies für Sie erledigt. Ihre Anwendung verarbeitet die Shards und Streamdatensätze in der richtigen Reihenfolge. Es verarbeitet automatisch neue oder abgelaufene Shards sowie Shards, die sich während der Ausführung der Anwendung teilen. Weitere Informationen finden Sie unter [Verwenden des DynamoDB-Streams-Kinesis-Adapters zum Verarbeiten von Stream-Datensätzen](Streams.KCLAdapter.md).)
Das folgende Diagramm zeigt die Beziehung zwischen einem Stream, Shards im Stream und Stream-Datensätzen in den Shards.
![\[Struktur von DynamoDB Streams. Stream-Datensätze, die Datenänderungen darstellen, sind in Shards organisiert.\]](http://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/images/streams-terminology.png)
**Anmerkung**
Wenn Sie eine `PutItem` oder `UpdateItem` Operation ausführen, mit der keine Daten in einem Element geändert werden, schreibt DynamoDB Streams *keinen* Stream-Datensatz für diese Operation.
Um auf einen Stream zuzugreifen und die darin enthaltenen Stream-Datensätze zu verarbeiten, führen Sie die folgenden Schritte aus:
+ Ermitteln Sie den eindeutigen ARN des Streams, auf den Sie zugreifen möchten.
+ Bestimmen Sie, welcher bzw. welche Shards im Stream die gewünschten Stream-Datensätze enthalten.
+ Greifen Sie auf den bzw. die Shards zu und rufen Sie die gewünschten Stream-Datensätze ab.
**Anmerkung**
Es sollten nicht mehr als zwei Prozesse gleichzeitig aus dem Shard desselben Streams lesen. Wenn mehr als zwei Leser pro Shard vorhanden sind, kann eine Drosselung die Folge sein.
Die DynamoDB Streams-API bietet die folgenden Aktionen zur Verwendung durch Anwendungsprogramme:
+ `[ListStreams](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_streams_ListStreams.html)` – Gibt eine Liste der Stream-Deskriptoren für das aktuelle Konto und den Endpunkt zurück. Sie können optional nur die Stream-Deskriptoren für einen bestimmten Tabellennamen anfordern.
+ `[DescribeStream](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_streams_DescribeStream.html)` – Gibt Informationen über einen Stream zurück, z. B. den aktuellen Status des Streams, seinen Amazon-Ressourcennamen (ARN), die Zusammenstellung der Shards und die zugehörige DynamoDB-Tabelle. Sie können das Feld `ShardFilter` optional verwenden, um den vorhandenen untergeordneten Shard abzurufen, der dem übergeordneten Shard zugeordnet ist.
+ `[GetShardIterator](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_streams_GetShardIterator.html)` – Gibt einen *Shard Iterator* zurück, der eine Position innerhalb eines Shards beschreibt. Sie können anfordern, dass der Iterator Zugriff auf den ältesten Punkt, den neuesten Punkt oder einen bestimmten Punkt im Stream bereitstellt.
+ `[GetRecords](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_streams_GetRecords.html)` – Gibt die Stream-Datensätze innerhalb eines bestimmten Shards zurück. Sie müssen den von einer `GetShardIterator`-Anforderung zurückgegebenen Shard Iterator angeben.
Eine detaillierte Beschreibung dieser API-Aktionen, einschließlich Anforderungs- und Antwortbeispielen, finden Sie unter [Amazon-DynamoDB-Streams-API-Referenz](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations_Amazon_DynamoDB_Streams.html).
### Shard-Erkennung
Mit zwei leistungsstarken Methoden können Sie neue Shards in Ihrem DynamoDB-Stream erkennen. Als Nutzer von Amazon DynamoDB Streams haben Sie zwei effektive Möglichkeiten, neue Shards zu verfolgen und zu identifizieren:
**Abfragen der gesamten Stream-Topologie**
Verwenden Sie die `DescribeStream`-API, um den Stream regelmäßig abzufragen. Dadurch werden alle Shards im Stream zurückgegeben, einschließlich aller neu erstellten Shards. Indem Sie die Ergebnisse im Zeitverlauf vergleichen, können Sie neu hinzugefügte Shards erkennen.
**Erkennen untergeordneter Shards**
Verwenden Sie die `DescribeStream`-API mit dem Parameter `ShardFilter`, um eine Teilmenge von Shards zu finden. Wenn Sie in der Anfrage einen übergeordneten Shard benennen, gibt DynamoDB Streams seine unmittelbar untergeordneten Shards zurück. Dieser Ansatz ist nützlich, wenn Sie nur die Herkunft der Shards verfolgen müssen, ohne den gesamten Stream zu scannen.
Anwendungen, die Daten aus DynamoDB Streams aufnehmen, können mithilfe dieses `ShardFilter`-Parameters effizient vom Lesen eines geschlossenen Shards zum zugehörigen untergeordneten Shard übergehen. Dadurch werden wiederholte Aufrufe der `DescribeStream`-API vermieden, um die Shard-Zuordnung für alle geschlossenen und offenen Shards abzurufen und zu durchlaufen. So können untergeordnete Shards schnell erkannt werden, nachdem ein übergeordneter Shard geschlossen wurde. Auf diese Weise werden Stream-Verarbeitungsanwendungen reaktionsschneller und kostengünstiger.
Mit beiden Methoden können Sie den Überblick über die sich entwickelnde Struktur Ihrer DynamoDB Streams behalten, um keine wichtigen Datenaktualisierungen oder Shard-Änderungen zu verpassen.
### Datenaufbewahrungsfrist für DynamoDB Streams
Alle Daten in DynamoDB Streams unterliegen einer 24-Stunden-Nutzungsdauer. Sie können die Aktivitäten der letzten 24 Stunden für eine bestimmte Tabelle abrufen und analysieren. Daten, die älter als 24 Stunden sind, können jedoch jederzeit entfernt werden.
Wenn Sie einen Stream in einer Tabelle deaktivieren, bleiben die Daten im Stream 24 Stunden lang lesbar. Nach Ablauf dieses Zeitraums verfallen die Daten und die Stream-Datensätze werden automatisch gelöscht. Es gibt keinen Mechanismus zum manuellen Löschen eines vorhandenen Streams. Sie müssen nur warten, bis die Aufbewahrungsfrist abgelaufen ist (24 Stunden) und alle Stream-Datensätze gelöscht werden.
# DynamoDB Streams und Time to Live (TTL)
Sie können Elemente, die durch die [Gültigkeitsdauer](TTL.md) (TTL) gelöscht wurden, sichern oder anderweitig verarbeiten, indem Sie Amazon DynamoDB Streams in der Tabelle aktivieren und die Streams-Datensätze der abgelaufenen Elemente verarbeiten. Weitere Informationen finden Sie unter [Lesen und Verarbeiten eines Streams](Streams.md#Streams.Processing).
Der Stream-Datensatz enthält ein Benutzeridentitätsfeld `Records[].userIdentity`.
Die Elemente, die nach Ablauf durch den Gültigkeitsdauer-Prozess gelöscht wurden, haben die folgenden Felder:
+ `Records[].userIdentity.type`
`"Service"`
+ `Records[