F: Was ist Amazon DynamoDB?

Amazon DynamoDB ist ein vollständig verwalteter NoSQL-Datenbank-Service, der schnelle und planbare Leistung mit nahtloser Skalierbarkeit bereitstellt. Mit Amazon DynamoDB geben Sie die administrativen Aufgaben in Bezug auf den Betrieb und die Skalierung verteilter Datenbanken an AWS weiter. So müssen Sie sich keine Gedanken um die Bereitstellung von Hardware, deren Einrichtung und Konfiguration, Replikation, Software-Patches oder Cluster-Skalierung machen.

F: Was verwaltet Amazon DynamoDB für mich?

Amazon DynamoDB bietet die Lösung für eine der größten Herausforderungen beim Skalieren von Datenbanken: die Verwaltung der Datenbanksoftware und die zum Ausführen erforderliche Hardware-Bereitstellung. Unsere Kunden können in wenigen Minuten eine nicht-relationale Datenbank bereitstellen. DynamoDB partitioniert und repartitioniert Ihre Daten und stellt weitere Serverkapazitäten zur Verfügung, die bei wachsender Tabellengröße oder durch eine Erweiterung des bereitgestellten Durchsatzes erforderlich werden. Außerdem repliziert Amazon DynamoDB synchron Daten in mehreren Standorten einer AWS-Region und erzielt so eine hohe Verfügbarkeit und Datenbeständigkeit.

F: Was bedeutet Lesekonsistenz? Warum sollte sie mir wichtig sein?

Amazon DynamoDB speichert drei geografisch verteilte Kopien jeder Tabelle, um eine hohe Verfügbarkeit und Datenbeständigkeit zu gewährleisten. Die Lesekonsistenz bezeichnet die Art und zeitliche Abstimmung, mit der sich erfolgreiche Schreib- oder Aktualisierungsvorgänge eines Datenelements in einem anschließenden Lesevorgang dieses Elements widerspiegeln. Amazon DynamoDB bietet logische Funktionen, mit denen Sie die gewünschten Konsistenzmerkmale für alle Lesevorgänge der Anwendung festlegen können.

F: Wie lautet das Konsistenzmodell von Amazon DynamoDB?

Beim Lesen der Daten von Amazon DynamoDB können die Benutzer angeben, ob der Lesevorgang "Eventually Consistent" (schließlich konsistent) oder "Strongly Consistent" (stark konsistent) sein soll:

"Eventually Consistent"-Lesevorgänge (Standard) – Mit dieser Option wird der Lesedurchsatz optimiert. Bei dieser Art des Lesevorgangs sind eventuell erst vor kurzem abgeschlossene Schreibvorgänge noch nicht sichtbar. Eine Konsistenz in allen Datenkopien wird im Allgemeinen innerhalb von einer Sekunde erreicht. Bei einer Wiederholung des Lesevorgangs nach kurzer Zeit sollten die aktualisierten Daten angezeigt werden.

"Strongly Consistent"-Lesevorgänge – Zusätzlich zum ''Eventually Consistent''-Lesevorgang (schließlich konsistent) können Sie mit Amazon DynamoDB auch einen ''Strongly Consistent''-Lesevorgang (stark konsistent) auswählen, wenn Ihre Anwendung oder ein Element Ihrer Anwendung dies erfordert. Bei dieser Art des Lesevorgangs wird ein Ergebnis zurückgegeben, das alle erfolgreichen Schreibvorgänge einbezieht, die vor dem Lesevorgang erfolgt sind.

F: Unterstützt DynamoDB atomare Updates im Hintergrund?

Amazon DynamoDB unterstützt schnelle Updates im Hintergrund. Sie können den Wert numerischer Attribute in einer Zeile anhand eines einzigen API-Aufrufs erhöhen oder verringern. Sie können einen Zeichenfolgesatz ebenfalls atomar hinzufügen oder entfernen. Weitere Informationen zu atomaren Updates finden Sie in der Dokumentation.

F: Warum wird Amazon DynamoDB auf Solid State-Laufwerken ausgeführt?

Amazon DynamoDB wird ausschließlich auf Solid State-Laufwerken (SSDs) ausgeführt. Durch den Einsatz von Solid State-Laufwerken erreichen wir unsere gewünschten Ergebnisse: planbaren Reaktionszeiten mit geringen Latenzen für die Speicherung und für den Zugriff auf beliebig große Datenmengen. Aufgrund der hohen E-/A-Leistung von Solid State-Laufwerken können wir umfangreiche Arbeitslasten kosteneffizient bearbeiten und diesen effizienten Service kostengünstig anbieten.

F: Die Kosten für die DynamoDB-Speicherlösung erscheinen mir hoch. Ist dieser Service für meinen Anwendungsfall kostengünstig?

Wie bei jedem Produkt weisen wir interessierte Kunden für Amazon DynamoDB auf die Gesamtkosten einer Lösung hin. Es geht nicht nur um einen einzelnen Preis. Bei den Gesamtkosten für die Bereitstellung einer Datenbank müssen die erforderlichen Datenverkehrsanforderungen und die Menge der zu speichernden Daten berücksichtigt werden. Die meisten Anforderungen an Datenbanken beinhalten hohe E-/A-Vorgänge pro gespeichertem GB (d. h. hohe Lese- und Schreibvorgänge pro Sekunde). Amazon DynamoDB wird auf Solid State-Laufwerken ausgeführt, was die Kosten im Vergleich zu rotierenden Laufwerken pro gespeichertem GB erhöht. Wir können dadurch aber sehr geringe Anfragekosten anbieten. Wenn man eine gewöhnliche Datenbankarbeitslast betrachtet sind wir daher der Ansicht, dass die Gesamtkosten für die Nutzung des DynamoDB-Service auf SSD-Basis im Allgemeinen niedriger liegen werden als die Kosten einer herkömmlichen relationalen oder nicht-relationalen Datenbank auf rotierenden Laufwerken. Wenn Sie große Datenmengen speichern möchten, auf die nur selten zugegriffen wird, ist DynamoDB eventuell nicht die richtige Lösung für Sie. Wir empfehlen Ihnen in diesem Fall die Nutzung von S3.

Beachten Sie außerdem, dass die Speicherkosten die Kosten für mehrere Kopien der Datenelemente an mehreren Standorten in einer AWS-Region beinhalten.

F: Eignet sich DynamoDB nur für umfangreiche Anwendungen?

Nein. DynamoDB bietet eine nahtlose Skalierung. Sie können also klein anfangen und je nach Ihren Anforderungen die Skalierung erweitern oder verringern. Wenn Sie sich für alle Skalierungen eine schnelle und planbare Leistung wünschen, ist DynamoDB für Sie wahrscheinlich genau die richtige Lösung.

F: Was sind die ersten Schritte mit Amazon DynamoDB?

Klicken Sie für den Einstieg in Amazon DynamoDB auf "Anmelden". Danach können Sie mit Amazon DynamoDB beginnen. Verwenden Sie dazu die AWS Management Console oder die Amazon DynamoDB-APIs. Wenn Sie die AWS Management Console verwenden, können Sie mit Amazon DynamoDB eine Tabelle erstellen und sich die Lösung mit nur wenigen Klicks genauer ansehen.

F: Welche Abfragefunktionen unterstützt DynamoDB?

Amazon DynamoDB unterstützt GET/PUT-Operationen unter Verwendung eines benutzerdefinierten Primärschlüssels. Der Primärschlüssel ist das einzige erforderliche Attribut für Elemente in einer Tabelle und identifiziert jedes Element eindeutig. Sie legen den Primärschlüssel beim Erstellen einer Tabelle fest. Zusätzlich dazu bietet DynamoDB flexible Abfragen, da Sie die Möglichkeit haben, mithilfe globaler bzw. lokaler sekundärer Indizes Abfragen auf der Basis von Nicht-Primärschlüsselattributen durchzuführen.

Ein Primärschlüssel kann entweder ein Hash-Schlüssel mit einem einzigen Attribut oder ein zusammengesetzter Hash-Bereichsschlüssel sein. Ein Hash-Primärschlüssel mit einem einzigen Attribut wäre beispielsweise "UserID". Damit könnten Sie Daten für ein Element, das einer bestimmten Benutzer-ID zugewiesen wurde, schnell lesen und schreiben.

Ein zusammengesetzter Hash-Bereichsschlüssel wird als Hash-Schlüsselelement und als Bereichsschlüsselelement indiziert. Dieser mehrteilige Schlüssel bewahrt die Hierarchie zwischen den ersten und zweiten Elementwerten. Ein zusammengesetzter Hash-Bereichsschlüssel könnte beispielsweise eine Kombination aus "UserID" (Hash) und "Timestamp" (Bereich) sein. Wenn das Hash-Schlüsselelement konstant gehalten wird, können Sie im Bereichsschlüsselelement nach Elementen suchen. Das ermöglicht die Verwendung der Query-API, beispielsweise, um alle Elemente für eine einzelne Benutzer-ID und einen Bereich von Zeitstempeln abzufragen.

Weitere Informationen zu globalen sekundären Indizierung und ihrer Abfragemöglichkeiten finden Sie im Abschnitt Sekundäre Indizes der häufig gestellten Fragen.

F: Wie kann ich Datenelemente mit Amazon DynamoDB aktualisieren und abfragen?

Nachdem Sie mit der AWS Management Console oder der CreateTable-API eine Tabelle erstellt haben, können Sie mithilfe der PutItem- oder BatchWriteItem-APIs Elemente einfügen. Anschließend verwenden Sie "GetItem", "BatchGetItem" oder, falls zusammengesetzte Primärschlüssel aktiviert sind und in Ihrer Tabelle verwendet werden, die "Query"-API, um die der Tabelle hinzugefügten Elemente abzurufen.

F: Unterstützt Amazon DynamoDB bedingte Operationen?

Ja. Sie können eine Bedingung angeben, die zum Ausführen einer PUT-, Aktualisierungs- oder Löschoperation für ein Element erfüllt sein muss. Um eine bedingte Operation auszuführen, können Sie eine ConditionExpression definieren, die aus folgenden Elementen besteht:

  • Boolesche Funktionen: ATTRIBUTE_EXIST, CONTAINS und BEGINS_WITH
  • Vergleichsoperatoren: =, <>, BETWEEN und IN
  • Logische Operatoren: NOT, AND und OR. 

Sie können einen formatfreien bedingten Ausdruck erstellen, der mehrere bedingte Klauseln einschließlich verschachtelter Klauseln kombiniert. Mit bedingten Operationen können Benutzer optimistische Gleichzeitigkeitssteuerungssysteme unter DynamoDB implementieren. Weitere Informationen zu bedingten Operationen finden Sie in unserer Dokumentation.

F: Unterstützt Amazon DynamoDB Operationen zur Erhöhung oder Verringerung von Werten?

Ja. Mit Amazon DynamoDB sind atomare Operationen zur Erhöhung oder Verringerung von Skalarwerten möglich.

F: Wann sollte ich Amazon DynamoDB statt einer relationalen Datenbank-Engine unter Amazon RDS oder Amazon EC2 verwenden?

Die webbasierten Anwendungen von heute erstellen und verbrauchen Big Data. Beispielsweise beginnt ein Online-Spiel nur mit wenigen tausend Benutzern und mit einer geringen Datenbankarbeitslast von nur 10 Schreib- und 50 Lesevorgängen pro Sekunde. Wenn das Spiel jedoch erfolgreicher wird, wächst seine Benutzeranzahl möglicherweise schnell auf mehrere Millionen an und erzeugt zehntausende (oder sogar hunderttausende) von Schreib- und Lesevorgängen pro Sekunde. Auch können pro Tag mehrere Terabyte an Daten erzeugt werden. Wenn Sie Ihre Anwendungen für Amazon DynamoDB entwickeln, können Sie klein anfangen und Ihre Anforderungskapazität für eine Tabelle erweitern, sobald Ihre Bedarf steigt und zwar, ohne dass es dabei zu Ausfallzeiten kommt. Für die von Ihnen bereitgestellte Anforderungskapazität zahlen Sie sehr kostengünstige Preise. Amazon DynamoDB kümmert sich zudem um die Partitionierung Ihrer Daten und des Datenverkehrs über ausreichende Serverkapazitäten, die Ihren Anforderungen entsprechen. Amazon DynamoDB verwaltet die Datenbank – Sie müssen Ihre Daten lediglich speichern und abfragen. Durch die automatische Replikation und die Failover-Lösungen wird eine integrierte Fehlertoleranz, eine hohe Verfügbarkeit und Datenbeständigkeit gewährleistet. Mit Amazon DynamoDB haben Sie die beruhigende Sicherheit, dass Ihre Datenbank umfassend verwaltet wird und mit den Anforderungen Ihrer Anwendung mitwächst.

Amazon DynamoDB befasst sich mit den Kernproblemen von Datenbankskalierbarkeit, -verwaltung, -leistung und -zuverlässigkeit, verfügt jedoch nicht über den gesamten Funktionsumfang einer relationalen Datenbank. Komplexe relationale Abfragen (z. B. Joins) oder komplexe Transaktionen werden nicht unterstützt. Wenn Sie für Ihre Anwendung diese Funktionalität benötigen oder wenn Kompatibilität mit einer vorhandenen relationalen Engine erforderlich ist, ist es eventuell besser, wenn Sie eine relationale Engine mit Amazon RDS oder Amazon EC2 ausführen. Relationale Engines stellen zwar umfangreiche Features und Funktionen bereit, aber das Skalieren einer Arbeitslast über eine einzelne relationale Instanz hinaus ist sehr komplex und erfordert viel Zeit und Fachkenntnis. Wenn Sie also damit rechnen, dass Sie Ihre neue Anwendung skalieren müssen und keine relationalen Funktionen benötigen, ist Amazon DynamoDB wahrscheinlich besser für Sie geeignet.

F: Inwiefern unterscheidet sich Amazon DynamoDB von Amazon SimpleDB?

Welche Lösung sollte ich verwenden? Bei beiden Services handelt es sich um nicht-relationale Datenbanken, bei denen die Verwaltung der Datenbank entfällt. Amazon DynamoDB legt den Schwerpunkt auf nahtlose Skalierbarkeit und auf schnelle, planbare Leistung. Der Service wird auf Solid State-Laufwerken (SSDs) ausgeführt, was zu Reaktionszeiten mit geringen Latenzen führt. Es gibt zudem keinerlei Einschränkungen in Bezug auf die Anforderungskapazität oder die Speicherkapazität für eine bestimmte Tabelle. Das kommt daher, weil Amazon DynamoDB Ihre Daten und die Arbeitslast automatisch auf einer ausreichenden Anzahl von Servern partitioniert, um den von Ihnen bereitgestellten Skalierungsanforderungen gerecht zu werden. Im Gegensatz dazu, hat eine Tabelle in Amazon SimpleDB eine strenge Speicherbeschränkung von 10 GB und ist in der erreichbaren Anforderungskapazität eingeschränkt (meist durch weniger als 25 Schreibvorgänge/Sekunde). Zudem müssen Sie die Partitionierung und Repartitionierung Ihrer Daten über weitere SimpleDB-Tabellen selbst verwalten, wenn Sie skalieren möchten. SimpleDB hat zwar Einschränkungen bei der Skalierung, eignet sich jedoch eventuell gut für kleinere Arbeitslasten, bei denen es auf eine Abfrageflexibilität ankommt. Amazon SimpleDB indiziert automatisch alle Elementattribute und unterstützt auf diese Weise die Abfrageflexibilität – jedoch auf Kosten der Leistung und Skalierung.

Im DynamoDB-Blog von Amazon CTO Werner Vogels erhalten Sie weitere Informationen zur nicht-relationalen Datenbanktechnologie bei Amazon.

F: Wann sollte ich Amazon DynamoDB statt Amazon S3 verwenden?

Amazon DynamoDB speichert strukturierte Daten indiziert nach dem Primärschlüssel und ermöglicht Schreib- und Lesezugriff auf Elemente von 1 Byte bis zu 400 KB mit geringen Latenzen. Amazon S3 speichert unstrukturierte BLOBs und eignet sich zum Speichern großer Objekte mit bis zu 5 TB. Zur Kostenoptimierung sollten bei sämtlichen AWS-Services größere Objekte oder Datensätze, auf die nur selten zugegriffen wird, in Amazon S3 gespeichert werden, während kleinere Datenelemente und Dateizeiger (z. B. auf Amazon S3-Objekte) am besten in Amazon DynamoDB gespeichert werden.

F: Wird DynamoDB von Anwendungen auf allen Betriebssystemen unterstützt?

Ja. DynamoDB ist ein vollständig verwalteter Cloud-Service, auf den Sie über die API zugreifen können. DynamoDB wird von Anwendungen auf allen Betriebssystemen unterstützt (z. B. Linux, Windows, iOS, Android, Solaris, AIX, HP-UX etc.). Für den Einstieg in DynamoDB empfehlen wir die Verwendung von AWS SDKs. Eine Liste der AWS SDKs finden Sie auf unserer Seite für Entwicklerressourcen. Wenn Sie Probleme bei der Installation oder Verwendung einer unserer SDKs haben, informieren Sie uns bitte im entsprechenden AWS-Forum.


F: Was ist das Datenmodell?

Das Datenmodell für Amazon DynamoDB lautet wie folgt:

Tabelle: Eine Tabelle ist eine Datensammlung, genau wie eine Tabelle in einer relationalen Datenbank eine Sammlung von Zeilen ist. Jede Tabelle kann über eine unbegrenzte Anzahl von Datenelementen verfügen. Amazon DynamoDB verfügt über kein Schema. Die Datenelemente in einer Tabelle müssen also nicht über dieselben Attribute oder dieselbe Anzahl von Attributen verfügen. Jede Tabelle muss über einen Primärschlüssel verfügen. Der Primärschlüssel kann ein Schlüssel mit einem einzelnen Attribut oder ein zusammengesetzter Attributschlüssel sein, der zwei Attribute kombiniert. Das/Die Attribut(e), die Sie als Primärschlüssel definieren, müssen für jedes Element als Primärschlüssel vorhanden sein, da jedes Element mit dem Primärschlüssel eindeutig in der Tabelle identifiziert wird.

Element: Ein Element besteht aus einem Primärschlüssel oder einem zusammengesetzten Schlüssel und einer flexiblen Anzahl von Attributen. Es gibt keine ausdrückliche Einschränkung in Bezug auf die Anzahl der mit einem einzelnen Element verknüpften Attribute, aber die Gesamtgröße eines Elements, einschließlich aller Attributnamen und -werte, ist 400 KB.

Attribut: Jedes mit einem Datenelement verknüpfte Attribut besteht aus einem Attributnamen (z. B. "Farbe") und einem Wert oder einer Wertemenge (z. B. "Rot" oder "Rot, Gelb, Grün"). Einzelne Attribute verfügen über keine explizite Größenbeschränkung, aber die Gesamtgröße eines Elements (einschließlich aller Attributnamen und Werte) darf 400 KB nicht überschreiten.

F: Gibt es Beschränkungen bei der Elementgröße?

Die Gesamtgröße eines Elements, einschließlich der Attributnamen und –Werte, darf 400 KB nicht überschreiten.

F: Gibt es Beschränkungen in Bezug auf die Anzahl der Attribute, die ein Element haben kann?

Es gibt keine Beschränkungen in Bezug auf die Anzahl der Attribute, die ein Element haben kann. Die Gesamtgröße eines Elements, einschließlich der Attributnamen und –Werte, darf jedoch 400 KB nicht überschreiten.

F: Was sind die APIs?

  • CreateTable – Erstellt eine Tabelle und legt den für den Datenzugriff verwendeten Primärindex fest.
  • UpdateTable – Aktualisiert die Werte für den bereitgestellten Durchsatz einer angegebenen Tabelle.
  • DeleteTable – Löscht eine Tabelle.
  • DescribeTables – Gibt die Tabellengröße, den Status und Indexinformationen zurück.
  • ListTables – Gibt eine Liste aller Tabellen zurück, die dem aktuellen Konto und Endpunkt zugeordnet sind.
  • PutItem – Erstellt ein neues Element oder ersetzt ein altes durch ein neues Element (einschließlich aller Attribute). Wenn in der angegebenen Tabelle bereits ein Element mit demselben Primärschlüssel vorhanden ist, ersetzt das neue Element das vorhandene Element vollständig. Sie können auch Bedingungsoperatoren verwenden, um ein Element nur dann zu ersetzen, wenn dessen Attributwerte bestimmte Bedingungen erfüllen, oder um ein neues Element nur dann einzufügen, wenn es noch nicht vorhanden ist.
  • BatchWriteItem – Dient zum Einfügen, Ersetzen und Löschen mehrerer Elemente aus mehreren Tabellen in einer einzigen Anforderung, aber nicht in einer einzigen Transaktion. Unterstützt "Put"- oder "Delete"-Operationen für Stapel von bis zu 25 Elementen, bei einer maximalen Gesamtgröße der Anforderung von 1 MB.
  • UpdateItem – Bearbeitet die Attribute eines vorhandenen Elements. Sie können auch Bedingungsoperatoren verwenden, um eine Aktualisierung nur dann durchzuführen, wenn die Attributwerte eines Elements bestimmte Bedingungen erfüllen.
  • DeleteItem – Löscht ein einzelnes Element in einer Tabelle nach Primärschlüssel. Sie können auch Bedingungsoperatoren verwenden, um ein Element nur dann zu löschen, wenn die Attributwerte eines Elements bestimmte Bedingungen erfüllen.
  • GetItem – Die GetItem-Operation gibt einen Satz von Attributen für ein Element mit dem angegebenen Primärschlüssel zurück. Die GetItem-API führt standardmäßig einen "Eventually Consistent"-Lesevorgang durch. Wenn die Option "Eventually Consistent Read" für Ihre Anwendung nicht geeignet ist, verwenden Sie "ConsistentRead".
  • BatchGetItem – Die BatchGetItem-Operation gibt die Attribute für mehrere Elemente aus mehreren Tabellen anhand ihrer Primärschlüssel zurück. Die Größe einer einzelnen Antwort ist auf 1 MB begrenzt, und es werden maximal 100 Elemente zurückgegeben. Unterstützt die Optionen "Strongly Consistent" und "Eventually Consistent".
  • Query – Ruft ein oder mehrere Elemente mithilfe des Primärschlüssels der Tabelle oder mithilfe des Indexschlüssels aus einem sekundären Index ab. Sie können den Umfang der Abfrage einschränken, indem Sie Vergleichsoperatoren auf den Bereichsschlüsselwert anwenden. Sie können die Abfrageergebnisse auch mithilfe von Filtern für Nicht-Schlüsselattribute filtern. Unterstützt die Optionen "Strongly Consistent" und "Eventually Consistent". Eine einzelne Antwort ist auf eine Größe von 1 MB beschränkt.
  • Scan – Durchsucht die vollständige Tabelle und ruft ein oder mehrere Elemente und Attribute ab. Sie können Filter für ein oder mehrere Attribute festlegen und so die zurückgegebenen Elemente einschränken. Mit dieser API können Sie somit in einer Tabelle Ad-hoc-Abfragen nach Attributen durchführen, die sich nicht im Primärschlüssel der Tabelle befinden. Da allerdings die gesamte Tabelle ohne Index durchsucht wird, sollten Sie die Scan-API nicht für Anwendungsabfragen verwenden, bei denen eine planbare Leistung erforderlich ist. Der Ergebnissatz einer Scan-API-Anforderung ist "Eventually Consistent". Stellen Sie sich die Scan-API als Iterator vor. Sobald die Gesamtgröße der für eine bestimmte Scan-API-Anforderung durchsuchten Elemente einen Grenzwert von 1 MB überschreitet, wird die Anforderung beendet und die gefundenen Ergebnisse werden zusammen mit "LastEvaluatedKey" (um die Suche in einem folgenden Vorgang fortzusetzen) zurückgegeben.

F: Welche Datentypen werden von DynamoDB unterstützt?

DynamoDB unterstützt vier Skalardatentypen: Zahl, Zeichenfolge, Binärzahl und Boolescher Wert. Zusätzlich unterstützt DynamoDB Sammlungsdatentypen: Zahlensatz, Zeichenfolgensatz, Binärzahlensatz, heterogene Liste und heterogene Karte. Außerdem unterstützt DynamoDB NULL-Werte.

F: Welche Arten von Datenstrukturen unterstützt DynamoDB?

DynamoDB unterstützt Schlüssel-Wert- und Dokument-Datenstrukturen.

F: Was ist ein Schlüssel-Wert-Speicher?

Ein Schlüssel-Wert-Speicher ist ein Datenbankservice, der Unterstützung für das Speichern, Abfragen und Aktualisieren von Objektsammlungen bietet, die durch einen Schlüssel und Werte identifiziert werden, in denen der gespeicherte Inhalt enthalten ist.

F: Was ist ein Dokument-Speicher?

Ein Dokumentspeicher bietet Unterstützung für das Speichern, Abfragen und Aktualisieren von Elementen in einem Dokumentformat wie beispielsweise JSON, XML und HTML.

F: Welche Datenstrukturen werden von DynamoDB unterstützt?

DynamoDB unterstützt sowohl Schlüssel-Wert- als auch Dokument-Datenstrukturen. Mit DynamoDB können Sie mithilfe des Document SDK Dokumente im Format JSON speichern, abfragen und aktualisieren. Außerdem unterstützt DynamoDB das Speichern, Abfragen und Aktualisieren von Schlüssel-Wert-Sammlungen.

F: Verfügt DynamoDB über einen JSON-Datentyp?

Nein, aber Sie können das Document SDK verwenden, um JSON-Daten direkt an DynamoDB zu übergeben. Die Datentypen von DynamoDB sind eine übergeordnete Menge der Datentypen, die von JSON unterstützt werden. Das Document SDK ordnet JSON-Dokumente automatisch nativen DynamoDB-Datentypen zu.

F: Kann ich die AWS Management Console verwenden, um JSON-Dokumente anzuzeigen und zu bearbeiten?

Ja. The AWS Management Console bietet eine einfache Benutzeroberfläche zum Anzeigen und Bearbeiten der Daten, die in Ihren DynamoDB-Tabellen gespeichert sind, einschließlich JSON-Dokumenten. Um Daten in Ihrer Tabelle anzuzeigen oder zu bearbeiten, melden Sie sich bitte bei der AWS Management Console an, wählen dort "DynamoDB" und anschließend die anzuzeigende Tabelle. Klicken Sie dann auf die Schaltfläche "Explore Table".

F: Gibt es in DynamoDB Unterschiede bei der Abfrage von JSON-Daten?

Nein. Sie können für jedes JSON-Element der obersten Stufe einen globalen sekundären Index oder einen lokalen sekundären Index erstellen. Beispiel: Sie haben ein JSON-Dokument gespeichert, das die folgenden Informationen über eine Person enthält: Vorname, Nachname, PLZ sowie eine Liste ihrer Freunde. Vorname, Nachname und PLZ wären dann JSON-Elemente der obersten Stufe. Sie könnten einen Index erstellen, mit dem Sie Abfragen auf der Basis von Vorname, Nachname und PLZ durchführen können. Die Liste der Freunde ist kein Element der obersten Stufe. Daher können Sie die Liste der Freunde nicht indexieren. Weitere Informationen zur globalen sekundären Indizierung und ihrer Abfragemöglichkeiten finden Sie im Abschnitt "Sekundäre Indizes" der häufig gestellten Fragen.

F: Wenn ich JSON-Daten in DynamoDB verschachtelt habe, kann ich dann nur ein bestimmtes Element dieser Daten abrufen?

Ja. Wenn Sie die GetItem-, BatchGetItem-, Query- oder Scan-APIs verwenden, können Sie eine ProjectionExpression definieren, um festzulegen, welche Attribute aus der Tabelle abgerufen werden sollen. Diese Attribute können skalare Werte, Sätze oder Elemente eines JSON-Dokuments umfassen.

F: Wenn ich JSON-Daten in DynamoDB verschachtelt habe, kann ich dann nur ein bestimmtes Element dieser Daten aktualisieren?

Ja. Wenn Sie ein DynamoDB-Element aktualisieren, können Sie das Subelement des JSON-Dokuments angeben, das Sie aktualisieren wollen.


F: Gibt es Beschränkungen in Bezug auf die Datenmenge, die sich in Amazon DynamoDB speichern lässt?

Nein. Sie können jede beliebige Speichermenge in einer Amazon DynamoDB-Tabelle speichern. Wenn die Größe der Datensätze wächst, verteilt Amazon DynamoDB Ihre Daten automatisch über ausreichend Ressourcen, um Ihre Speicheranforderungen zufrieden zu stellen.

F: Gibt es Beschränkungen in Bezug auf die Durchsatzrate mit einer einzelnen Tabelle?

Nein. Sie können den für Ihre Tabelle bereitgestellten Durchsatz erhöhen, indem Sie die UpdateTable-API oder die AWS Management Console verwenden. DynamoDB kann mit großen Datenmenge arbeiten. Theoretisch gibt es keine Einschränkungen in Bezug auf den erreichbaren Durchsatz. DynamoDB teilt Ihre Tabelle automatisch auf mehrere Partitionen auf. Jede Partition ist eine unabhängige parallele Recheneinheit. DynamoDB kann immer höhere Durchsatzraten erreichen, indem immer mehr Partitionen hinzugefügt werden.

Wenn Sie Durchsatzraten von 10.000 Schreibvorgängen/Sekunde oder 10.000 Lesevorgängen/Sekunde überschreiten möchten, müssen Sie sich zuerst mithilfe dieses Online-Formulars an Amazon wenden.

F: Ist Amazon DynamoDB weiterhin verfügbar, wenn ich eine Erhöhung bzw. Verringerung des bereitgestellten Durchsatzes beantrage?

Ja. Amazon DynamoDB wurde so konzipiert, dass der bereitgestellte Durchsatz vergrößert oder verringert werden kann, aber die Lösung auch während dieser Zeit verfügbar bleibt.

F: Muss ich in der Amazon DynamoDB die kundenseitige Partitionierung verwalten?

Nein. Mit Amazon DynamoDB ist es nicht erforderlich, dass Datenbanktabellen partitioniert werden, um den Durchsatz verändern zu können.

F: Wie hochgradig verfügbar ist Amazon DynamoDB?

Der Service wird auf den bewährten Amazon Datencentern mit hoher Verfügbarkeit ausgeführt. Der Service repliziert Daten über drei Standorte in einer AWS-Region hinweg und bietet so eine Fehlertoleranz bei eventuellen Server- oder Availability Zone-Ausfällen.

F: Wie erzielt Amazon DynamoDB eine hohe Verfügbarkeit und Beständigkeit?

Damit eine hohe Verfügbarkeit und Beständigkeit erzielt werden kann, repliziert Amazon DynamoDB Daten über drei Standorte in einer AWS-Region hinweg.


F: Was sind globale sekundäre Indizes?

Globale sekundäre Indizes sind Indizes mit Hash- oder Hash- und Bereichsschlüsseln, die sich von den Schlüsseln in der Tabelle unterscheiden können, auf denen der Index basiert.

Für einen effizienten Zugriff auf Daten in einer Tabelle erstellt und verwaltet Amazon DynamoDB Indizes für die primären Schlüsselattribute. Dadurch können Anwendungen Daten durch Angeben von Primärschlüsselwerten schneller abrufen. Doch viele Anwendungen können ggf. davon profitieren, wenn ein oder mehrere sekundäre (oder alternative) Schlüssel verfügbar sind, die einen effizienten Zugriff auf Daten mit Attributen zulassen, die sich vom Primärschlüssel unterscheiden. Zu diesem Zweck können Sie einen oder mehrere sekundäre Indizes für eine Tabelle erstellen und Abfrageanforderungen an diese Indizes richten.

Amazon DynamoDB unterstützt zwei Typen sekundärer Indizes:

  • Lokaler sekundärer Index – Ein Index, der denselben Hash-Schlüssel wie die Tabelle, aber einen anderen Bereichsschlüssel aufweist. Ein lokaler sekundärer Index ist dahingehend "lokal", dass jede Partition eines lokalen sekundären Indexes einer Tabellenpartition mit demselben Hash-Schlüssel zugeordnet ist.
  • Globaler sekundärer Index – Ein Index mit einem Hash- oder Hash- und Bereichsschlüssel, der sich von dem für die Tabelle unterscheiden kann. Ein globaler sekundärer Index gilt als "global", da Abfragen des Indexes alle Elemente einer Tabelle in sämtlichen Partitionen umfassen können. 

Sekundäre Indizes werden von Amazon DynamoDB automatisch als platzsparende Objekte gepflegt. Elemente werden nur in einem Index angezeigt, wenn sie in der Tabelle vorhanden sind, für die der Index definiert ist. Dadurch erfolgen Abfragen eines Indexes sehr effizient, da die Anzahl der Elemente im Index oft beträchtlich unter der Anzahl der Elemente in einer Tabelle liegt.

Globale sekundäre Indizes unterstützen nicht eindeutige Attribute, wodurch sich die Abfrageflexibilität erhöht, indem Abfragen beliebiger Nicht-Schlüsselattribute in der Tabelle ermöglicht werden.

Betrachten wir z. B. eine Spieleanwendung, in der die Informationen der Spieler in einer DynamoDB-Tabelle gespeichert werden, deren Primärschlüssel aus Benutzer-ID (Hash) und Spieltitel (Bereich) besteht. Elemente haben Attributnamen wie u. a HighScore, Zeitstempel und PLZ. Bei Erstellung der Tabelle stellt DynamoDB einen impliziten (primären) Index für den Primärschlüssel bereit, der effiziente Abfragen unterstützen kann, die den High Score eines bestimmten Benutzers für alle Spiele zurückgeben.

Wenn die Anwendung hingegen die High Scores von Benutzern für ein bestimmtes Spiel anfordert, wäre das Verwenden dieses primären Indexes nicht effizient, da ein Suchvorgang durch die gesamte Tabelle erforderlich wäre. Stattdessen ermöglicht ein globaler sekundärer Index mit "Spieltitel" als Hash-Schlüsselelement und "HighScore" als Bereichsschlüsselelement der Anwendung einen raschen Abruf der High Scores eines Spiels.

Ein globaler sekundärer Index muss über kein Bereichsschlüsselelement verfügen. Beispielsweise ist ein globaler sekundärer Index mit einem Schlüssel möglich, der nur das eine Hash-Element Spieltitel aufweist. Im nachstehenden Beispiel hat der globale sekundäre Index keine projizierten Attribute, weshalb er alle (vom Primärschlüssel bestimmten) Elemente zurückgibt, die ein Attribut aufweisen, das dem Spieltitel in Ihrer Abfrage entspricht.

F: Wann sollte ich globale sekundäre Indizes nutzen?

Globale sekundäre Indizes eignen sich besonders für das Nachverfolgen von Beziehungen zwischen Attributen mit vielen verschiedenen Werten. Sie können beispielsweise eine DynamoDB-Tabelle mit Kunden-ID als primären Hash-Schlüssel für die Tabelle und PLZ als Hash-Schlüssel für einen globalen sekundären Index erstellen, da es viele Postleitzahlen gibt und Sie wahrscheinlich über viele Kunden verfügen. Mithilfe des Primärschlüssels können Sie anschließend rasch den Datensatz des gewünschten Kunden abrufen. Mithilfe des globalen sekundären Indexes können Sie effizient alle Kunden abfragen, die in einem bestimmten Postleitzahlbereich leben.

Um sicherzustellen, dass Sie die globale sekundäre Indexfunktion optimal nutzen, lesen Sie unsere Dokumentation mit bewährten Methoden für einheitliche Verarbeitungslasten.

F: Wie erstelle ich einen globalen sekundären Index für eine DynamoDB-Tabelle?

Alle globalen sekundären Indizes müssen zum Zeitpunkt der Erstellung der Tabelle angegeben werden. Derzeit ist es nicht möglich, nach Erstellung einer Tabelle einen globalen sekundären Index hinzuzufügen. Detaillierte Anweisungen zum Erstellen einer Tabelle und ihrer Indizes finden Sie hier. Pro Tabelle können Sie maximal 5 globale sekundäre Indizes erstellen.

F: Unterstützt DynamoDB Local globale sekundäre Indizes?

Ja. DynamoDB Local ist eine Offline-Version von DynamoDB, die sich zum Entwickeln und Testen von Anwendungen mit DynamoDB-Unterstützung eignet. Die neueste Version von DynamoDB Local können Sie hier herunterladen.

F: Was sind projizierte Attribute?

Die Daten in einem sekundären Index bestehen aus Attributen, die aus der Tabelle in den Index projiziert, d. h. kopiert, werden. Beim Erstellen eines sekundären Indexes definieren Sie den alternativen Schlüssel für den Index sowie andere Attribute, die Sie in den Index projizieren möchten. Amazon DynamoDB kopiert diese Attribute gemeinsam mit den Primärschlüsselattributen der Tabelle in den Index. Sie können den Index anschließend wie eine Tabelle abfragen.

F: Kann ein globaler sekundärer Indexschlüssel für nicht eindeutige Attribute definiert werden?

Ja. Im Gegensatz zum Primärschlüssel einer Tabelle müssen in einem globalen sekundären Indexschlüssel die indizierten Attribute nicht eindeutig sein. Ein globaler sekundärer Index für Spieltitel kann beispielsweise alle Elemente indizieren, in denen die Punkte der Benutzer in jedem Spiel erfasst werden. Bei diesem Beispiel kann dieser globale sekundäre Index abgefragt werden, um alle Benutzer zurückzugeben, die "TicTacToe" gespielt haben.

F: Wie unterscheiden sich globale sekundäre Indizes von lokalen sekundären Indizes?

Sowohl globale als auch lokale sekundäre Indizes verbessern die Abfrageflexibilität. Ein lokaler sekundärer Index wird einem bestimmten Primärschlüssel-Hash-Wert zugeordnet, während ein globaler sekundärer Index alle Primärschlüssel-Hash-Werte umfasst. Da Elemente mit demselben Primärschlüssel-Hash-Wert in DynamoDB dieselbe Partition gemeinsam nutzen, deckt der "lokale" sekundäre Index nur Elemente ab, die (in derselben Partition) gemeinsam gespeichert sind. Demzufolge ist der Zweck des lokalen sekundären Indexes das Abfragen von Elementen mit demselben Primärschlüssel-Hash-Wert, jedoch einem anderen Bereichsschlüssel. Nehmen wir als Beispiel eine DynamoDB-Tabelle zum Nachverfolgen von Kundenbestellungen, wobei Kunden-ID der Primärschlüssel ist.

Ein lokaler sekundärer Index für Bestellzeit ermöglicht ein effizientes Abfragen der von einem bestimmten Kunden zuletzt bestellten Artikel.

Im Gegensatz dazu ist ein globaler sekundärer Index nicht auf Elemente mit einem gemeinsamen Primärschlüssel-Hash-Wert beschränkt. Dieser Indextyp umfasst stattdessen ebenso wie der implizite primäre Index alle Elemente in der Tabelle. Bei der obigen Tabelle kann ein globaler sekundärer Index für Produkt-ID zum Auffinden aller Bestellungen eines bestimmten Produkts effizient genutzt werden. Beachten Sie, dass in diesem Fall kein Bereichsschlüssel für den globalen sekundären Index angegeben wird. Und selbst wenn es viele Bestellungen mit derselben Produkt-ID gibt, werden diese im globalen sekundären Index als getrennte Elemente gespeichert.

Um sicherzustellen, dass Daten in der Tabelle und der Index sich zusammen in der selben Partition befindet, ist bei lokalen sekundären Indizes die Gesamtgröße aller Elemente (Tabellen und Indizes) auf 10 GB pro Hash-Schlüsselwert begrenzt. Bei globalen sekundären Indizes wird die gemeinsame Speicherung nicht erzwungen und es gilt auch keine solche Einschränkung.

Wenn Sie Daten in eine Tabelle schreiben, aktualisiert DynamoDB atomisch alle betroffenen lokalen sekundären Indizes. Im Gegensatz dazu sind alle für die Tabelle definierten globalen sekundären Indizes schließlich konsistent.

Lokale sekundäre Indizes ermöglichen der Query-API das Abrufen von Attributen, die nicht zur Projektionsliste gehören. Dieses Verhalten wird von globalen sekundären Indizes nicht unterstützt.

F: Wie funktionieren globale sekundäre Indizes?

Auf viele Weisen ähnelt das Verhalten globaler sekundärer Indizes dem einer DynamoDB-Tabelle. Sie können einen globalen sekundären Index mithilfe seines Hash-Schlüsselelements mit Bedingungsfiltern für das Bereichsschlüsselelement des globalen sekundären Indexes abfragen. Doch im Gegensatz zu einem Primärschlüssel einer DynamoDB-Tabelle, die eindeutig sein muss, kann ein globaler sekundärer Indexschlüssel für mehrere Elemente identisch sein. Wenn mehrere Elemente mit demselben globalen sekundären Indexschlüssel vorhanden sind, werden diese als gesonderte globale sekundäre Indexelemente nachverfolgt und eine Abfrage des globalen sekundären Indexes ruft diese alle als einzelne Elemente ab. Intern stellt DynamoDB sicher, dass der Inhalt des globalen sekundären Indexes beim Hinzufügen, Entfernen und Aktualisieren von Elementen entsprechend auf den neuesten Stand gebracht wird.

DynamoDB speichert die projizierten Attribute eines globalen sekundären Indexes in dessen Datenstruktur zusammen mit dem globalen sekundären Indexschlüsseln und den Primärschlüsseln der übereinstimmenden Elemente. Globale sekundäre Indizes belegen Speicher für projizierte Elemente, die in der Quelltabelle vorhanden sind. Dadurch können Abfragen auf den globalen sekundären Index anstatt auf die Tabelle angewendet werden, wodurch sich die Abfrageflexibilität und die Verteilung der Verarbeitungslast verbessern. Attribute, die zu einem Element in einer Tabelle, jedoch nicht zum globalen sekundären Indexschlüssel, zum Primärschlüssel der Tabelle oder den projizierten Attributen gehören, werden demzufolge bei einer Abfrage des globalen sekundären Indexes nicht zurückgegeben. Anwendungen, die nach Abfragen des globalen sekundären Indexes weitere Daten aus der Tabelle benötigen, können den Primärschlüssel aus dem globalen sekundären Index abrufen und anschließend entweder mit der GetItem- oder der BatchGetItem-API die gewünschten Attribute aus der Tabelle abrufen. Da globale sekundäre Indizes schließlich konsistent sind, müssen Anwendungen, die dieses Muster befolgen, zwischen den Aufrufen an den globalen sekundären Index und von "GetItem/BatchItem" das Löschen von Elementen (aus der Tabelle) unterstützen. 

DynamoDB verarbeitet das Hinzufügen, Aktualisieren und Löschen von Elementen in einem globalen sekundären Index, wenn entsprechende Änderungen an der Tabelle erfolgen. Wenn ein Element (mit Attributen des globalen sekundären Indexschlüssels) der Tabelle hinzugefügt wird, aktualisiert DynamoDB den globalen sekundären Index zum Hinzufügen des neuen Elements asynchron. Wenn ein Element aus der Tabelle gelöscht wird, entfernt DynamoDB das Element aus dem betroffenen globalen sekundären Index.

F: Kann ich globale sekundäre Indizes für Hash-basierte Tabellen und Hash-Bereichsschematabellen erstellen?

Sie können einen globalen sekundären Index unabhängig vom Typ des Primärschlüssels der DynamoDB-Tabelle erstellen. Die Tabelle kann bloß einen primären Hash-Schlüssel oder einen primären Hash- und Bereichsschlüssel aufweisen.

F: Welches Konsistenzmodell gilt für globale sekundäre Indizes?

Globale sekundäre Indizes unterstützen die schließliche Konsistenz. Wenn Elemente in eine Tabelle eingefügt oder aktualisiert werden, werden globale sekundäre Indizes nicht synchron aktualisiert. Unter normalen Betriebsbedingungen wird ein Schreibvorgang in einen globalen sekundären Index im Bruchteil einer Sekunde übernommen. In unwahrscheinlichen Ausfallszenarien können längere Verzögerungen auftreten. Aus diesem Grund muss Ihre Anwendungslogik die Verarbeitung von Ergebnissen der Abfrage des globalen sekundären Indexes unterstützen, die möglicherweise veraltet sind. Beachten Sie, dass dieses Verhalten dem anderer DynamoDB-APIs entspricht, die schließlich konsistente Lesevorgänge unterstützen.

Betrachten wir nun eine Tabelle, in der High Scores erfasst werden und in der jedes Element die Attribute Benutzer-ID, Spieltitel und HighScore aufweist. Der primäre Hash-Schlüssel ist Benutzer-ID, der primäre Bereichsschlüssel ist Spieltitel. Wenn die Anwendung ein Element mit einem neuen High Score für den Spieltitel "TicTacToe" und die Benutzer-ID "SPIELER123" hinzufügt und anschließend den globalen sekundären Index abfragt, ist es möglich, dass der neue Punktwert nicht im Abfrageergebnis enthalten ist. Doch sobald die Übernahme in den globalen sekundären Index abgeschlossen ist, wird das neue Element in solchen Abfragen des globalen sekundären Indexes angezeigt.

F: Kann ich für die Tabelle und jeden globalen sekundären Index getrennt Durchsatzkapazität bereitstellen?

Ja. Bei globalen sekundären Indizes wird der Durchsatz unabhängig von der Tabelle verwaltet, auf der diese basieren. Sie müssen zum Zeitpunkt der Erstellung der Tabelle und aller dazugehörigen globalen sekundären Indizes den bereitgestellten Durchsatz explizit angeben. Über den Create Table Wizard in der DynamoDB-Konsole können Sie Ihren gesamten Durchsatz auf Ihre Tabellen und Indizes verteilen.

Je nach Anwendung kann sich die Verarbeitungslast von Anforderungen an einen globalen sekundären Index beträchtlich von denen an die Tabelle oder andere globale sekundäre Indizes unterscheiden. Die folgenden Szenarien dienen der Veranschaulichung:

  • Ein globaler sekundärer Index, der einen kleinen Bruchteil der Tabellenelemente enthält, benötigt im Vergleich zur Tabelle einen wesentlich niedrigeren Schreibdurchsatz.
  • Ein globaler sekundärer Index, der für seltene Nachschlagevorgänge von Elementen verwendet wird, benötigt im Vergleich zur Tabelle einen wesentlich niedrigeren Lesedurchsatz.
  • Ein globaler sekundärer Index, der von einer leseintensiven Hintergrundaufgabe verwendet wird, benötigt einige Stunden am Tag ggf. einen hohen Lesedurchsatz.

Je nachdem, wie sich Ihre Anforderungen entwickeln, können Sie den bereitgestellten Durchsatz des globalen sekundären Indexes unabhängig vom bereitgestellten Durchsatz der Tabelle ändern.

Nehmen wir eine DynamoDB-Tabelle mit einem globalen sekundären Index, der alle Attribut projiziert, und bei der der globale sekundäre Indexschlüssel bei 50 % der Elementen vorhanden ist. In diesem Fall muss die dem globalen sekundären Index bereitgestellte Schreibkapazität auf 50 % der bereitgestellten Schreibkapazitätseinheiten der Tabelle festgelegt werden. Bei Wahl eines ähnlichen Ansatzes kann der Lesedurchsatz des globalen sekundären Indexes geschätzt werden. Weitere Details finden Sie in der DynamoDB-Dokumentation zu globalen sekundären Indizes.

F: Wie wirkt sich das Hinzufügen eines globalen sekundären Indexes auf den bereitgestellten Durchsatz und die Speicherung einer Tabelle aus?

Ähnlich wie eine DynamoDB-Tabelle belegt ein globaler sekundärer Index bereitgestellten Durchsatz, wenn Lese- oder Schreibvorgänge auf ihn angewendet werden. Ein Schreibvorgang zum Hinzufügen oder Aktualisieren eines Elements eines globalen sekundären Indexes belegt basierend auf der Größe der Aktualisierung Schreibkapazitätseinheiten. Die vom Schreibvorgang des globalen sekundären Indexes belegte Kapazität wird zusätzlich zu derjenigen belegt, die zum Aktualisieren des Elements in der Tabelle benötigt wird.

Wenn Sie ein Element in einer DynamoDB-Tabelle hinzufügen, löschen oder aktualisieren und dies nicht zu einer Änderung am globalen sekundären Index führt, belegt dieser keine Schreibkapazitätseinheiten. Dies geschieht, wenn ein Element ohne globale sekundäre Indexschlüsselattribute der DynamoDB-Tabelle hinzugefügt wird oder ein Element aktualisiert wird, ohne einen globalen sekundären Indexschlüssel oder projizierte Attribute zu ändern.

Eine Abfrage eines globalen sekundären Indexes belegt Lesekapazitätseinheiten basierend der auf Größe der Elemente, die von der Abfrage untersucht werden.

Die Speicherkosten eines globalen sekundären Indexes basieren auf der Gesamtanzahl der in ihm gespeicherten Bytes. Dies umfasst den globalen sekundären Indexschlüssel sowie die projizierten Attribute und Werte und zusätzlich 100 Bytes für Indizierungszwecke.

F: Kann DynamoDB die Schreibvorgänge meiner Anwendung in eine Tabelle aufgrund eines für einen globalen sekundären Index bereitgestellten Durchsatzes einschränken?

Da einige oder alle Schreibvorgänge in eine DynamoDB-Tabelle in Schreibvorgängen in dazugehörige globale sekundäre Indizes resultieren, ist es möglich, dass der bereitgestellte Durchsatz eines globalen sekundären Indexes sich erschöpft. In einem solchen Szenario werden Schreibvorgänge in die Tabelle eingeschränkt. Dies kann auch dann passieren, wenn die Tabelle verfügbare Schreibkapazitätseinheiten aufweist.

F: Wie oft kann ich den bereitgestellten Durchsatz auf Indexebene ändern?

Bei Tabellen mit globalen sekundären Indizes gelten dieselben täglichen Obergrenzen für die Anzahl der Vorgänge zur Durchsatzänderung wie bei normalen Tabellen.

F: Wie wird mir ein globaler sekundärer Index in DynamoDB in Rechnung gestellt?

Ihnen wird für den gesamten bereitgestellten Durchsatz für eine Tabelle und ihre globalen sekundären Indizes ein Stundentarif in Rechnung gestellt. Darüber hinaus zahlen Sie für den vom globalen sekundären Index belegten Datenspeicher und die standardmäßigen (externen) Datenübertragungsgebühren. Wenn Sie die bereitgestellte Durchsatzkapazität für Ihren globalen sekundären Index ändern möchten, können Sie dies über die DynamoDB-Konsole oder UpdateTable-API vornehmen.

F: Kann ich angeben, welcher globale sekundäre Index für eine Abfrage verwendet werden soll?

Ja. Zusätzlich zu den allgemeinen Abfrageparametern enthält ein Query-Befehl für einen globalen sekundären Index explizit den Namen des globalen sekundären Indexes, der verwendet werden soll. Beachten Sie, dass eine Abfrage nur einen globalen sekundären Index nutzen kann.

F: Welche API-Aufrufe werden von einem globalen sekundären Index unterstützt?

Die von einem globalen sekundären Index unterstützten API-Aufrufe sind Query und Scan. Ein Query-Vorgang durchsucht nur Attributwerte von Indexschlüsseln und unterstützt eine Teilmenge der Vergleichsoperatoren. Da globale sekundäre Indizes asynchron aktualisiert werden, können Sie den Parameter ConsistentRead nicht mit der Abfrage verwenden. Hier finden Sie Details zum Verwenden von globalen sekundären Indizes mit Abfragen und Suchvorgängen.

F: Wie ändere oder lösche ich einen globalen sekundären Index nach der Tabellenerstellung?

Indizes können nach dem Erstellen der Tabelle nicht erstellt, geändert oder gelöscht werden.

F: Sind globale sekundäre Indexschlüsselattribute für alle Elemente einer DynamoDB-Tabelle erforderlich?

Nein. Globale sekundäre Indizes sind platzsparende Indizes. Im Gegensatz zum vorgeschriebenen Primärschlüssel muss ein Element in einer DynamoDB-Tabelle keine globalen sekundären Indexschlüssel enthalten. Wenn ein globaler sekundärer Indexschlüssel sowohl Hash- als auch Bereichselemente aufweist und bei einem Tabellenelement eines von beiden weggelassen wird, dann wird dieses Element nicht vom dazugehörigen globalen sekundären Index indiziert. In diesen Fällen eignet sich ein globaler sekundärer Index besonders für das effiziente Bestimmen von Elementen mit einem ungewöhnlichen Attribut.

F: Kann ich alle Attribute einer DynamoDB-Tabelle aus einem globalen sekundären Index abrufen?

Eine Abfrage eines globalen sekundären Indexes kann nur Attribute zurückgeben, die zum Zeitpunkt der Erstellung dem globalen sekundären Index hinzugefügt wurden. Die im globalen sekundären Index enthaltenen Attribute sind diejenigen, die standardmäßig projiziert werden, z. B. die Schlüsselattribute des globalen sekundären Indexes und die Primärschlüsselattribute der Tabelle, und diejenigen, die der Benutzer für die Projektion angegeben hat. Aus diesem Grund gibt eine Abfrage eines globalen sekundären Indexes keine Attribute von Elementen zurück, die zwar Teil der Tabelle, aber nicht im globalen sekundären Index enthalten sind. Ein globaler sekundärer Index, bei dem alle Attribute als projizierte Attribute angegeben sind, kann zum Abrufen beliebiger Tabellenattribute genutzt werden. Hier finden Sie Dokumentation zum Verwenden globaler sekundärer Indizes für Abfragen.

F: Wie kann ich einer Tabelle zugeordnete globale sekundäre Indizes auflisten?

Die DescribeTable-API gibt detaillierte Informationen zu globalen sekundären Indizes für eine Tabelle zurück.

F: Welche Datentypen können indiziert werden?

Alle skalaren Datentypen (Number, String, Binary und Boolesch) können als Bereichsschlüsselelement des lokalen sekundären Indexschlüssels verwendet werden. Die Datentypen Set, List und Map können nicht indexiert werden.

F: Sind zusammengesetzte Attributindizes möglich?

Nein. Sie können jedoch Attribute zu einer Zeichenfolge verketten und diese als Schlüssel nutzen.

F: Welche Datentypen können zu den projizierten Attributen eines globalen sekundären Indexes gehören?

Sie können Attribute mit beliebigen Datentypen (auch vom Typ "Set") für die Projektion in einen globalen sekundären Index angeben.

F: Welche Aspekte bei der Skalierbarkeit gelten für globale sekundäre Indizes?

Die Leistungsaspekte des Primärschlüssels einer DynamoDB-Tabelle gelten auch für globale sekundäre Indexschlüssel. Ein globaler sekundärer Index setzt ein relativ zufälliges Zugriffsmuster in allen seinen Schlüsseln voraus. Um den bereitgestellten Durchsatz für den sekundären Index optimal auszunutzen, müssen Sie für den globalen sekundären Index ein Hash-Schlüsselelement mit einer großen Anzahl eindeutiger Werte und ein Bereichsschlüsselelement wählen, das relativ einheitlich und so zufällig wie möglich abgefragt wird.

F: Welche neuen Metriken stehen in CloudWatch für globale sekundäre Indizes zur Verfügung?

Für Tabellen mit globalem sekundärem Index werden Gesamtmetriken für die Tabelle und Indizes mit Aufschlüsselungen der Metriken für die Tabelle und jeden einzelnen globalen sekundären Index bereitgestellt.

In Berichten zu einzelnen globalen sekundären Indizes wird eine Teilmenge der CloudWatch-Metriken unterstützt, die von einer Tabelle unterstützt werden. Dazu zählen:

  • Lesekapazität (ProvisionedReadCapacityUnits, ConsumedReadCapacityUnits)
  • Schreibkapazität (ProvisionedWriteCapacityUnits, ConsumedWriteCapacityUnits)
  • Eingeschränkte Leseereignisse (ReadThrottleEvents)
  • Eingeschränkte Schreibereignisse (WriteThrottleEvents)

Details zu von DynamoDB-Tabellen unterstützten Metriken und Indizes finden Sie hier.

F: Ist für meine Tabellen und Indizes in DynamoDB eine automatische Skalierung möglich?

Systeminhärent wird diese Funktion nicht unterstützt. Im Abschnitt Entwicklerressourcen auf der DynamoDB-Webseite finden Sie jedoch Bibliotheken anderer Anbieter.


F: Was sind lokale sekundäre Indizes?

Lokale sekundäre Indizes ermöglichen bei einigen gängigen Abfragen eine schnellere und wirtschaftlichere Ausführung, bei denen andernfalls das Abrufen einer großen Anzahl von Elementen und anschließende Filtern der Ergebnisse erforderlich wäre. Dies bedeutet, dass Ihre Anwendungen flexiblere Abfragen basierend auf einer größeren Anzahl von Attributen unterstützen können.

Wenn Sie vor der Einführung lokaler sekundärer Indizes bestimmte Elemente in einem Hash-Schlüssel-Bucket (mit demselben Hash-Schlüssel) finden wollten, musste DynamoDB alle Objekte mit demselben Hash-Schlüssel abrufen und die Ergebnis entsprechend filtern. Angenommen, in einer E-Commerce-Anwendung werden Kundenauftragsdaten in einer DynamoDB-Tabelle mit dem Hash-Bereichsschema "Kunden-ID-Zeitstempel des Auftrags" gespeichert. Ohne lokale sekundäre Indizes hätten Sie zum Erfüllen der Anforderung "Alle Aufträge des Kunden X mit Lieferdatum in den letzten 30 Tagen sortiert nach Lieferdatum anzeigen" die Query-API verwenden, um alle Objekte unter dem Hash-Schlüssel "X" abzurufen, die Ergebnisse nach dem Lieferdatum sortieren und anschließend ältere Datensätze herausfiltern müssen.

Dank lokaler sekundärer Indizes wird dieser Vorgang vereinfacht. Nun können Sie einen Index für das Attribut "Lieferdatum" erstellen und diese Abfrage so ausführen, dass nur die gewünschten Elemente zurückgegeben werden. Dadurch werden Latenz und Kosten Ihrer Abfragen spürbar verringert, da Sie nur die Elemente abrufen, die Ihre spezifischen Kriterien erfüllen. Darüber hinaus wird das Programmierungsmodell Ihrer Anwendung vereinfacht, da Sie zum Filtern der Ergebnisse keine Kundenlogik mehr schreiben müssen. Wir bezeichnen diesen neuen sekundären Index als "lokal", da er zusammen mit dem Hash-Schlüssel verwendet wird und demzufolge das lokale Suchen in einem Hash-Schlüssel-Bucket zulässt. Während Sie zuvor nur anhand des Hash- und Bereichsschlüssels suchen konnten, können Sie nun anstelle des Bereichsschlüssels mithilfe eines sekundären Indexes suchen. Dadurch erhöht sich die Anzahl der Attribute, die für die effizientere Ausführung von Abfragen genutzt werden können.

Redundante Kopien von Datenattributen werden in die von Ihnen definierten lokalen sekundären Indizes kopiert. Diese Attribute umfassen den Tabellen-Hash- und Bereichsschlüssel sowie den von Ihnen definierten alternativen Bereichsschlüssel. Sie können im lokalen sekundären Index auch weitere Dateiattribute redundant speichern, um auf diese anderen Attribute zugreifen zu können, ohne auf die Tabelle selbst zugreifen zu müssen.

Lokale sekundäre Indizes sind nicht für alle Anwendungen geeignet. Mit ihnen einher gehen Einschränkungen bei der Datenmenge, die in einem einzelnen Hash-Schlüsselwert gespeichert werden kann. Weitere Informationen finden Sie in den häufig gestellten Fragen zu Elementauflistungen.

F: Was sind Projektionen?

Die Gruppe von Attributen, die im lokalen sekundären Index gespeichert ist, wird als Projektion bezeichnet. Die Projektion bestimmt die Attribute, die Sie mit der höchsten Effizienz abrufen können. Wenn Sie einen lokalen sekundären Index abfragen, kann Amazon DynamoDB auf beliebige der projizierten Attribute zugreifen, und zwar mit denselben Leistungsmerkmalen, als wären diese Attribute in einer eigenen Tabelle enthalten. Wenn Sie Attribute abrufen müssen, die nicht projiziert sind, ruft Amazon DynamoDB diese Attribute automatisch aus der Tabelle ab.

Wenn Sie einen lokalen sekundären Index definieren, müssen Sie die Attribute angeben, die in den Index projiziert werden. Jeder Indexeintrag besteht mindestens auf Folgendem: (1.) dem Hash-Schlüsselwert der Tabelle, (2.) einem Attribut, das als Indexbereichsschlüssel fungiert, und (3.) dem Schlüsselwert des Tabellenbereichs.

Über diese Mindestanforderungen hinaus können Sie auch eine benutzerdefinierte Liste anderer Nicht-Schlüsselattribute auswählen, die in den Index projiziert werden sollen. Sie können nach Wunsch auch alle Attribute in den Index projizieren. In diesem Fall repliziert der Index dieselben Daten wie die Tabelle selbst. Doch die Daten werden anhand eines von Ihnen angegebenen alternativen Bereichsschlüssels organisiert.

F: Wie kann ich einen lokalen sekundären Index erstellen?

Ein lokaler sekundärer Index muss zum Zeitpunkt der Erstellung der Tabelle angelegt werden. Derzeit ist es nicht möglich, ihn später hinzuzufügen. Geben Sie zum Erstellen eines lokalen sekundären Indexes die folgenden beiden Parameter an:

Schlüssel des indizierten Bereichs – Das Attribut, das indiziert und abfragt wird.

Projizierte Attribute – Die Liste mit Attributen aus der Tabelle, die direkt in den lokalen sekundären Index kopiert wird, damit diese schneller zurückgegeben werden können, ohne Daten aus dem primären Index abzurufen, der alle Elemente der Tabelle enthält. Ohne projizierte Attribute enthält ein lokaler sekundärer Index nur primäre und sekundäre Indexschlüssel.

F: Was ist das Konsistenzmodell für lokale sekundäre Indizes?

Lokale sekundäre Indizes werden automatisch aktualisiert, wenn der primäre Index aktualisiert wird. Ähnlich wie bei Lesevorgängen in einem primären Index unterstützt ein lokaler sekundärer Index die Leseoptionen "Strongly Consistent" und "Eventually Consistent".

F: Enthalten lokale sekundäre Indizes Verweise auf alle Elemente der Tabelle?

Nein, nicht unbedingt. Lokale sekundäre Indizes verweisen nur auf die Elemente, die den für den jeweiligen lokalen sekundären Index angegebenen indizierten Bereichsschlüssel enthalten. Beim flexiblen Schema von DynamoDB bedeutet dies, dass nicht alle Elemente notwendigerweise alle Attribute enthalten.

Das heißt, dass der lokale sekundäre Index im Vergleich zum primären Index eine wesentlich geringe Dichte haben kann. Da lokale sekundäre Indizes eine geringe Dichte haben, können Sie Abfragen von Attributen, die nicht gängig sind, effizient unterstützen.

Beim zuvor beschriebenen Auftragsbeispiel kann ein Kunde bei einem Element über einige Zusatzattribute verfügen, die nur hinzugefügt werden, wenn der Auftrag storniert wird (z. B. Datum/Uhrzeit der Stornierung, Stornierungsgrund). Bei Abfragen im Zusammenhang mit stornierten Artikeln ist ein lokaler sekundärer Index für eines dieser Attribute effizient, da die einzigen Artikel, die im Index referenziert werden, diejenigen sind, bei denen diese Attribute vorhanden sind.

F: Wie frage ich lokale sekundäre Indizes ab?

Lokale sekundäre Indizes können nur über die Query API abgefragt werden.

Zum Abfragen eines lokalen sekundären Indexes müssen Sie den Index zusätzlich zum Namen der Tabelle, die Sie abfragen möchten, explizit referenzieren. Sie müssen Name und Wert des Index-Hash-Attributs angeben. Sie können optional eine Bedingung für das Attribut des Indexschlüsselbereichs angeben.

Ihre Abfrage kann nicht projizierte Attribute abrufen, die im primären Index gespeichert sind, indem Sie einen Tabellenabrufvorgang ausführen, wobei Kosten für zusätzliche Lesekapazitätseinheiten anfallen.

Für Abfragen mithilfe des lokalen sekundären Indexes werden Lesevorgänge vom Typ "Strongly consistent" und "Eventually consistent" unterstützt.

F: Wie erstelle ich lokale sekundäre Indizes?

Lokale sekundäre Indizes müssen bei der Erstellung einer Tabelle definiert werden. Der primäre Index der Tabelle müssen einen zusammengesetzten Hash-/Bereichsschlüssel verwenden.

F: Wie kann ich einer vorhandenen Tabelle lokale sekundäre Indizes hinzufügen?

Nein, derzeit können vorhandenen Tabellen keine lokalen sekundären Indizes hinzugefügt werden. Wir arbeiten an der Entwicklung dieser Fähigkeit und werden sie in naher Zukunft zur Verfügung stellen. Wenn Sie eine Tabelle mit einem lokalen sekundären Index erstellen, können Sie nach Wunsch einen lokalen sekundären Index für die künftige Nutzung erstellen, indem Sie ein Bereichsschlüsselelement definieren, das derzeit nicht verwendet wird. Da lokale sekundäre Indizes eine geringe Dichte haben, fallen Kosten für den Index erst an, sobald Sie ihn verwenden.

F: Wie viele lokale sekundäre Indizes kann ich für eine Tabelle erstellen?

Jede Tabelle kann bis zu fünf lokale sekundäre Indizes haben.

F: Wie viele projizierte Nicht-Schlüsselattribute kann ich für eine Tabelle erstellen?

Jede Tabelle kann in sämtlichen lokalen sekundären Indizes der Tabelle bis zu 20 projizierte Nicht-Schlüsselattribute aufweisen. Bei jedem Index kann auch vorgegeben sein, dass alle Nicht-Schlüsselattribute im primären Index projiziert sind.

F: Kann ich den Index nach seiner Erstellung ändern?

Nein, nach seiner Erstellung kann ein Index nicht geändert werden. Wir arbeiten jedoch daran, dies künftig zu ermöglichen.

F: Kann ich lokale sekundäre Indizes löschen?

Nein, lokale sekundäre Indizes können nach ihrer Erstellung nicht aus einer Tabelle entfernt werden. Sie werden freilich gelöscht, sobald Sie die gesamte Tabelle löschen. Wir arbeiten an der Entwicklung dieser Fähigkeit und werden sie in naher Zukunft zur Verfügung stellen.

F: Wie belegen lokale sekundäre Indizes bereitgestellte Kapazität?

Für lokale sekundäre Indizes muss nicht explizit Kapazität bereitgestellt werden. Sie belegen Kapazität als Teil der Tabelle, der sie zugeordnet sind.

Lese- und Schreibvorgänge im lokalen sekundären Index nutzen Kapazität gemäß der Standardformel "1 Einheit pro 1 KB pro Sekunde gelesener oder geschriebener Daten". Dabei gelten die folgenden Unterschiede:

Wenn Schreibvorgänge Daten enthalten, die für einen oder mehrere lokale sekundäre Indizes relevant sind, werden diese Schreibvorgänge in die entsprechenden lokalen sekundären Indizes gespiegelt. In diesem Fällen wird Schreibkapazität für die Tabelle selbst und zusätzliche Schreibkapazität für jeden relevanten lokalen sekundären Index genutzt.

Aktualisierungen, die ein vorhandenes Element überschreiben, können in zwei Vorgängen (Löschen und Einfügen) resultieren und nutzen daher zusätzliche Schreibkapazitätseinheiten pro 1 KB Daten.

Wenn eine Leseabfrage Attribute anfordert, die nicht in den lokalen sekundären Index projiziert wurden, ruft DynamoDB diese Attribute aus dem primären Index ab. Diese implizite "GetItem"-Anforderung nutzt eine Lesekapazitätseinheit pro 1 KB abgerufener Elementdaten.

F: Wie viel Speicher belegen lokale sekundäre Indizes?

Lokale sekundäre Indizes belegen Speicher für den Attributnamen und -wert aller Primär- und Indexschlüssel des lokalen sekundären Indexes für alle projizierten Nicht-Schlüsselattribute plus 100 Bytes pro im LSI gespiegelten Element.

F: Welche Datentypen können indiziert werden?

Alle skalaren Datentypen (Number, String, Binary) können als Bereichsschlüsselelement des lokalen sekundären Indexschlüssel verwendet werden. "Set"-Typen können nicht verwendet werden.

F: Welche Datentypen können in einen lokalen sekundären Index projiziert werden?

Alle Datentypen (einschließlich "Set"-Typen") können in einen lokalen sekundären Index projiziert werden.

F: Was sind Elementauflistungen und in welchem Verhältnis stehen sie zu lokalen sekundären Indizes?

In Amazon DynamoDB ist eine Elementauflistung eine beliebige Gruppe von Elementen mit demselben Hash-Schlüssel in einer Tabelle und allen ihren lokalen sekundären Indizes. Herkömmliche partitionierte relationale Datenbanksysteme rufen diese Partitionen auf und verweisen auf alle Datenbankelemente bzw. -zeilen, die unter einem Hash-Schlüssel gespeichert sind.

Elementauflistungen werden automatisch für jede Tabelle erstellt und verwaltet, die lokale sekundäre Indizes enthalten. DynamoDB speichert jede Elementauflistung in einer einzelnen Festplattenpartition.

F: Gibt es Grenzen für die Größe einer Elementauflistung?

Für jede Elementauflistung in Amazon DynamoDB gilt eine maximale Größe von 10 GB. Bei allen eindeutigen Hash-Schlüsselwerten darf die Summe der Elementgrößen in der Tabelle plus die Summe der Elementgrößen in allen lokalen sekundären Indizes dieser Tabelle 10 GB nicht überschreiten.

Der 10-GB-Grenzwert für Elementauflistungen gilt nicht für Tabellen ohne lokalen sekundären Index, sondern ausschließlich für Tabellen mit mindestens einem lokalen sekundären Index.

Wenngleich die Größe einzelner Elementauflistungen begrenzt ist, gilt für die Speichergröße der gesamten Tabelle mit lokalen sekundären Indizes kein Grenzwert. Die Gesamtgröße einer indizierten Tabelle in Amazon DynamoDB ist praktisch unbegrenzt, solange die gesamte Speichergröße (Tabelle und Indizes) eines der Hash-Schlüssel den Schwellenwert von 10 GB nicht überschreitet.

F: Wie kann ich die Größe einer Elementauflistung nachverfolgen?

Zu den Schreib-APIs (PutItem, UpdateItem, DeleteItem und BatchWriteItem) von DynamoDB zählt eine Option, die der API-Antwort ermöglicht, eine Schätzung der Größe der relevanten Elementauflistung hinzuzufügen. Diese Schätzung umfasst eine untere und obere Größenschätzung der Daten in einer bestimmten Elementauflistung, die in Gigabytes gemessen wird.

Es wird empfohlen, Ihre Anwendung so einzurichten, dass die Größe Ihrer Elementauflistungen überwacht wird. Ihre Anwendungen sollten die API-Antworten hinsichtlich der Elementauflistungsgröße untersuchen und eine Fehlermeldung protokollieren, wenn eine Elementauflistung einen benutzerdefinierten Grenzwert (z. B. 8 GB) überschreitet. Dadurch verfügen Sie über ein Frühwarnsystem, das Sie benachrichtigt, wenn eine Elementauflistung eine kritische Größe erreicht, sodass Sie genügend Zeit für eine Reaktion haben.

F: Was geschieht, wenn ich den 10-GB-Grenzwert einer Elementauflistung überschreite?

Wenn eine bestimmte Elementauflistung den 10-GB-Grenzwert überschreitet, können Sie für den jeweiligen Hash-Schlüssel keine neuen Elemente mehr schreiben und vorhandene Elemente nicht vergrößern. Lese- und Schreibvorgänge, die die Elementauflistung verkleinern, sind weiter zulässig. Andere Elementauflistungen in der Tabelle sind nicht betroffen.

Zum Beheben dieses Problems können Sie aus der Auflistung mit mehr als 10  GB entweder Elemente entfernen oder Elementgrößen verkleinern. Alternativ können Sie neue Elemente unter einem neuen Hash-Schlüsselwert hinzufügen, um dieses Problem zu umgehen. Wenn Ihre Tabelle ältere Daten enthält, auf die nur selten zugegriffen wird, können Sie diese Daten in Amazon S3, Amazon Glacier oder einem anderen Datenspeicher archivieren.


F: Was ist die differenzierte Zugriffskontrolle von DynamoDB?

Die differenzierte Zugriffskontrolle (Fine Grained Access Control, FGAC) bietet dem Besitzer einer DynamoDB-Tabelle einen hohen Grad an Kontrolle über die Daten in der Tabelle. Insbesondere kann der Tabellenbesitzer angeben, welcher Aufrufer auf welche Elemente oder Attribute der Tabelle zugreifen darf und welche Aktionen (Lese-/Schreibvorgänge) zulässig sind. Die differenzierte Zugriffskontrolle wird zusammen mit AWS Identity and Access Management (IAM) genutzt, einem Service, der zur Verwaltung der Anmeldeinformationen und dazugehörigen Berechtigungen dient.

F: Was sind gängige Anwendungsfälle für die differenzierte Zugriffskontrolle von DynamoDB?

Von der differenzierten Zugriffskontrolle profitieren Anwendungen, die Informationen in einer DynamoDB-Tabelle nachverfolgen, bei der Endbenutzer (oder Anwendungs-Client im Auftrag von Endbenutzern) die Tabelle ohne einen Middle-Tier-Service direkt lesen oder ändern möchte. Beispielsweise kann ein Entwickler einer mobilen App mit dem Namen Acme die differenzierte Zugriffskontrolle nutzen, um die Höchstpunktzahl aller Benutzer von Acme in einer DynamoDB-Tabelle nachzuverfolgen. Die differenzierte Zugriffskontrolle ermöglicht dem Anwendungs-Client die Höchstpunktzahl nur des Benutzers zu ändern, der die Anwendung derzeit ausführt.

F: Kann ich Fine Grain Access Control für JSON-Dokumente verwenden?

Ja. Sie können Fine Grain Access Control (FGAC) verwenden, um den Zugriff auf Ihre Daten auf der Basis der Attribute der obersten Stufe in Ihrem Dokument einzuschränken. Sie können FGAC nicht verwenden, um den Zugriff auf der Basis verschachtelter Attribute einzuschränken. Beispiel: Sie haben ein JSON-Dokument gespeichert, das die folgenden Informationen über eine Person enthält: ID, Vorname, Nachname sowie eine Liste ihrer Freunde. Sie könnten FGAC verwenden, um den Zugriff auf der Basis ihrer ID, des Vornamen oder des Nachnamens einzuschränken, nicht aber auf der Basis der Liste ihrer Freunde.

F: Wie können Entwickler ohne differenzierte Zugriffskontrolle eine Zugriffskontrolle auf Elementebene erreichen?

Um diesen Grad von Kontrolle ohne differenzierte Zugriffskontrolle zu erreichen, müssen Entwickler einen von mehreren möglicherweise aufwendigen Ansätzen wählen. Dazu zählen u. a.:

  1. Proxy: Die Anwendung sendet eine Anforderung an einen vermittelnden Proxy, der die Authentifizierung und Autorisierung übernimmt. Eine solche Lösung erhöht die Komplexität der Systemarchitektur und kann zu höheren Gesamtbetriebskosten (TCO) führen.
  2. Eigene Tabelle für jeden Client: Jedem Anwendungs-Client wird eine eigene Tabelle zugewiesen. Da Anwendungs-Clients auf verschiedene Tabellen zugreifen, wären sie voreinander geschützt. Dies könnte allerdings erforderlich machen, dass ein Entwickler Millionen von Tabellen erstellen muss, was die Datenbankverwaltung nicht gerade vereinfacht.
  3. In Client eingebettetes Token: Ein geheimes Token wird in den Anwendungs-Client eingebettet. Der Nachteil hierbei ist die Schwierigkeit, das Token zu ändern und diese Auswirkung auf die gespeicherten Daten in den Griff zu bekommen. Hierbei enthält der Schlüssel der Elemente, auf die dieser Client zugreifen darf, das geheime Token.

F: Wie funktioniert die differenzierte Zugriffskontrolle von DynamoDB?

Bei der differenzierten Zugriffskontrolle fordert eine Anwendung ein geheimes Token an, das der Anwendung erlaubt, nur auf bestimmte Elemente in einer bestimmten DynamoDB-Tabelle zuzugreifen. Mithilfe dieses Tokens können Endbenutzeranwendungs-Agenten Anforderungen direkt an DynamoDB richten. Nach Eingang der Anforderung werden die enthaltenen Anmeldeinformationen zunächst von DynamoDB mithilfe von IAM ausgewertet, um die Anforderung zu authentifizieren und die Möglichkeiten zu bestimmen, über die der Benutzer verfügt. Wenn die Anforderung des Benutzers nicht zugelassen wird, verhindert die differenzierte Zugriffskontrolle den Zugriff auf die Daten.

F: Wie viel kostet die differenzierte Zugriffskontrolle von DynamoDB?

Für die Nutzung der differenzierten Zugriffskontrolle fallen keine zusätzlichen Gebühren an. Sie zahlen wie gewohnt nur für den bereitgestellten Durchsatz und den zur DynamoDB-Tabelle gehörenden Speicher.

F: Was sind die ersten Schritte?

Im DynamoDB Developer Guide erfahren Sie im Abschnitt Fine-Grained Access Control, wie Sie eine Zugriffsrichtlinie erstellen, eine IAM-Rolle für Ihre App einrichten (z. B. mit dem Name "Facebook-Benutzer von Acme" für die Facebook-App-ID 34567) und die Zugriffsrichtlinie der Rolle zuweisen. Die Vertrauensrichtlinie der Rolle bestimmt, welche Identitätsanbieter akzeptiert werden (z. B. Login with Amazon, Facebook oder Google). Die Zugriffsrichtlinie gibt an, auf welche AWS-Ressourcen zugegriffen werden darf (z. B. eine DynamoDB-Tabelle). Mithilfe der Rolle kann Ihre App nun temporäre Anmeldeinformationen für DynamoDB abrufen, indem die "AssumeRoleWithIdentityRequest"-API des AWS Security Token Service (STS) aufgerufen wird.

F: Wie erlaube ich Benutzern das Abfragen eines lokalen sekundären Indexes und wie hindere ich sie an einem Tabellenabruf zum Bestimmen nicht projizierter Attribute?

Einige Abfrageoperationen eines lokalen sekundären Indexes sind ggf. aufwendiger als andere, wenn Attribute angefordert werden, die nicht in einen Index projiziert sind. Sie können möglicherweise aufwendige Abrufoperationen einschränken, indem Sie die Berechtigung mit dem Kontextschlüssel "dynamodb:Attributes" auf ausschließlich projizierte Attribute beschränken.

F: Wie hindere ich Benutzer am Zugriff auf bestimmte Attribute?

Die empfohlene Vorgehensweise zum Verhindern des Zugriffs auf bestimmte Attribute ist das Befolgen der Regel der geringsten Rechte und Zulassen des Zugriffs nur auf bestimmte Attribute.

Alternativ können Sie eine Richtlinie vom Typ Verweigern zum Angeben von Attributen nutzen, auf die nicht zugegriffen werden darf. Dies wird jedoch aus folgenden Gründen nicht empfohlen:

  1. Bei einer Verweigern-Richtlinie kann der Benutzer die ausgeblendeten Attribute ermitteln, indem wiederholte Anforderungen für jeden möglichen Attributnamen gestellt werden, bis dem Benutzer letztlich der Zugriff verweigert wird.
  2. Verweigern-Richtlinien sind dahingehend problematisch, da in DynamoDB künftig neue API-Funktionalität eingeführt werden könnte, die ein Zugriffsmuster zulässt, das Sie bislang blockieren wollten.

F: Wie verhindere ich, dass Benutzer einer Tabelle ungültige Daten hinzufügen?

Die verfügbaren Steuerelemente für die differenzierte Zugriffskontrolle können bestimmen, welche Elemente sich geändert haben oder gelesen wurden bzw. welche Attribute geändert und gelesen werden können. Benutzer können neue Elemente ohne diese blockierten Attribute hinzufügen und Werte änderbarerer Attribute ändern.

F: Kann ich Zugriff auf mehrere Attribute gewähren, ohne alle auflisten zu müssen?

Die IAM-Richtliniensprache unterstützt viele verschiedene Vergleichsoperatoren wie u. a. "StringLike" und "StringNotLike". Der folgende Richtlinienauszug gleicht beispielsweise alle mit "public_" beginnenden Attribute ab.

F: Wie erstelle ich eine geeignete Richtlinie?

Wir empfehlen die Nutzung von DynamoDB Policy Generator in der DynamoDB-Konsole. Sie können Ihre Richtlinie auch mit den im Amazon DynamoDB Developer Guide aufgeführten Richtlinien vergleichen, um sicherzustellen, dass Sie ein empfohlenes Muster befolgen. Sie können Richtlinien auch in den AWS-Foren vorstellen, um Rückmeldungen von der DynamoDB-Community zu erhalten.

F: Kann ich Zugriff basierend auf einer autorisierten Benutzer-ID gewähren anstatt auf getrennten IDs für den Benutzer basierend auf dem Identitätsanbieter, mit dem er angemeldet ist?

Das geht nur mit einer "Token-Ausgabemaschine". Wenn ein Benutzer einen Verbundzugriff auf Ihre IAM-Rolle direkt mithilfe von Facebook-Anmeldeinformationen über STS abruft, gelten diese Anmeldeinformationen nur für die Facebook-Anmeldung des Benutzers und nicht für seine Amazon- oder Google-Anmeldung. Wenn Sie intern eine Zuordnung jeder dieser Anmeldungen zu Ihrer eigenen beständigen ID speichern möchten, können Sie einen Service ausführen, den der Benutzer zur Anmeldung kontaktiert. Anschließend können Sie STS aufrufen und dem Benutzer Anmeldeinformationen bereitstellen, die an den Hash-Schlüsselwert angepasst sind, den der Benutzer in seiner autorisierten Benutzer-ID vorgelegt hat.

F: Welche Informationen können Aufrufern bei Verwenden der differenzierten Zugriffskontrolle nicht vorenthalten werden?

Bestimmte Informationen zu den Elementen in der Tabelle können derzeit für den Aufrufer nicht blockiert werden:

  • Sammlungsmetriken zu Elementen. Der Aufrufer kann die geschätzte Anzahl von Elementen und die Größe in Byte der Elementsammlung abfragen.
  • Genutzter Durchsatz. Der Aufrufer kann die detaillierte Aufschlüsselung oder Zusammenfassung des bereitgestellten Durchsatzes abfragen, der für Operationen genutzt wurde.
  • Überprüfungsmöglichkeiten. Unter bestimmten Umständen kann der Aufrufer das Vorhandensein einer Tabelle und ihr Primärschlüsselschema ermitteln, auch wenn Sie nicht vorhatten, ihm Zugriff zu gewähren. Um dies zu verhindern, befolgen Sie die Regel der geringsten Rechte und lassen den Zugriff nur auf die gewünschten Tabellen und Aktionen zu.
  • Wenn Sie den Zugriff auf bestimmte Attribute verweigern, anstatt eine Positivliste für bestimmte Attribute zu erstellen, kann der Aufrufer bei einer Logik vom Typ "Zugriff auf alle zulassen, außer" theoretisch die Namen der ausgeblendeten Attribute ermitteln. Es ist sicherer, für bestimmte Attributnamen eine Positivliste anzulegen.

F: Werden IAM-Berechtigungen von Amazon DynamoDB unterstützt?

Ja. DynamoDB unterstützt Berechtigungen auf API-Ebene durch die Integration des Services AWS Identity and Access Management (IAM)

Weitere Informationen zu IAM erhalten Sie unter:


F: Wie wird mir die Nutzung von Amazon DynamoDB in Rechnung gestellt?

Jede DynamoDB-Tabelle verfügt über einen dazugehörigen bereitgestellten Lese- und Schreibdurchsatz. Diese Durchsatzkapazität wird Ihnen nach Stunden berechnet, sobald Sie das kostenlose Nutzungskontingent überschreiten.

Beachten Sie, dass die Durchsatzkapazität, die Sie für Ihre Tabelle bereitstellen, nach Stunden berechnet wird. Dabei ist unerheblich, ob Sie Anforderungen an Ihre Tabelle senden oder nicht. Wenn Sie den bereitgestellten Durchsatz für Ihre Tabelle ändern möchten, können Sie das über die AWS Management Console oder die UpdateTable-API vornehmen.

Außerdem berechnet Ihnen DynamoDB indizierten Datenspeicher und die standardmäßigen Transfergebühren für Internet-Daten.

Die Preise für DynamoDB finden Sie auf der Seite mit der Preisübersicht für DynamoDB.

F: Können Sie einige Preisbeispiele nennen?

Hier finden Sie ein Beispiel dafür, wie Sie Ihre Durchsatzkosten unter Verwendung der Preise für die Region USA Ost (Nord-Virginia) berechnen. Die Preise für andere Regionen finden Sie auf der Seite mit unserer Preisübersicht.

Wenn Sie eine Tabelle erstellen und 10 Schreibkapazitätseinheiten sowie 200 Lesekapazitätseinheiten für den bereitgestellten Durchsatz anfordern, wird Ihnen das wie folgt in Rechnung gestellt:

0,01 USD + (4 x 0,01 USD) = 0,05 USD pro Stunde

Sobald sich Ihre Durchsatzanforderungen ändern und Sie Ihren bereitgestellten Durchsatz auf 10.000 Schreib- und 50.000 Lesekapazitätseinheiten erhöhen, ändert sich die Berechnung wie folgt:

(1.000 x 0,01 USD) + (1.000 x 0,01 USD) = 20 USD/Stunde

Die Preise für DynamoDB finden Sie auf der Seite mit der Preisübersicht für DynamoDB.

F: Sind Steuern bereits in den Preisen enthalten?

Falls nicht anders angegeben, gelten unsere Preise zuzüglich geltender Steuern und Abgaben, darunter MwSt. und Umsatzsteuer. Bei Kunden mit japanischer Rechungsadresse unterliegt die Nutzung der Region Asien-Pazifik (Tokio) der japanischen Verbrauchssteuer. Weitere Informationen.

F: Was ist bereitgestellter Durchsatz?

Bei Amazon DynamoDB können Sie den Anforderungsdurchsatz festlegen, den Ihre Tabelle erreichen soll. Der Service stellt im Hintergrund die Ressourcen bereit, mit denen die erforderliche Durchsatzrate erreicht wird. Bei uns müssen Sie sich also keine Gedanken über Instanzen, Hardware, Arbeitsspeicher und andere Faktoren machen, die Auswirkungen auf Ihre Durchsatzrate haben – Sie müssen uns lediglich mitteilen, welchen Durchsatz Sie erzielen möchten. Das ist das bereitgestellte Durchsatzmodell des Service.

Bei Amazon DynamoDB können Sie Ihre Durchsatzanforderungen in Bezug auf die Lesekapazität und Schreibkapazität in Ihrer Tabelle festlegen. Beim Erstellen einer Tabelle geben Sie Ihre erforderlichen Lese- und Schreibkapazitätsanforderungen an. Daraufhin partitioniert Amazon DynamoDB automatisch die entsprechende Anzahl von Ressourcen und reserviert diese, damit Sie Ihren Durchsatz erreichen. Überlegen Sie sich bei der Entscheidung für die entsprechenden Lese- und Schreibdurchsatzwerte die Anzahl der Lese- und Schreib-API-Aufrufe auf Datenebene, die pro Sekunde erfolgen sollen. Falls Sie zu einem bestimmten Zeitpunkt erwarten, dass der Datenverkehr so anwachsen wird, dass Ihr bereitgestellter Durchsatz überschritten wird, können Sie Ihre bereitgestellten Durchsatzwerte ganz einfach über die AWS Management Console oder die Amazon DynamoDB-APIs aktualisieren. Sie können die bereitgestellten Durchsatzwerte für eine Tabelle auch verringern, wenn die Nachfrage abnimmt. Amazon DynamoDB bleibt verfügbar, während die Durchsatzrate vergrößert oder verkleinert wird.

F: Inwiefern hat die Auswahl des Primärschlüssels Auswirkungen auf die mögliche Skalierbarkeit?

Beim Speichern von Daten teilt Amazon DynamoDB eine Tabelle in mehrere Partitionen auf und verteilt die Daten je nach dem Hash-Schlüsselelement des Primärschlüssels. Bei der Zuweisung von Kapazitätsressourcen verwendet Amazon DynamoDB ein relativ zufälliges Zugriffsmuster für alle Primärschlüssel. Sie sollten Ihr Datenmodell so einrichten, dass Ihre Anforderungen zu einer möglichst gleichmäßigen Verteilung des Datenverkehrs auf die Primärschlüssel führen. Wenn eine Tabelle über eine sehr kleine Anzahl von Hash-Schlüsselelementen verfügt (vielleicht sogar über ein einziges, sehr häufig verwendetes Hash-Schlüsselelement), wird der Verkehr auf eine kleine Anzahl von Partitionen konzentriert – möglicherweise auf nur eine Partition. Wenn die Arbeitslast unausgeglichen ist, also sich unverhältnismäßig auf einen oder einige wenige Partitionen konzentriert, werden bei den Operationen nicht die insgesamt bereitgestellten Durchsatzraten erreicht. Den besten Durchsatz erzielen Sie mit Amazon DynamoDB, indem Sie Tabellen erstellen, bei denen das Hash-Schlüsselelement über eine große Anzahl bestimmter Werte verfügt und die Werte ziemlich einheitlich und so zufällig, wie möglich, abgefragt werden. Ein Beispiel für einen guten Primärschlüssel ist "CustomerID", wenn die Anwendung viele Kunden hat und Anforderungen an verschiedene Kundendatensätze mehr oder weniger gleichförmig sind. Ein Beispiel für einen weniger guten Primärschlüssel ist "Produktkategoriename", wobei bestimmte Produktkategorien beliebter als andere sind.

F: Was ist eine Lese-/Schreibkapazitätseinheit?

Wie finde ich heraus, wie viele Lese- und Schreibkapazitätseinheiten ich für meine Anwendung benötige? Mit einer Schreibkapazitätseinheit können Sie einen Schreibvorgang pro Sekunde für Elemente von bis zu 1 KB Größe ausführen. Mit einer Lesekapazitätseinheit können Sie einen "Strongly Consistent"-Lesevorgang pro Sekunde (oder zwei "Eventually Consistent"-Lesevorgänge pro Sekunde) für Elemente von bis zu 4 KB Größe ausführen. Für größere Elemente ist eine höhere Kapazität erforderlich. Sie können die Anzahl der für Sie erforderlichen Kapazitätseinheiten für Lese- und Schreibvorgänge berechnen, indem Sie die Anzahl der erwarteten erforderlichen Lese- oder Schreibvorgänge pro Sekunde mit der Größe der einzelnen Elemente in KB multiplizieren (aufgerundet auf die nächste ganze Zahl).

Für Schreibvorgänge erforderliche Kapazitätseinheiten = Anzahl der Elementschreibvorgänge pro Sekunde x Elementgröße in KB (aufgerundet auf die nächste ganze Zahl)

Für Lesevorgänge erforderliche Kapazitätseinheiten* = Anzahl der Elementlesevorgänge pro Sekunde x Elementgröße in KB (aufgerundet auf die nächste ganze Zahl)

* Wenn Sie "Eventually Consistent"-Lesevorgänge verwenden, erhalten Sie in Bezug auf die Lesevorgänge pro Sekunde den doppelten Durchsatz.

Wenn die einzelnen Elemente weniger als 1 KB groß sind, können Sie mit jeder Lesekapazitätseinheit einen Lesevorgang pro Sekunde und mit jeder Schreibkapazitätseinheit einen Schreibvorgang pro Sekunde ausführen. Beispiel: Wenn Ihre Elemente eine Größe von 512 Byte haben und Sie 100 Elemente pro Sekunde aus Ihrer Tabelle lesen möchten, müssen Sie 100 Lesekapazitätseinheiten bereitstellen.

Sind Ihre Elemente größer als 1 KB, müssen sie die erforderliche Anzahl der Lese- und Schreibkapazitätseinheiten berechnen. Beispiel: Wenn Ihre Elemente eine Größe von 1,5 KB haben und Sie 100 Lesevorgänge pro Sekunde vornehmen möchten, müssen Sie 100 (Lesevorgänge pro Sekunde) x 2 (1,5 KB aufgerundet auf die nächste ganze Zahl) = 200 Lesekapazitätseinheiten bereitstellen.

Beachten Sie, dass die erforderliche Anzahl von Lesekapazitätseinheiten durch die Anzahl der gelesenen Elemente pro Sekunde bestimmt wird und nicht durch die Anzahl der API-Aufrufe. Wenn Sie beispielsweise 500 Elemente pro Sekunde in Ihrer Tabelle lesen müssen und Ihre Elemente kleiner oder gleich 1 KB sind, benötigen Sie 500 Lesekapazitätseinheiten. Dabei ist unerheblich, ob Sie 500 einzelne GetItem-Aufrufe oder 50 BatchGetItem-Aufrufe ausführen, die jeweils 10 Elemente zurückgeben.

F: Kann ich meinen bereitgestellten Durchsatz immer erreichen?

Amazon DynamoDB verwendet ein relativ zufälliges Zugriffsmuster für alle Primärschlüssel. Sie sollten Ihr Datenmodell so einrichten, dass Ihre Anforderungen zu einer möglichst gleichmäßigen Verteilung des Datenverkehrs auf die Primärschlüssel führen. Wenn Sie ein sehr ungleichmäßiges oder verzerrtes Zugriffsmuster haben, können Sie eventuell Ihren bereitgestellten Durchsatz nicht erreichen.

Beim Speichern von Daten teilt Amazon DynamoDB eine Tabelle in mehrere Partitionen auf und verteilt die Daten je nach dem Hash-Schlüsselelement des Primärschlüssels. Der zu einer Tabelle gehörige bereitgestellte Durchsatz wird auf die Partitionen aufgeteilt. Der Durchsatz jeder Partition wird unabhängig auf Grundlage des zugewiesenen Kontingents verwaltet. Eine gemeinsame Nutzung des bereitgestellten Durchsatzes über die Partitionen hinweg findet nicht statt. Daher eignet sich eine Tabelle in Amazon DynamoDB am besten, um die bereitgestellten Durchsatzraten zu erreichen, falls die Arbeitslast ziemlich gleichmäßig auf die Hash-Schlüsselwerte verteilt ist. Durch die Verteilung von Anforderungen auf Hash-Schlüsselwerte werden die Anforderungen auf die Partitionen verteilt. So können Sie Ihren gesamten bereitgestellten Durchsatz erreichen.

Wenn Sie über die Primärschlüssel verteilt ein ungleichmäßiges Arbeitslastmuster haben, können Sie Ihre bereitgestellte Durchsatzrate eventuell nicht erreichen. Stellen Sie Ihre Durchsatzanforderungen durch eine weitere Erhöhung Ihres bereitgestellten Durchsatzes zufrieden. Dadurch erhalten Sie für jede Partition mehr Durchsatz. Es wird jedoch empfohlen, dass Sie Ihr Anfragemuster oder Ihr Datenmodell ändern, damit Sie ein Zugriffsmuster erzielen, das relativ zufällig über die Primärschlüssel verteilt ist.

F: Wenn ich nur ein einzelnes Element eines JSON-Dokuments abrufe, wird mir dann das Lesen des kompletten Elements in Rechnung gestellt?

Ja. Wenn Sie Daten aus DynamoDB lesen, nutzen Sie den erforderlichen Durchsatz zum Lesen des kompletten Elements.

F: Wie lautet der Höchstdurchsatz, den ich für eine einzelne DynamoDB-Tabelle zur Verfügung stellen kann?

DynamoDB wurde speziell für eine unbegrenzte Skalierung konzipiert. Wenn Sie jedoch Durchsatzraten von 10 000 Schreib- und Lesekapazitätseinheiten für eine einzelne Tabelle überschreiten möchten, müssen Sie sich zunächst mithilfe dieses Online-Formulars an Amazon wenden. Wenn Sie mehr als 20 000 Schreib- oder Lesekapazitätseinheiten über ein einzelnes Abonnentenkonto bereitstellen möchten, wenden Sie sich bitte zunächst über das zuvor beschriebene Formular an uns.

F: Wie lautet der Mindestdurchsatz, den ich für eine einzelne DynamoDB-Tabelle zur Verfügung stellen kann?

Der geringste bereitgestellte Durchsatz, den Sie anfordern können, beträgt 1 Schreib- und 1 Lesekapazitätseinheit.

Dieser fällt unter das kostenlose Kontingent, welches 25 Schreib- und 25 Lesekapazitätseinheiten bereitstellt. Das kostenlose Kontingent gilt für das Konto und nicht für die Tabelle. Mit anderen Worten: Wenn Sie die bereitgestellten Kapazitäten für alle Ihre Tabellen zusammenzählen und die Gesamtkapazität nicht mehr als 25 Schreib– und 25 Lesekapazitätseinheiten beträgt, fällt Ihre bereitgestellte Kapazität unter das kostenlose Kontingent.

F: Gibt es Einschränkungen beim Ändern meines bereitgestellten Durchsatzes durch eine einzelne Anforderung?

Sie können die bereitgestellte Durchsatzkapazität Ihrer Tabelle in beliebigem Umfang erhöhen, indem Sie die UpdateTable-API verwenden. Beispiel: Sie könnten die bereitgestellte Schreibkapazität Ihrer Tabelle mit einem einzigen API-Aufruf von 1 Schreibkapazitätseinheit auf 10.000 Schreibkapazitätseinheiten erhöhen. Ihr Konto unterliegt immer noch den Kapazitätsgrenzen auf Tabellen- und Kontoebene, wie auf unserer Dokumentationsseite beschrieben. Wenn Sie Ihre bereitgestellten Kapazitätsgrenzen erhöhen müssen, können Sie unser Support-Center besuchen, auf "Neuen Fall öffnen" klicken und eine Erhöhung der Kapazitätsgrenzen beantragen.

F: Wie wird mir der bereitgestellte Durchsatz in Rechnung gestellt?

Für jede Amazon DynamoDB-Tabelle werden die Ressourcen bereitgestellt, die für die von Ihnen beantragte Durchsatzrate erforderlich sind. So lange Ihre Tabelle diese Ressourcen nutzt, werden Ihnen die Stunden in Rechnung gestellt. Eine komplette Preisliste mit Beispielen finden Sie auf der Seite mit der Preisübersicht für DynamoDB.

F: Wie kann ich den bereitgestellten Durchsatz für eine vorhandene DynamoDB-Tabelle ändern?

Es gibt zwei Möglichkeiten zum Aktualisieren des bereitgestellten Durchsatzes einer Amazon DynamoDB-Tabelle. Sie können die Änderung in der AWS Management Console vornehmen oder Sie verwenden den UpdateTable API-Aufruf. Sie können Ihren Durchsatz mit einem einzelnen API-Aufruf um bis 100 % ändern, wie zuvor beschrieben: "Gelten Einschränkungen für das Ändern meines bereitgestellten Durchsatzes durch einen einzelnen API-Aufruf?"

Amazon DynamoDB ist weiterhin verfügbar während Ihre bereitgestellter Durchsatzrate erhöht oder verringert wird.

F: Wie oft kann ich meinen bereitgestellten Durchsatz ändern?

Sie können Ihren bereitgestellten Durchsatz so oft erhöhen, wie Sie möchten. Sie können ihn viermal pro Tag verringern. Ein Tag basiert auf der GMT-Zeitzone (MEZ-1). Wenn Sie beispielsweise den bereitgestellten Durchsatz für Ihre Tabelle am 12. Dezember viermal verringern, können Sie ihn für diese Tabelle erst wieder am 13. Dezember um 0:01 Uhr (GMT) ändern.

Beachten Sie, dass Sie Ihren bereitgestellten Durchsatz nicht ändern können, wenn Ihre Amazon DynamoDB-Tabelle gerade noch auf Ihre letzte Änderungsanforderung in Bezug auf den bereitgestellten Durchsatz reagiert. Verwenden Sie die AWS Management Console oder die DescribeTables-API, um den Status Ihrer Tabelle zu überprüfen. Falls der Status "CREATING", "DELETING" oder "UPDATING" lautet, können Sie den Durchsatz für Ihre Tabelle nicht anpassen. Warten Sie bitte, bis die Tabelle den Status "ACTIVE" hat und versuchen Sie es noch einmal.

F: Hat die Konsistenzebene Auswirkungen auf die Durchsatzrate?

Ja. Bei einer bestimmten Ressourcenzuweisung unterscheidet sich die von einer DynamoDB-Tabelle erreichbare Lesevorgangsrate für die Einstellungen "Strongly Consistent" und "Eventually Consistent". Wenn Sie "1.000 Lesekapazitätseinheiten" anfordern, weist DynamoDB ausreichend Ressourcen zu, um 1.000 "Strongly Consistent"-Lesevorgänge pro Sekunde für Elemente mit bis zu 1 KB zu erzielen. Wenn Sie 1.000 "Eventually Consistent"-Lesevorgänge für Elemente mit bis zu 1 KB erzielen möchten, müssen Sie diese Kapazität halbieren, d. h. auf 500 Lesekapazitätseinheiten. Weitere Hilfestellung zur Auswahl der passenden Durchsatzrate für Ihre Tabelle erhalten Sie in den Hinweisen zum bereitgestellten Durchsatz.

F: Hat die Elementgröße Auswirkungen auf die Durchsatzrate?

Ja. Bei einer bestimmten Ressourcenzuweisung hängt die von einer DynamoDB-Tabelle erreichbare Lesevorgangsrate von der Größe eines Elements ab. Wenn Sie den gewünschten bereitgestellten Durchsatz angeben, nimmt DynamoDB bei der Bereitstellung der Ressourcen an, dass die Elemente kleiner als 1 KB sind. Bei jeder Vergrößerung über 1 KB vergrößert sich linear auch der erforderliche Ressourcenbedarf, damit dieselbe Durchsatzrate erzielt werden kann. Wenn Sie beispielsweise eine DynamoDB-Tabelle mit 100 Schreibkapazitätseinheiten bereitgestellt haben, bedeutet das, dass Sie pro Sekunde 100 x 1 KB schreiben können oder 50 x 2 KB pro Sekunde oder 25 x 4 KB usw. Weitere Hilfestellung zur Auswahl der passenden Durchsatzrate für Ihre Tabelle erhalten Sie in den Hinweisen zum bereitgestellten Durchsatz.

F: Was passiert, wenn meine Anwendung mehr Lese- und Schreibvorgänge ausführt, als meine verfügbare Kapazität erlaubt?

Wenn Ihre Anwendung mehr Lesevorgänge oder Schreibvorgänge pro Sekunde ausführt, als die bereitgestellte Durchsatzkapazität erlaubt, werden die Anforderungen, die Ihre bereitgestellte Kapazität überschreiten, gedrosselt und Sie erhalten den Fehlercode 400. Wenn Sie beispielsweise 1.000 Schreibkapazitätseinheiten beantragt haben und versuchen 1.500 Schreibvorgänge/Sekunde von Elementen mit 1 KB auszuführen, erlaubt DynamoDB nur 1.000 Schreibvorgänge/Sekunde und gibt für alle weiteren Anforderungen den Fehlercode 400 aus. Mit CloudWatch können Sie Ihre Anforderungsrate überwachen und so sicherstellen, dass Sie stets über ausreichend bereitgestellten Durchsatz verfügen, um die erforderliche Anforderungsrate zu erzielen.

F: Wie erkenne ich, wenn ich meine bereitgestellte Durchsatzkapazität überschreite?

DynamoDB veröffentlicht Ihre verbrauchte Durchsatzkapazität als CloudWatch-Kennzahl. Sie können für diese Kennzahl einen Alarm festlegen, sodass Sie benachrichtigt werden, wenn Sie sich ihrer bereitgestellten Kapazität nähern.

F: Wie lange dauert es, bis der bereitgestellte Durchsatz einer Tabelle geändert wird?

Im Allgemeinen dauert eine Verringerung des Durchsatzes von einigen Sekunden bis zu einigen Minuten und eine Erhöhung des Durchsatzes von einigen Minuten bis zu einigen Stunden.

Wir empfehlen Ihnen, eine Erhöhung des Durchsatzes so zu planen, dass dieser zusätzliche Durchsatz nicht sofort verwendet werden muss. Planen Sie die Bereitstellung der Durchsatzkapazität so weit im Voraus, dass diese verfügbar ist, wenn sie benötigt wird.

F: Was ist reservierte Kapazität?

"Reservierte Kapazität" ist eine Fakturierungsfunktion, über die Sie Ermäßigungen auf Ihre bereitgestellte Durchsatzkapazität im Tausch gegen Folgendes erhalten:

  • Eine einmalige Vorauszahlung
  • Eine Verpflichtung zu einer monatlichen Mindestnutzung für die Laufzeit des Vertrags

"Reservierte Kapazität" ist auf eine einzelne AWS-Region begrenzt und kann mit einer Laufzeit von einem oder drei Jahren erworben werden. Jeder DynamoDB-Tabelle ist eine bereitgestellte Durchsatzkapazität zugeordnet. Beim Erstellen oder Aktualisieren einer Tabelle geben Sie an, wie viel Lese- und Schreibkapazität Sie für die Tabelle wünschen. Anhand dieser Kapazität wird die Durchsatzrate für Lese- und Schreibvorgänge in Ihrer DynamoDB-Tabelle bestimmt. "Reservierte Kapazität" ist eine Fakturierungsvereinbarung ohne direkte Auswirkung auf die Leistung oder Kapazität Ihrer DynamoDB-Tabellen. Wenn Sie beispielsweise 5000 Schreibkapazitätseinheiten als reservierte Kapazität erworben haben, verpflichten Sie sich zur Zahlung dieser Kapazität für die Laufzeit des Vertrags (1 oder 3 Jahre) im Tausch gegen ermäßigte Gebühren. F: Wie erwerbe ich reservierte Kapazität? Melden Sie sich an der AWS Management Console an, wechseln Sie zur Seite der DynamoDB-Konsole und klicken Sie auf "Purchase Reserved Capacity". Sie gelangen zu einem Formular, das Sie ausfüllen, um reservierte Kapazität zu beantragen. Vergewissern Sie sich, dass Sie die richtige AWS-Region ausgewählt haben, in der die reservierte Kapazität genutzt wird. Die Bearbeitung Ihres Antrags kann bis zu zwei Wochen in Anspruch nehmen. Sie werden per E-Mail benachrichtigt, sobald Ihr Antrag auf reservierte Kapazität bearbeitet wurde.

F: Kann ich den Erwerb reservierter Kapazität stornieren?

Nein. Sie können Ihre reservierte Kapazität nicht stornieren und die Einmalzahlung wird nicht rückerstattet. Sie zahlen weiter für jede Stunde Ihrer Vertragslaufzeit für die reservierte Kapazität unabhängig von der tatsächlichen Nutzung.

F: Welches ist das kleinste Volumen an reservierter Kapazität, das ich erwerben kann?

Das kleinste Angebot an reservierter Kapazität umfasst 5000 Schreibkapazitätseinheiten und 5000 Lesekapazitätseinheiten.

F: Gibt es APIs, die ich nutzen kann, um reservierte Kapazität zu erwerben?

Noch nicht. In naher Zukunft werden wir APIs und weitere Optionen für reservierte Kapazität anbieten.

F: Wie oft kann ich reservierte Kapazität erwerben?

Derzeit kann ein AWS-Konto reservierte Kapazität einmalig erwerben. Wir werden unser Angebot an reservierter Kapazität in Zukunft erweitern, damit pro Konto mehrmals reservierte Kapazität erworben werden kann.

F: Kann ich reservierte Kapazität aus einer Region in eine andere verschieben?

Nein. Reservierte Kapazität ist einer einzelnen Region zugeordnet.

F: Kann ich mehr Durchsatzkapazität bereitstellen, als meine reservierte Kapazität vorsieht?

Ja. Wenn Sie reservierte Kapazität erwerben, vereinbaren Sie eine Mindestnutzung, für die Sie eine ermäßigte Gebühr zahlen. Wenn Sie über diese Mindestnutzung hinaus Kapazität bereitstellen, wird Ihnen dafür der Regeltarif in Rechnung gestellt.

F: Wie nutze ich meine reservierte Kapazität?

Reservierte Kapazität wird automatisch in Ihrer Rechnung berücksichtigt. Wenn Sie beispielsweise 5000 Schreibkapazitätseinheiten als reservierte Kapazität erwerben und 6000 bereitgestellt haben, deckt Ihre reservierte Kapazität automatisch die Kosten von 5000 Schreibkapazitätseinheiten ab. Für die restlichen 1000 Schreibkapazitätseinheiten wird Ihnen der Regeltarif in Rechnung gestellt.

F: Was passiert, wenn ich weniger Durchsatz bereitstelle, als meine reservierte Kapazität vorsieht?

Der Erwerb reservierter Kapazität ist ein Vertrag über die Zahlung für ein Mindestvolumen an bereitgestellter Durchsatzkapazität für die Laufzeit des Vertrags im Tausch gegen eine ermäßigte Gebühr. Wenn Sie weniger als ihre reservierte Kapazität in Anspruch nehmen, wird Ihnen dennoch monatlich dieses Mindestvolumen an bereitgestellter Durchsatzkapazität in Rechnung gestellt.

F: Kann ich meine reservierte Kapazität für mehrere DynamoDB-Tabellen nutzen?

Ja. Reservierte Kapazität gilt für die insgesamt bereitgestellte Kapazität innerhalb der Region, in der Sie Ihre reservierte Kapazität erworben haben. Angenommen, Sie haben 5000 Schreibkapazitätseinheiten als reservierte Kapazität erworben. Dann können Sie diese für eine Tabelle mit 5000 Schreibkapazitätseinheiten oder 100 Tabellen mit 50 Schreibkapazitätseinheiten oder 1000 Tabellen mit 5 Schreibkapazitätseinheiten usw. in Anspruch nehmen.

F: Was ist DynamoDB Streams?

Wenn Sie DynamoDB Streams für eine DynamoDB-Tabelle aktivieren, erhalten Sie Zugriff auf einen Stream aller Datenänderungen in dieser Tabelle während der letzten 24 Stunden. Sie können mit einem einfachen API-Aufruf auf den Stream zugreifen und ihn verwenden, um andere Datenspeicher bezüglich der Änderungen bei DynamoDB auf dem neuesten Stand zu halten oder aufgrund der Änderungen in Ihrer Tabelle Aktionen durchzuführen.

F: Welche Vorteile bietet die Nutzung von DynamoDB Streams?

Durch Verwendung der Streams-APIs können Entwickler die Aktualisierungen verwenden, die Daten auf Elementebene vor und nach den Änderungen empfangen und kreative Erweiterungen ihrer Anwendungen erstellen, die auf DynamoDB beruhen. Beispielsweise könnte ein Entwickler, der mit DynamoDB ein globales Spiel für mehrere Spieler entwickelt, die Streams-APIs nutzen, um eine Multi-Master-Topologie aufzubauen und die Master zu synchronisieren, indem die Streams für die einzelnen Master verwendet und die Aktualisierungen auf den entfernten Mastern erneut wiedergegeben werden. Ein weiteres Beispiel: Entwickler können die Streams-APIs verwenden, um Mobilanwendungen zu erstellen, die automatisch die Mobilgeräte aller Freunde in einem Umkreis benachrichtigen, sobald ein Benutzer ein Selfie aufnimmt. Entwickler könnten DynamoDB Streams auch verwenden, um Tools für das Data Warehousing wie beispielsweise Amazon Redshift mit allen Änderungen ihrer DynamoDB-Tabelle zu synchronisieren und damit Echtzeit-Analysen zu ermöglichen.

Weitere Informationen   über DynamoDB Streams finden Sie in der DynamoDB-Dokumentation.

F: Kann ich Amazon DynamoDB Streams schon heute verwenden?

DynamoDB Streams ist derzeit als Teil einer Vorversion erhältlich. AWS hat zwei Vorversions-Regionen eingerichtet, in denen Sie DynamoDB Streams ausprobieren können. Diese Regionen sind für Test und Entwicklung gedacht und sollten nicht für Produktionsanwendungen verwendet werden. Um Zugang auf die Vorversion von DynamoDB Streams zu erhalten, füllen Sie bitte die Anforderung der Vorversion aus.

Sie können DynamoDB Streams auch im Rahmen einer Vorversion von DynamoDB Local ausprobieren, indem Sie eine kostenlose clientseitige Version von DynamoDB verwenden, die Sie herunterladen und auf EC2, Ihrem Desktop oder in Ihrer Infrastruktur vor Ort einsetzen können. Weitere Informationen über die Verwendung von DynamoDB Streams finden Sie in unserer Dokumentation.

F: Kann ich die Vorversion von DynamoDB Streams zum Ausführen einer Produktionsanwendung verwenden?

Nein. Die Vorversion gibt Ihnen die Möglichkeit, zukünftige DynamoDB-Funktionen kennenzulernen, bevor sie erhältlich sind. Die Regionen für die Vorversion werden nicht als Produktionsregionen unterstützt und sollten nicht zum Ausführen von Produktionsanwendungen verwendet werden.

F: Wie lange stehen Änderungen meiner DynamoDB-Tabelle über DynamoDB Streams zur Verfügung?

DynamoDB Streams halten alle Änderungen in einer Tabelle 24 Stunden lang fest. Danach werden sie gelöscht.

F: Wie aktiviere ich DynamoDB Streams?

DynamoDB Streams müssen pro Tabelle aktiviert werden. Um Streams für eine bestehende DynamoDB-Tabelle zu aktivieren, wählen Sie die Tabelle über die AWS Management Console, klicken auf die Registerkarte "Stream" und dann auf die Schaltfläche "Stream aktivieren". Bei neuen Tabellen ermöglicht die Console die Aktivierung von DynamoDB Streams, wenn die Tabelle erstellt wird.

Die Option zum Aktivieren dieser Funktion steht nur in der Vorversion von DynamoDB Streams zur Verfügung. Weitere Informationen über die Vorversion finden Sie in unserer Dokumentation.

F: Wie kann ich prüfen, ob DynamoDB Streams aktiviert wurde?

Nach dem Aktivieren von DynamoDB Streams sehen Sie den Stream auf der AWS Management Console. Wählen Sie Ihre Tabelle und klicken Sie dann auf die Registerkarte "Stream". Sie sehen eine Liste mit aktiven DynamoDB Streams und alle Streams, die in den letzten 24 Stunden deaktiviert wurden.

F: Wie kann ich auf DynamoDB Streams zugreifen?

Sie können mit einem einfachen API-Aufruf auf den Stream zugreifen, indem Sie das DynamoDB SDK oder die Kinesis Client Library verwenden. Diese Bibliothek hilft Ihnen beim Nutzen und Verarbeiten der Daten des Streams und beim Verwalten von Aufgaben wie beispielsweise Lastausgleich zwischen mehreren Lesern, Reagieren auf Instance-Fehler und Einrichten von Checkpoints für verarbeitete Datensätze.

Weitere Informationen über den Zugriff auf DynamoDB Streams finden Sie in unserer Dokumentation.

F: Zeigt DynamoDB Streams alle Aktualisierungen meiner DynamoDB-Tabelle in der richtigen Reihenfolge an?

Änderungen aller einzelnen Elemente werden in der richtigen Reihenfolge angezeigt. Änderungen unterschiedlicher Elemente erscheinen im DynamoDB Stream möglicherweise in einer anderen Reihenfolge als sie empfangen wurden.

Beispiel: Sie haben eine DynamoDB-Tabelle, in der die Punkte für ein Spiel festgehalten werden. Jedes Element in der Tabelle steht für einen einzelnen Spieler. Angenommen, Sie führen die folgenden drei Änderungen in dieser Reihenfolge durch:

  • Aktualisierung 1: Punktzahl für Spieler 1 auf 100 Punkte setzen
  • Aktualisierung 2: Punktzahl für Spieler 2 auf 50 Punkte setzen
  • Aktualisierung 3: Punktzahl für Spieler 1 auf 125 Punkte setzen

Aktualisierung 1 und 3 haben das gleiche Element geändert (Spieler 1). Daher zeigt DynamoDB Stream, dass Aktualisierung 3 nach Aktualisierung 1 durchgeführt wurde. Dadurch können Sie die neueste Punktzahl für jeden Spieler abrufen. Der Stream zeigt möglicherweise nicht, dass alle drei Aktualisierungen in der gleichen Reihenfolge durchgeführt wurden (d. h. dass Aktualisierung 2 nach Aktualisierung 1 und vor Aktualisierung 3 durchgeführt wurde), aber die Aktualisierungen für die einzelnen Spieler werden in der richtigen Reihenfolge angezeigt.

F: Muss ich die Kapazität eines DynamoDB Stream verwalten?

Nein, die Kapazität für Ihren DynamoDB Stream wird automatisch verwaltet. Wenn der Datenverkehr in Ihre DynamoDB-Tabelle beträchtlich zunimmt, passt DynamoDB die Kapazität von DynamoDB Stream automatisch an, sodass auch weiterhin alle Aktualisierungen entgegengenommen werden können.

F: Mit welcher Geschwindigkeit kann ich aus einem DynamoDB Stream lesen?

Sie können Aktualisierungen aus Ihrem DynamoDB Stream mit der doppelten Geschwindigkeit der bereitgestellten Schreibkapazität Ihrer DynamoDB lesen. Wenn Sie beispielsweise genug Kapazität bereitgestellt haben, um in Ihrer DynamoDB-Tabelle 1.000 Elemente pro Sekunde zu aktualisieren, könnten Sie bis zu 2.000 Aktualisierungen pro Sekunde aus Ihrem DynamoDB Stream lesen.

F: Wenn ich meine DynamoDB-Tabelle lösche, wird dann auch der DynamoDB Stream gelöscht?

Nein, nicht sofort. Der DynamoDB Stream bleibt 24 Stunden lang bestehen, um Ihnen die Gelegenheit zu geben, die letzten Aktualisierungen Ihrer Tabelle zu lesen. Nach 24 Stunden wird der DynamoDB Stream automatisch gelöscht.

F: Was passiert, wenn ich DynamoDB Streams für meine Tabelle deaktiviere?

Wenn Sie DynamoDB Streams deaktivieren, bleibt der Stream 24 Stunden lang bestehen, wird aber nicht mehr aktualisiert, wenn Sie weitere Änderungen in Ihrer DynamoDB-Tabelle durchführen.

F: Was passiert, wenn ich DynamoDB Streams deaktiviere und dann wieder aktiviere?

Wenn Sie DynamoDB Streams deaktivieren, bleibt der Stream 24 Stunden lang bestehen, wird aber nicht mehr aktualisiert, wenn Sie weitere Änderungen in Ihrer DynamoDB-Tabelle durchführen. Wenn Sie DynamoDB Streams wieder aktivieren, wird dadurch ein neuer DynamoDB Stream erstellt, der die Änderungen Ihrer DynamoDB-Tabelle ab der Erstellung des neuen DynamoDB Streams enthält.

F: Kann es im DynamoDB Stream Duplikate oder Lücken geben?

Nein. DynamoDB Streams sind so konzipiert, dass jede Aktualisierung Ihrer Tabelle genau einmal im Stream dargestellt wird.

F: Welche Daten sind im DynamoDB Stream enthalten?

Der DynamoDB Stream enthält Daten sowohl zum vorherigen als auch zum geänderten Wert des Elements. Der DynamoDB Stream enthält außerdem den Primärschlüssel für die Tabelle. Der Benutzer kann wählen, ob das gesamte Element in den Stream aufgenommen wird, nur die Attribute oder einfach nur der Primärschlüssel..

F: Wie kann ich festlegen, welche Daten in den DynamoDB Stream aufgenommen werden?

Verwenden Sie bei neuen Tabellen den API-Aufruf "CreateTable" mit dem Parameter "ViewType", um festzulegen, welche Parameter in den DynamoDB Stream aufgenommen werden.

Verwenden Sie für eine bestehende Tabelle den Aufruf "UpdateTable" mit dem Parameter "ViewType", um festzulegen, welche Daten in den DynamoDB Stream aufgenommen werden.

ViewType: {
OldViewType: {ALL, CHANGED, NONE},
NewViewType: {ALL, CHANGED, NONE}
}

Die Werte haben folgende Bedeutung:

  • "ALL": Gesamtes Element aufnehmen. 
  • "CHANGED": Geänderte Attribute aufnehmen
  • "NONE": Keine Daten außer dem Element aufnehmen Dies gilt nur für "OldViewType". Sie könnten dies verwenden, wenn Sie nur die neue Version jedes geänderten Elements sehen möchten.

F: Kann ich meine Kinesis Client Library verwenden, um auf DynamoDB Streams zuzugreifen?

Ja. Entwickler, die mit Kinesis-APIs vertraut sind, können DynamoDB Streams problemlos nutzen. Sie können den DynamoDB Streams-Adapter benutzen, der die Amazon Kinesis-Schnittstelle implementiert, um Ihrer Anwendung die Verwendung der Amazon Kinesis Client Libraries (KCL) für den Zugriff auf DynamoDB Streams zu ermöglichen. Weitere Informationen über die Verwendung der KCL für den Zugriff auf DynamoDB Streams finden Sie in unserer Dokumentation.

F: Kann ich festlegen, welche Art von Informationen in den DynamoDB Stream aufgenommen wird?

Wenn Sie nach dem Erstellen eines DynamoDB Streams ändern möchten, welche Art von Informationen gespeichert wird, müssen Sie den DynamoDB Stream deaktivieren und mit der UpdateTable-API einen neuen erstellen.

F: Wenn ich meine DynamoDB-Tabelle ändere, wie schnell wird diese Änderung in einem DynamoDB Stream reflektiert?

Änderungen werden normalerweise in weniger als einer Sekunde im DynamoDB Stream reflektiert.

F: Wenn ich ein Element lösche, wird diese Änderung in den DynamoDB Stream aufgenommen?

Ja. Jede Aktualisierung im DynamoDB Stream enthält einen Parameter, der angibt, ob die Aktualisierung eine Löschung, eine Einfügung eines neuen Elements oder eine Änderung eines vorhandenen Elements war. Weitere Informationen über die Aktualisierungsarten finden Sie in unserer Dokumentation.

F: Wann kann ich, nachdem ich DynamoDB Streams für meine Tabelle aktiviert habe, mit dem Lesen des Streams beginnen?

Sie können die DescribeStream-API verwenden, um den aktuellen Status des Streams abzurufen. Sobald der Status "ENABLED" lautet, werden alle Aktualisierungen Ihrer Tabelle im Stream dargestellt.

Sie können aus dem Stream lesen, sobald Sie ihn gestartet haben. Möglicherweise enthält der Stream aber nicht alle Aktualisierungen der Tabelle, bevor der Status auf "ENABLED" gewechselt hat.