Bigtable für DynamoDB-Nutzer

Dieses Dokument richtet sich an DynamoDB-Entwickler und Datenbankadministratoren, die Anwendungen zur Verwendung mit Bigtable als Datenspeicher migrieren oder entwerfen möchten. Bevor Sie dieses Dokument lesen, sollten Sie sich die Bigtable-Übersicht durchlesen.

Bigtable und DynamoDB sind verteilte Speicher für Schlüssel/Wert-Paare, die Millionen von Abfragen pro Sekunde unterstützen, bis zu Petabyte an Daten skalieren können und Knotenausfälle tolerieren.

Die Feature-Sets dieser Datenbankdienste sind zwar ähnlich, die zugrunde liegenden Architekturen und Interaktionsdetails unterscheiden sich jedoch in einer Weise, die vor Beginn einer Migration wichtig ist. In diesem Dokument werden die Gemeinsamkeiten und Unterschiede zwischen den beiden Datenbanksystemen hervorgehoben.

Steuerungsebene

In DynamoDB und Bigtable können Sie mit der Steuerungsebene Ihre Kapazität konfigurieren sowie Ressourcen einrichten und verwalten. DynamoDB ist ein serverloses Produkt und die höchste Interaktionsebene mit DynamoDB ist die Tabellenebene. Im Modus „Bereitgestellte Kapazität“ stellen Sie hier Lese- und Schreibanfragen bereit, wählen Ihre Regionen und Replikation aus und verwalten Sicherungen. Bigtable ist kein serverloses Produkt. Sie müssen eine Instanz mit einem oder mehreren Clustern erstellen, deren Kapazität durch die Anzahl der vorhandenen Knoten bestimmt wird. Weitere Informationen zu diesen Ressourcen finden Sie unter Instanzen, Cluster und Knoten.

In der folgenden Tabelle werden Ressourcen der Steuerungsebene für DynamoDB und Bigtable verglichen.

DynamoDB Bigtable
Tabelle : Eine Sammlung von Elementen mit einem definierten Primärschlüssel. Tabellen haben Einstellungen für Sicherungen, Replikation und Kapazität. Instanz:Eine Gruppe von Bigtable-Clustern in verschiedenen Google Cloud-Zonen oder -Regionen, zwischen denen Replikation und Verbindungsrouting erfolgen. Replikationsrichtlinien werden auf Instanzebene festgelegt.

Cluster: Eine Gruppe von Knoten in derselben geografischen Google Cloud-Zone, die aus Gründen der Latenz und Replikation idealerweise mit Ihrem Anwendungsserver verbunden ist. Die Kapazität wird dadurch verwaltet, dass die Anzahl der Knoten in jedem Cluster angepasst wird.

Tabelle: Eine logische Organisation von Werten, die nach Zeilenschlüssel indexiert ist.

Sicherungen werden auf Tabellenebene gesteuert.
Lesekapazitätseinheit (RCU) und Schreibkapazitätseinheit (WCU): Einheiten, die Lese- oder Schreibvorgänge pro Sekunde bei fester Nutzlastgröße ermöglichen. Für jeden Vorgang mit größeren Nutzlasten werden Lese- oder Schreibeinheiten in Rechnung gestellt.

UpdateItem-Vorgänge nutzen die Schreibkapazität, die für die größte Größe eines aktualisierten Elements verwendet wird – entweder vor oder nach der Aktualisierung –, auch wenn die Aktualisierung eine Teilmenge der Attribute des Elements umfasst.		 Knoten: Eine virtuelle Rechenressource, die für das Lesen und Schreiben von Daten zuständig ist. Die Anzahl der Knoten, die ein Cluster hat, wird in Durchsatzlimits für Lese-, Schreibvorgänge und Scans umgewandelt. Sie können die Anzahl der Knoten abhängig von der Kombination Ihrer Latenzziele, der Anzahl der Anfragen und der Nutzlastgröße anpassen.

SSD-Knoten bieten denselben Durchsatz für Lese- und Schreibvorgänge, im Gegensatz zu dem erheblichen Unterschied zwischen RCU und WCU. Weitere Informationen finden Sie unter Leistung bei typischer Arbeitslast.
Partition: Ein Block mit zusammenhängenden Zeilen, unterstützt von Solid State Drives (SSDs), die sich zusammen mit Knoten befinden.

Jede Partition unterliegt einem festen Limit von 1.000 WCUs, 3.000 RCUs und 10 GB Daten.		 Tablet: Ein Block mit zusammenhängenden Zeilen, der auf dem Speichermedium Ihrer Wahl (SSD oder HDD) basiert.

Tabellen werden in Tablets fragmentiert, um die Arbeitslast zu verteilen. Tabellenreihen werden nicht auf Knoten in Bigtable gespeichert, sondern im verteilten Dateisystem von Google, was eine schnelle Umverteilung von Daten bei der Skalierung ermöglicht und zusätzliche Langlebigkeit durch die Verwaltung mehrerer Kopien bietet.
Globale Tabellen: Eine Möglichkeit, die Verfügbarkeit und Langlebigkeit Ihrer Daten zu erhöhen, indem Datenänderungen automatisch über mehrere Regionen verteilt werden. Replikation: Eine Möglichkeit, die Verfügbarkeit und Langlebigkeit Ihrer Daten zu erhöhen, indem Datenänderungen automatisch über mehrere Regionen oder mehrere Zonen innerhalb derselben Region weitergegeben werden.
Nicht zutreffend (N/A) Anwendungsprofil: Einstellungen, die Bigtable anweisen, wie ein Client-API-Aufruf an den entsprechenden Cluster in der Instanz weitergeleitet werden soll. Sie können ein App-Profil auch als Tag verwenden, um Messwerte für die Attribution zu segmentieren.

Geografische Replikation

Replikation wird verwendet, um Kundenanforderungen in folgenden Bereichen zu erfüllen:

  • Hochverfügbarkeit für die Geschäftskontinuität bei einem zonalen oder regionalen Ausfall
  • Dienstdaten in unmittelbarer Nähe von Endnutzern platzieren, um standortunabhängig mit niedriger Latenz bereitzustellen
  • Arbeitslastisolierung, wenn Sie eine Batcharbeitslast auf einem Cluster implementieren und sich auf die Replikation auf Bereitstellungscluster verlassen müssen.

Bigtable unterstützt replizierte Cluster in so vielen Zonen, die in bis zu acht Google Cloud-Regionen verfügbar sind, in denen Bigtable verfügbar ist. Die meisten Regionen haben drei Zonen. Bigtable repliziert automatisch Daten clusterübergreifend in einer multiprimären Topologie, sodass Sie in jedem Cluster lesen und schreiben können. Die Bigtable-Replikation ist Eventual Consistency. Weitere Informationen finden Sie unter Replikation – Übersicht.

DynamoDB bietet globale Tabellen, um die Tabellenreplikation über mehrere Regionen hinweg zu unterstützen. Globale Tabellen sind multiprimär und werden automatisch regionsübergreifend repliziert. Die Replikation ist letztendlich konsistent.

Die folgende Tabelle enthält Replikationskonzepte und beschreibt ihre Verfügbarkeit in DynamoDB und Bigtable.

Attribut DynamoDB Bigtable
Multi-primäre Replikation Ja.

Sie können in jeder globalen Tabelle lesen und schreiben.		 Ja.

Sie können in jedem Bigtable-Cluster lesen und schreiben.
Konsistenzmodell Schließlich konsistent.

Read-Your-Writes-Konsistenz auf regionaler Ebene für globale Tabellen.		 Schließlich konsistent.

Read-Your-Writes-Konsistenz auf Clusterebene für alle Tabellen, vorausgesetzt, Sie senden sowohl Lese- als auch Schreibvorgänge an denselben Cluster.
Replikationslatenz Kein Service Level Agreement (SLA).

Sekunden		 Kein SLA.

Sekunden
Detaillierungsgrad der Konfiguration Tabellenebene. Instanzebene.

Eine Instanz kann mehrere Tabellen enthalten.
Implementierung Erstellen Sie eine globale Tabelle mit einem Tabellenreplikat in jeder ausgewählten Region.

Regionale Ebene.

Automatische Replikation über mehrere Replikate hinweg durch Konvertierung einer Tabelle in eine globale Tabelle.

Für die Tabellen müssen DynamoDB-Streams aktiviert sein, wobei der Stream sowohl die neuen als auch die alten Images des Elements enthält.

Löschen Sie eine Region, um die globale Tabelle in dieser Region zu entfernen.		 Instanz mit mehr als einem Cluster erstellen
Die Replikation erfolgt automatisch clusterübergreifend in dieser Instanz.

Zonale Ebene.

Cluster zu einer Bigtable-Instanz hinzufügen oder daraus entfernen
Replikationsoptionen Pro Tabelle. Pro Instanz.
Traffic-Routing und -Verfügbarkeit Traffic, der an das nächstgelegene geografische Replikat weitergeleitet wird.

Im Falle eines Fehlers wenden Sie benutzerdefinierte Geschäftslogik an, um zu bestimmen, wann Anfragen an andere Regionen weitergeleitet werden sollen.		 Verwenden Sie Anwendungsprofile, um Richtlinien für das Cluster-Traffic-Routing zu konfigurieren.

Verwenden Sie Multi-Cluster-Routing, um Traffic automatisch an den nächstgelegenen intakten Cluster weiterzuleiten.

Im Falle eines Fehlers unterstützt Bigtable automatisches Failover zwischen Clustern für Hochverfügbarkeit.
Skalierung Die Schreibkapazität in replizierten Schreibanfrageneinheiten (R-WRU) wird über die Replikate hinweg synchronisiert.

Lesekapazität in replizierten Lesekapazitätseinheiten (R-RCU) pro Replikat.		 Sie können Cluster unabhängig voneinander skalieren, indem Sie nach Bedarf Knoten zu jedem replizierten Cluster hinzufügen oder daraus entfernen.
Cost R-WRUs kosten 50% mehr als normale WRUs. Die Knoten und der Speicher jedes Clusters werden Ihnen in Rechnung gestellt.
Für die regionale Replikation über Zonen hinweg fallen keine Kosten für die Netzwerkreplikation an.
Wenn die Replikation über Regionen oder Kontinente hinweg erfolgt, fallen Kosten an.
SLA 99,999 % 99,999 %

Datenebene

In der folgenden Tabelle werden die Datenmodellkonzepte für DynamoDB und Bigtable verglichen. Jede Zeile in der Tabelle beschreibt entsprechende Merkmale. Ein Element in DynamoDB ähnelt beispielsweise einer Zeile in Bigtable.

DynamoDB Bigtable
Element : Eine Gruppe von Attributen, die unter allen anderen Elementen anhand ihres Primärschlüssels eindeutig identifiziert werden können. Die maximal zulässige Größe beträgt 400 KB. Zeile : Eine einzelne Entität, die durch den Zeilenschlüssel identifiziert wird. Die maximal zulässige Größe beträgt 256 MB.
– Spaltenfamilie: Ein benutzerdefinierter Namespace, der Spalten gruppiert.
Attribut : Eine Gruppierung aus einem Namen und einem Wert. Ein Attributwert kann ein Skalar, eine Menge oder ein Dokumenttyp sein. Für die Attributgröße selbst gibt es keine explizite Beschränkung. Da jeder Artikel jedoch auf 400 KB begrenzt ist, kann das Attribut bei einem Artikel mit nur einem Attribut bis zu 400 KB abzüglich der durch den Attributnamen belegten Größe umfassen. Spaltenqualifizierer : Die eindeutige Kennzeichnung innerhalb einer Spaltenfamilie für eine Spalte. Die vollständige Kennzeichnung einer Spalte wird als „column-family:column-qualifier“ angegeben. Spaltenqualifizierer werden innerhalb der Spaltenfamilie lexikografisch sortiert.

Die maximal zulässige Größe für einen Spaltenqualifizierer beträgt 16 KB.


Zelle: Eine Zelle enthält die Daten für eine bestimmte Zeile, Spalte und einen bestimmten Zeitstempel. Eine Zelle enthält einen Wert, der bis zu 100 MB groß sein kann.
Primärschlüssel : Eine eindeutige Kennzeichnung für ein Element in einer Tabelle. Dies kann ein Partitionierungsschlüssel oder ein zusammengesetzter Schlüssel sein.

Partitionierungsschlüssel: Ein einfacher Primärschlüssel, der aus einem Attribut besteht. Dadurch wird die physische Partition bestimmt, in der sich das Element befindet. Die maximal zulässige Größe beträgt 2 KB.

Sortierschlüssel: Ein Schlüssel, der die Reihenfolge der Zeilen innerhalb einer Partition bestimmt. Die maximal zulässige Größe beträgt 1 KB.

Zusammengesetzter Schlüssel: Ein Primärschlüssel, der aus zwei Attributen besteht: dem Partitionierungsschlüssel und einem Sortierschlüssel oder Bereichsattribut.		 Zeilenschlüssel : Eine eindeutige Kennung für ein Element in einer Tabelle. Wird normalerweise durch eine Verkettung von Werten und Trennzeichen dargestellt. Die maximal zulässige Größe beträgt 4 KB.

Mit Spaltenqualifizierern kann ein Verhalten bereitgestellt werden, das dem Sortierschlüssel von DynamoDB entspricht.

Zusammengesetzte Schlüssel können mit verketteten Zeilenschlüsseln und Spaltenqualifizierern erstellt werden.

Weitere Informationen finden Sie im Abschnitt „Schemadesign“ in diesem Dokument im Beispiel für die Schemaübersetzung.
Gültigkeitsdauer : Mit Zeitstempeln pro Element wird festgelegt, wann ein Element nicht mehr benötigt wird. Nach dem Datum und der Uhrzeit des angegebenen Zeitstempels wird das Element aus der Tabelle gelöscht, ohne dass es zu einem Schreibdurchsatz kommt. Garbage Collection : Mit Zeitstempeln pro Zelle wird festgelegt, wann ein Element nicht mehr benötigt wird. Bei der automatischen Speicherbereinigung werden abgelaufene Elemente während eines Hintergrundprozesses gelöscht, der als Verdichtung bezeichnet wird. Richtlinien für die automatische Speicherbereinigung werden auf Spaltenfamilienebene festgelegt und können Elemente nicht nur basierend auf ihrem Alter, sondern auch anhand der Anzahl der Versionen löschen, die der Nutzer verwalten möchte. Sie müssen beim Anpassen der Clustergröße keine Kapazität für die Verdichtung berücksichtigen.

Operations

Mit Vorgängen auf Datenebene können Sie Aktionen zum Erstellen, Lesen, Aktualisieren und Löschen (CRUD) für Daten in einer Tabelle ausführen. In der folgenden Tabelle werden ähnliche Datenebenenvorgänge für DynamoDB und Bigtable verglichen.

DynamoDB Bigtable
CreateTable CreateTable
PutItem
BatchWriteItem		 MutateRow
MutateRows
Bigtable behandelt Schreibvorgänge als Upserts.
UpdateItem
  • Bedingtes Schreiben
  • Erhöhen und verringern
Bigtable behandelt Schreibvorgänge als Upserts.
GetItem
BatchGetItem, Query, Scan		 ReadRow
ReadRows (Bereich, Präfix, Umgekehrter Scan)
Bigtable unterstützt ein effizientes Scannen nach Zeilenschlüsselpräfix, regulärem Ausdrucksmuster oder Zeilenschlüsselbereich vorwärts oder rückwärts.

Datentypen

Sowohl Bigtable als auch DynamoDB sind schemalos. Spalten können beim Schreiben definiert werden, ohne dass eine tabellenweite Erzwingung für das Vorhandensein von Spalten oder für Datentypen erforderlich ist. Ebenso kann sich eine bestimmte Spalte oder ein bestimmter Attributdatentyp von Zeile oder Artikel unterscheiden. Die DynamoDB und die Bigtable API behandeln Datentypen jedoch auf unterschiedliche Weise.

Jede DynamoDB-Schreibanfrage enthält eine Typdefinition für jedes Attribut, die mit der Antwort auf Leseanfragen zurückgegeben wird.

Bigtable behandelt alles als Byte und erwartet, dass der Clientcode den Typ und die Codierung kennt, damit der Client die Antworten korrekt parsen kann. Eine Ausnahme sind increment-Vorgänge, die die Werte als vorzeichenbehaftete 64-Bit-Big-Endian-Ganzzahlen interpretieren.

In der folgenden Tabelle werden die Unterschiede bei den Datentypen zwischen DynamoDB und Bigtable verglichen.

DynamoDB Bigtable
Skalare Typen : werden als Datentypdeskriptor-Token in der Serverantwort zurückgegeben. Byte : Byte werden in der Clientanwendung in die gewünschten Typen umgewandelt.

Increment interpretiert den Wert als 64-Bit-Big-Endian-Ganzzahl
Set : Eine unsortierte Sammlung eindeutiger Elemente. Spaltenfamilie: Sie können Spaltenqualifizierer als festgelegte Mitgliedernamen verwenden und für jeden ein einzelnes 0-Byte als Zellenwert angeben. Satzmitglieder werden lexikografisch innerhalb ihrer Spaltenfamilien sortiert.
Zuordnung : Eine unsortierte Sammlung von Schlüssel/Wert-Paaren mit eindeutigen Schlüsseln. Spaltenfamilie
Verwenden Sie den Spaltenqualifizierer als Zuordnungsschlüssel und den Zellenwert für den Wert. Zuordnungsschlüssel werden lexikografisch sortiert.
Liste : Eine sortierte Sammlung von Elementen. Spaltenqualifizierer
Verwenden Sie den „Zeitstempel einfügen“, um das Äquivalent des Verhaltens „list_append“ zu erreichen, umgekehrt von „Zeitstempel einfügen“ für „Voranstellen“.

Schemadesign

Eine wichtige Überlegung beim Schemadesign ist die Speicherung der Daten. Zu den wichtigsten Unterschieden zwischen Bigtable und DynamoDB gehört die Verarbeitung folgender Elemente:

  • Aktualisierung einzelner Werte
  • Datensortierung
  • Datenversionsverwaltung
  • Speicherung großer Werte

Aktualisierung einzelner Werte

UpdateItem-Vorgänge in DynamoDB verbrauchen die Schreibkapazität für die größere der Elementgrößen "vor" und "nach", auch wenn die Aktualisierung eine Teilmenge der Attribute des Elements umfasst. Dies bedeutet, dass Sie in DynamoDB häufig aktualisierte Spalten möglicherweise in separaten Zeilen platzieren, auch wenn sie logisch in dieselbe Zeile mit anderen Spalten gehören.

Bigtable kann eine Zelle genauso effizient aktualisieren, unabhängig davon, ob es sich um die einzige Spalte in einer bestimmten Zeile oder um eine Spalte aus vielen Tausend handelt. Weitere Informationen finden Sie unter Einfache Schreibvorgänge.

Datensortierung

DynamoDB-Hashes und zufällig verteilt Partitionsschlüssel, während Bigtable Zeilen in lexikografischer Reihenfolge nach Zeilenschlüssel speichert und jegliche Hash-Technologie dem Nutzer überlässt.

Die Zufallsschlüsselverteilung ist nicht für alle Zugriffsmuster optimal. Es verringert das Risiko von Hotspots mit aktiven Zeilenbereichen, macht aber Zugriffsmuster mit Scans, die über Partitionsgrenzen hinausgehen, teuer und ineffizient. Diese unbegrenzten Scans sind üblich, insbesondere bei Anwendungsfällen mit einer Zeitdimension.

Für diese Art von Zugriffsmuster, also Scans, die Partitionsgrenzen überschreiten, ist ein sekundärer Index in DynamoDB erforderlich. Bigtable verarbeitet dies jedoch, ohne dass ein sekundärer Index erforderlich ist. Ebenso sind in DynamoDB Abfrage- und Scanvorgänge auf 1 MB gescannte Daten beschränkt, sodass eine Paginierung über dieses Limit hinaus erforderlich ist. Bigtable hat keine solche Begrenzung.

Trotz der zufällig verteilten Partitionsschlüssel kann DynamoDB weiterhin Hot-Partitionen haben, wenn ein ausgewählter Partitionierungsschlüssel Traffic nicht gleichmäßig verteilt, was sich negativ auf den Durchsatz auswirkt. Zur Behebung dieses Problems empfiehlt DynamoDB Write-Sharding, bei dem Schreibvorgänge nach dem Zufallsprinzip auf mehrere logische Partitionsschlüsselwerte aufgeteilt werden.

Um dieses Designmuster anzuwenden, müssen Sie eine Zufallszahl aus einem festen Satz (z. B. 1 bis 10) erstellen und diese Zahl dann als logischen Partitionsschlüssel verwenden. Da Sie den Partitionierungsschlüssel zufällig festlegen, werden die Schreibvorgänge in der Tabelle gleichmäßig auf alle Partitionierungsschlüsselwerte verteilt.

Bigtable bezeichnet dieses Verfahren als Key Salting. Mit diesem Verfahren lassen sich Hot-Tablets effektiv vermeiden.

Datenversionsverwaltung

Jede Bigtable-Zelle hat einen Zeitstempel. Der neueste Zeitstempel ist immer der Standardwert für eine bestimmte Spalte. Ein häufiger Anwendungsfall für Zeitstempel ist die Versionsverwaltung, also das Schreiben einer neuen Zelle in eine Spalte, die sich von vorherigen Versionen der Daten für diese Zeile und Spalte durch ihren Zeitstempel unterscheidet.

DynamoDB verfolgt kein solches Konzept und erfordert komplexe Schemadesigns, um die Versionsverwaltung zu unterstützen. Bei diesem Ansatz werden zwei Kopien jedes Elements erstellt: eine Kopie mit dem Versionsnummernpräfix 0 wie v0_ am Anfang des Sortierschlüssels und eine weitere Kopie mit dem Versionsnummernpräfix 1, z. B. v1_. Bei jeder Aktualisierung des Elements verwenden Sie im Sortierschlüssel der aktualisierten Version das nächsthöhere Versionspräfix und kopieren den aktualisierten Inhalt in das Element mit dem Versionspräfix null. Dadurch wird sichergestellt, dass die neueste Version eines Elements mit dem Präfix Null ermittelt werden kann. Diese Strategie erfordert nicht nur die Verwaltung der anwendungsseitigen Logik, sondern macht Datenschreibvorgänge sehr teuer und langsam, da jeder Schreibvorgang einen Lesevorgang des vorherigen Werts und zwei Schreibvorgänge erfordert.

Mehrzeilige Transaktionen im Vergleich zu großen Zeilenkapazität

Bigtable unterstützt keine mehrzeiligen Transaktionen. Da Sie damit jedoch Zeilen speichern können, die viel größer sind als Elemente in DynamoDB sein können, erreichen Sie die beabsichtigte Transaktionalität oft, indem Sie Ihre Schemas so konzipieren, dass relevante Elemente unter einem gemeinsamen Zeilenschlüssel gruppiert werden. Ein Beispiel, das diesen Ansatz veranschaulicht, finden Sie unter Designmuster für eine einzelne Tabelle.

Große Werte speichern

Da ein DynamoDB-Element, das einer Bigtable-Zeile entspricht, auf 400 KB begrenzt ist, muss der Wert für das Speichern großer Werte entweder in Elemente aufgeteilt oder in anderen Medien wie S3 gespeichert werden. Beide Ansätze erhöhen die Komplexität Ihrer Anwendung. Im Gegensatz dazu kann eine Bigtable-Zelle bis zu 100 MB speichern und eine Bigtable-Zeile bis zu 256 MB unterstützen.

Beispiele für die Schemaübersetzung

Die Beispiele in diesem Abschnitt übersetzen Schemas von DynamoDB in Bigtable unter Berücksichtigung der Unterschiede im Design des Schlüsselschemas.

Grundlegende Schemas migrieren

Produktkataloge sind ein gutes Beispiel zur Veranschaulichung des grundlegenden Schlüssel/Wert-Musters. Im Folgenden sehen Sie, wie ein solches Schema in DynamoDB aussehen könnte.

Primärschlüssel Attribute
Partitionierungsschlüssel Sortierschlüssel Beschreibung Preis Miniaturansicht
Hüte Filzhut#brandA Hergestellt aus hochwertiger Wolle... 30 https://storage…
Hüte Filzhut#brandB Strapazierfähiges wasserabweisendes Canvas mit... 28 https://storage…
Hüte zeitungsjunge#markeB Verleihen Sie Ihrem Alltag einen Hauch von Vintage-Charme. 25 https://storage…
Schuhe sneakers#markeA Stilvoll und bequem durch den Tag... 40 https://storage…
Schuhe sneakers#markeB Klassische Ausstattung mit modernen Materialien... 50 https://storage…

Bei dieser Tabelle ist die Zuordnung von DynamoDB zu Bigtable unkompliziert: Sie konvertieren den zusammengesetzten Primärschlüssel von DynamoDB in einen zusammengesetzten Bigtable-Zeilenschlüssel. Sie erstellen eine Spaltenfamilie (SKU), die denselben Satz von Spalten enthält.

Artikelnummer
Zeilenschlüssel Beschreibung Preis Miniaturansicht
hüte#fedoras#markeA Hergestellt aus hochwertiger Wolle... 30 https://storage…
hüte#fedoras#markeB Strapazierfähiges wasserabweisendes Canvas mit... 28 https://storage…
hüte#newsboy#markeB Verleihen Sie Ihrem Alltag einen Hauch von Vintage-Charme. 25 https://storage…
schuhe#sneaker#markeA Stilvoll und bequem durch den Tag... 40 https://storage…
Schuhe#Sneaker#MarkeB Klassische Ausstattung mit modernen Materialien... 50 https://storage…

Designmuster für eine einzelne Tabelle

Ein einzelnes Tabellendesignmuster fasst mehrere Tabellen in einer relationalen Datenbank in einer einzigen Tabelle in DynamoDB zusammen. Sie können den Ansatz aus dem vorherigen Beispiel wählen und dieses Schema unverändert in Bigtable duplizieren. Es ist jedoch besser, die Probleme des Schemas während des Prozesses anzugehen.

In diesem Schema enthält der Partitionsschlüssel die eindeutige ID für ein Video. So können alle Attribute im Zusammenhang mit diesem Video für einen schnelleren Zugriff sortiert werden. Aufgrund der Größenbeschränkungen für Elemente von DynamoDB ist es nicht möglich, eine unbegrenzte Anzahl von Freitextkommentaren in eine einzelne Zeile aufzunehmen. Daher wird ein Sortierschlüssel mit dem Muster VideoComment#reverse-timestamp verwendet, um für jeden Kommentar eine separate Zeile innerhalb der Partition zu erstellen, die in umgekehrter chronologischer Reihenfolge sortiert ist.

Angenommen, dieses Video hat 500 Kommentare und der Rechteinhaber möchte das Video entfernen. Das bedeutet, dass auch alle Kommentare und Videoattribute gelöscht werden müssen. Dazu müssen Sie in DynamoDB alle Schlüssel in dieser Partition scannen und dann mehrere Löschanfragen senden, die alle durchlaufen. DynamoDB unterstützt mehrzeilige Transaktionen, aber diese Löschanfrage ist zu groß, um sie in einer einzelnen Transaktion durchzuführen.

Primärschlüssel Attribute
Partitionierungsschlüssel Sortierschlüssel UploadDate Formate
0123 Video 2023-09-10T15:21:48 {"480": "https://storage...", "720": "https://storage...", "1080p": "https://storage..."}
Videokommentar#98765481 Content
Das gefällt mir sehr. Spezialeffekte sind toll.
Videokommentar#86751345 Content
Bei 1:05 Uhr ist ein Audiofehler aufgetreten.
VideoStatsLikes Anzahl
3
VideoStatsViews Anzahl
156
0124 Video 2023-09-10T17:03:21 {"480": "https://storage…", "720": "https://storage…"}
Videokommentar#97531849 Content
Ich habe das mit allen meinen Freunden geteilt.
Videokommentar#87616471 Content
Der Stil erinnert mich an einen Regisseur, aber ich kann nicht darauf achten.
VideoStats ViewCount
45

Ändern Sie dieses Schema während der Migration, damit Sie Ihren Code vereinfachen und Datenanfragen schneller und kostengünstiger stellen können. Bigtable-Zeilen haben eine viel größere Kapazität als DynamoDB-Elemente und können eine große Anzahl von Kommentaren verarbeiten. Falls ein Video Millionen von Kommentaren erhält, können Sie eine Richtlinie für die automatische Speicherbereinigung festlegen, um nur eine feste Anzahl der neuesten Kommentare beizubehalten.

Da Zähler ohne Aktualisierung der gesamten Zeile aktualisiert werden können, müssen Sie sie auch nicht aufteilen. Sie müssen auch keine UploadDate-Spalte verwenden oder einen umgekehrten Zeitstempel berechnen und diesen zu Ihrem Sortierschlüssel machen, da Bigtable-Zeitstempel Ihnen automatisch die umgekehrten chronologisch sortierten Kommentare liefern. Dies vereinfacht das Schema erheblich. Wenn ein Video entfernt wird, können Sie die Zeile des Videos einschließlich aller Kommentare in einer einzigen Anfrage entfernen.

Da die Spalten in Bigtable lexikografisch geordnet sind, können Sie die Spalten zur Optimierung so umbenennen, dass ein schneller Bereichsscan möglich ist – von Videoattributen bis zu den N letzten Kommentaren über die Videoattribute – in einer einzelnen Leseanfrage. Dies sollten Sie tun, wenn das Video geladen ist. Später kannst du beim Scrollen durch die restlichen Kommentare blättern.

Attribute
Zeilenschlüssel Formate „Mag ich“-Bewertungen Aufrufe UserComments
0123 {"480": "https://storage...", "720": "https://storage...", "1080p": "https://storage..."} @2023-09-10T15:21:48 3 156 Das gefällt mir sehr. Spezialeffekte sind toll. @ 2023-09-10T19:01:15
Um 1:05 Uhr ist ein Audiofehler aufgetreten. @ 10.09.2023T16:30:42
0124 {"480": "https://storage...", "720":"https://storage..."} @2023-09-10T17:03:21 45 Der Stil erinnert mich an einen Regisseur, aber ich kann nicht darauf achten. @2023-10-12T07:08:51

Designmuster der Adjacency-Liste

Betrachten Sie eine etwas andere Version dieses Designs, die DynamoDB häufig als Designmuster der Nachbarschaftslisten bezeichnet.

Primärschlüssel Attribute
Partitionierungsschlüssel Sortierschlüssel DateCreated Details
Invoice-0123 Invoice-0123 2023-09-10T15:21:48 {"discount": 0,10,
"sales_tax_usd":"8",
"due_date":"2023-10-03.."}
Payment-0680 2023-09-10T15:21:40 {"amount_usd": 120, "bill_to":"John...",
"address":"123 Abc St..."}
Payment-0789 2023-09-10T15:21:31 {"amount_usd": 120, "bill_to":"Jane...",
"address":"Xyz St. 13"}
Invoice-0124 Invoice-0124 2023-09-09T10:11:28 {"discount": 0,20,
"sales_tax_usd":"11",
"due_date":"2023-10-03.."}
Payment-0327 2023-09-09T10:11:10 {"amount_usd": 180, "bill_to":"Bernd...",
"address":"321 Cba St..."}
Payment-0275 2023-09-09T10:11:03 {"amount_usd": 70, "bill_to":"Kate...",
"address":"21 Zyx St..."}

In dieser Tabelle basieren die Sortierschlüssel nicht auf der Zeit, sondern auf den Zahlungs-IDs. Sie können also ein anderes breites Spaltenmuster verwenden und diese IDs in Bigtable zu separaten Spalten machen. Dies hat ähnliche Vorteile wie im vorherigen Beispiel.

Rechnung Zahlung
Zeilenschlüssel Details 0680 0789
0123 {"discount": 0,10,
"sales_tax_usd":"8",
"due_date":"2023-10-03.."}
am 10.09.2023T15:21:48		 {"amount_usd": 120, "bill_to":"John...",
"address":"123 Abc St..."} @ 2023-09-10T15:21:40		 {"amount_usd": 120, "bill_to":"Jane...",
"address":"13 Xyz St..."}
@ 2023-09-10T15:21:31
Zeilenschlüssel Details 0275 0327
0124 {"discount": 0,20,
"sales_tax_usd":"11",
"due_date":"2023-10-03.."}
@ 2023-09-09T10:11:28		 {"amount_usd": 70, "bill_to":"Kate...",
"address":"21 Zyx St..."}
@ 2023-09-09T10:11:03		 {"amount_usd": 180, "bill_to":"Bob...",
"address":"321 Cba St..."}
@ 2023-09-09T10:11:10

Wie Sie in den vorherigen Beispielen sehen können, kann das spaltenorientierte Modell von Bigtable mit dem richtigen Schemadesign sehr leistungsfähig sein und viele Anwendungsfälle unterstützen, die teure mehrzeilige Transaktionen, eine sekundäre Indexierung oder eine Kaskaden bei Löschvorgängen in anderen Datenbanken erfordern würden.

Nächste Schritte