Bigtable für DynamoDB-Nutzer

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

Bigtable und DynamoDB sind verteilte Speicher für Schlüssel/Wert-Paare, die Millionen von Abfragen pro Sekunde unterstützen, Speicher bereitstellen, der sich auf Petabyte an Daten skalieren lässt, und Knotenausfälle tolerieren.

Während die Feature-Sets dieser Datenbankdienste ähnlich sind, unterscheiden sich die zugrunde liegenden Architekturen und Interaktionsdetails in einer Weise, die vor Beginn der Migration wichtig zu verstehen ist. In diesem Dokument werden die Gemeinsamkeiten und Unterschiede zwischen den beiden Datenbanksystemen aufgezeigt.

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. Die höchste Interaktionsebene mit DynamoDB ist die Tabellenebene. Im Modus für bereitgestellte Kapazität stellen Sie hier Ihre Lese- und Schreibanfrageeinheiten 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 die Ressourcen der Steuerungsebene für DynamoDB und Bigtable verglichen.

DynamoDB Bigtable
Tabelle : Eine Sammlung von Elementen mit einem definierten Primärschlüssel. Tabellen enthalten 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 stattfinden. Replikationsrichtlinien werden auf Instanzebene festgelegt.

Cluster: Eine Gruppe von Knoten in derselben geografischen Google Cloud-Zone, die aus Latenz- und Replikationsgründen idealerweise mit Ihrem Anwendungsserver zusammengelegt ist. Die Kapazität wird durch Anpassen der Anzahl der Knoten in jedem Cluster verwaltet.

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 mit einer festen Nutzlastgröße zulassen. Bei jedem Vorgang mit größeren Nutzlastgrößen werden Ihnen Lese- oder Schreibeinheiten in Rechnung gestellt.

UpdateItem-Vorgänge verbrauchen 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 einen Teil der Attribute des Elements umfasst.		 Knoten: Eine virtuelle Rechenressource, die für das Lesen und Schreiben von Daten verantwortlich ist. Die Anzahl der Knoten, die ein Cluster hat, ändert sich in Durchsatzlimits für Lese-, Schreib- und Scans. Sie können die Anzahl der Knoten abhängig von der Kombination Ihrer Latenzziele, der Anzahl der Anfragen und der Nutzlastgröße anpassen.

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

Für jede Partition gilt ein festes Limit von 1.000 WCUs, 3.000 RCUs und 10 GB Daten.		 Tablet: Ein Block aus zusammenhängenden Zeilen, der vom Speichermedium Ihrer Wahl (SSD oder HDD) unterstützt wird.

Tabellen sind in Tabellenreihen fragmentiert, um die Arbeitslast zu verteilen. Tabellenreihen werden nicht auf Knoten in Bigtable gespeichert, sondern im verteilten Dateisystem von Google, das eine schnelle Umverteilung von Daten bei der Skalierung ermöglicht und zusätzliche Langlebigkeit durch die Beibehaltung 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 hinweg weitergegeben 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 wird. Sie können ein App-Profil auch als Tag verwenden, um Messwerte für die Attribution zu segmentieren.

Geografische Replikation

Die Replikation wird verwendet, um Kundenanforderungen für Folgendes zu erfüllen:

  • Hochverfügbarkeit für die Geschäftskontinuität bei einem zonalen oder regionalen Ausfall
  • Platzieren Ihrer Dienstdaten in der Nähe von Endnutzern, um überall auf der Welt eine niedrige Latenz bereitzustellen.
  • Arbeitslastisolierung, wenn Sie eine Batcharbeitslast auf einem Cluster implementieren und auf die Replikation auf Bereitstellungsclustern angewiesen sind.

Bigtable unterstützt replizierte Cluster in so vielen Zonen, die verfügbar sind, und zwar in bis zu acht Google Cloud-Regionen, in denen Bigtable verfügbar ist. Die meisten Regionen haben drei Zonen. Bigtable repliziert Daten automatisch über mehrere Cluster in einer Multi-primären Topologie, was bedeutet, dass Sie in jedem Cluster lesen und schreiben können. Die Bigtable-Replikation ist letztendlich konsistent. Weitere Informationen finden Sie unter Replikation – Übersicht.

DynamoDB bietet globale Tabellen zur Unterstützung der Tabellenreplikation über mehrere Regionen hinweg. Globale Tabellen sind multiprimär und werden automatisch über Regionen hinweg repliziert. Die Replikation ist Eventual Consistency.

In der folgenden Tabelle sind Replikationskonzepte aufgeführt und ihre Verfügbarkeit in DynamoDB und Bigtable beschrieben.

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 Irgendwann einheitlich.

Read-Your-Writes-Konsistenz auf regionaler Ebene für globale Tabellen		 Irgendwann einheitlich.

Read-Your-Writes-Konsistenz auf regionaler Ebene für alle Tabellen
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 Replikate hinweg, indem eine Tabelle in eine globale Tabelle konvertiert wird.

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

Löschen Sie eine Region, um die globale Tabelle aus dieser Region zu entfernen.		 Erstellen Sie eine Instanz mit mehr als einem Cluster.
Die Replikation erfolgt automatisch in allen Clustern dieser Instanz.

Zonale Ebene.

Cluster zu einer Bigtable-Instanz hinzufügen und daraus entfernen.
Replikationsoptionen Pro Tabelle. Pro Instanz.
Routenführung und -verfügbarkeit Traffic, der an das nächste geografische Replikat weitergeleitet wird.

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

Mit Multi-Cluster-Routing können Sie Traffic automatisch an den nächsten fehlerfreien Cluster weiterleiten.

Im Falle eines Fehlers unterstützt Bigtable automatischen Failover zwischen Clustern für Hochverfügbarkeit.
Skalierung Die Schreibkapazität in replizierten Schreibanfrageeinheiten (R-WRU) wird auf allen Replikaten synchronisiert.

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

Datenebene

In der folgenden Tabelle werden Datenmodellkonzepte für DynamoDB und Bigtable verglichen. Jede Zeile in der Tabelle beschreibt analoge 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 identifizierbar ist. 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-, Satz- oder Dokumenttyp sein. Es gibt keine explizite Beschränkung für die Attributgröße selbst. Da jedes Element jedoch auf 400 KB beschränkt ist, kann das Attribut bei einem Element, das nur ein Attribut hat, bis zu 400 KB abzüglich der Größe des Attributnamens sein. Spaltenqualifizierer : Die eindeutige Kennung innerhalb einer Spaltenfamilie für eine Spalte. Die vollständige Kennung einer Spalte wird als „column-family:column-qualifier“ ausgedrückt. Spaltenqualifizierer werden lexikografisch innerhalb der Spaltenfamilie 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 Kennung für ein Element in einer Tabelle. Es kann ein Partitionsschlüssel oder ein zusammengesetzter Schlüssel sein.

Partitionsschlüssel: Ein einfacher Primärschlüssel, der aus einem Attribut besteht. Dies bestimmt die physische Partition, 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 festlegt. Die maximal zulässige Größe beträgt 1 KB.

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

Spaltenqualifizierer können verwendet werden, um ein Verhalten zu liefern, 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 Beispiel zur Schemaübersetzung im Abschnitt „Schemadesign“ dieses Dokuments.
Gültigkeitsdauer : Zeitstempel für einzelne Elemente bestimmen, wann ein Artikel nicht mehr benötigt wird. Nach dem Datum und der Uhrzeit des angegebenen Zeitstempels wird das Element aus der Tabelle gelöscht, ohne dass dabei Schreibdurchsatz verbraucht wird. Speicherbereinigung : Anhand von Zeitstempeln pro Zelle wird ermittelt, wann ein Element nicht mehr benötigt wird. Bei der automatischen Speicherbereinigung werden abgelaufene Elemente während eines Hintergrundprozesses, der als Verdichtung bezeichnet wird, gelöscht. Richtlinien für die automatische Speicherbereinigung werden auf Spaltenfamilienebene festgelegt und können Elemente nicht nur aufgrund ihres Alters, sondern auch nach der Anzahl der Versionen löschen, die der Nutzer verwalten möchte. Sie müssen beim Ändern der Clustergröße keine Kapazität für die Verdichtung berücksichtigen.

Operations

Mit Datenebenenvorgängen können Sie Erstellungs-, Lese-, Aktualisierungs- und Löschaktionen (CRUD) für Daten in einer Tabelle ausführen. In der folgenden Tabelle werden ähnliche Vorgänge auf Datenebenen für DynamoDB und Bigtable verglichen.

DynamoDB Bigtable
CreateTable CreateTable
PutItem
BatchWriteItem		 MutateRow
MutateRows
Bigtable behandelt Schreibvorgänge als Upserts.
UpdateItem
  • Bedingter Schreibvorgang
  • Erhöhung und Verringerung
Bigtable behandelt Schreibvorgänge als Upserts.
GetItem
BatchGetItem, Query, Scan		 `ReadRow`
`ReadRows` (Bereich, Präfix, Reverse Scan)
Bigtable unterstützt effizientes Scannen nach Zeilenschlüsselpräfix, Muster mit regulären Ausdrücken oder Zeilenschlüsselbereich vor oder zurück.

Datentypen

Sowohl Bigtable als auch DynamoDB sind schemalos. Spalten können beim Schreiben definiert werden, ohne dass das Vorhandensein von Spalten oder Datentypen in der gesamten Tabelle erzwungen wird. Ebenso kann sich ein bestimmter Spalten- oder Attributdatentyp von einer Zeile oder einem Element zur anderen unterscheiden. Die DynamoDB und Bigtable APIs gehen jedoch auf unterschiedliche Weise mit Datentypen um.

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

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

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

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

Increment interpretiert den Wert als 64-Bit-Big-Endian-Ganzzahl
Set (Satz): Eine unsortierte Sammlung eindeutiger Elemente. Spaltenfamilie : Sie können Spaltenqualifizierer als Set-Mitgliedernamen verwenden und für jeden einzelnen ein einzelnes 0-Byte als Zellenwert angeben. Satzmitglieder werden lexikografisch innerhalb ihrer Spaltenfamilie 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 Verhalten von „list_append“ zu erreichen, umgekehrt.

Schemadesign

Ein wichtiger Aspekt beim Schemadesign ist, wie die Daten gespeichert werden. Die Hauptunterschiede zwischen Bigtable und DynamoDB sind der Umgang mit Folgendem:

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

Aktualisierung einzelner Werte

UpdateItem-Vorgänge in DynamoDB verbrauchen die Schreibkapazität für den größeren der Werte für „Vorher“ und „Nach“, auch wenn die Aktualisierung eine Teilmenge der Attribute des Elements beinhaltet. Dies bedeutet, dass Sie in DynamoDB häufig aktualisierte Spalten möglicherweise in separate Zeilen einfügen, auch wenn sie logisch in dieselbe Zeile mit anderen Spalten gehören.

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

Datensortierung

DynamoDB führt Hashes aus und verteilt Partitionsschlüssel nach dem Zufallsprinzip. Bigtable speichert Zeilen in lexikografischer Reihenfolge nach Zeilenschlüssel und überlässt jede Hash-Technologie dem Nutzer.

Die Zufallsschlüsselverteilung ist nicht für alle Zugriffsmuster optimal. Es verringert das Risiko von Hot-Row-Bereichen, macht jedoch Zugriffsmuster mit Scans, die Partitionsgrenzen überschreiten, teuer und ineffizient. Diese unbegrenzten Scans sind üblich, insbesondere für Anwendungsfälle mit einer Zeitdimension.

Für die Verarbeitung dieser Art von Zugriffsmustern, also zum Scannen von partitionierten Grenzen, ist ein sekundärer Index in DynamoDB erforderlich. Bigtable verarbeitet ihn jedoch ohne einen sekundären Index. In DynamoDB sind Abfrage- und Scanvorgänge auf 1 MB an gescannten Daten beschränkt, sodass eine Paginierung über dieses Limit hinaus erforderlich ist. Bigtable hat kein solches Limit.

Trotz der zufällig verteilten Partitionsschlüssel kann DynamoDB immer noch Hot-Partitionen haben, wenn ein ausgewählter Partitionsschlüssel den Traffic nicht gleichmäßig verteilt, was sich negativ auf den Durchsatz auswirkt. Um dieses Problem zu beheben, empfiehlt DynamoDB die Schreibfragmentierung, bei der Schreibvorgänge nach dem Zufallsprinzip auf mehrere logische Partitionsschlüsselwerte aufgeteilt werden.

Um dieses Designmuster anwenden zu können, 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 Partitionsschlüssel zufällig auswählen, werden die Schreibvorgänge in die Tabelle gleichmäßig auf alle Werte der Partitionsschlüssel verteilt.

Bigtable bezeichnet dieses Verfahren als Key-Salting und kann eine effektive Möglichkeit sein, um Hot-Tablets zu vermeiden.

Datenversionsverwaltung

Jede Bigtable-Zelle hat einen Zeitstempel. Der letzte Zeitstempel ist immer der Standardwert für eine bestimmte Spalte. Ein häufiger Anwendungsfall für Zeitstempel ist die Versionsverwaltung. Dabei wird eine neue Zelle in eine Spalte geschrieben, die sich durch ihren Zeitstempel von vorherigen Versionen der Daten für diese Zeile und Spalte unterscheidet.

DynamoDB hat 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 Präfix der Versionsnummer null, z. B. v0_ am Anfang des Sortierschlüssels, und eine weitere Kopie mit einem Präfix für die Versionsnummer, 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 beliebigen Elements mit dem Präfix null gefunden werden kann. Diese Strategie erfordert nicht nur die Aufrechterhaltung der anwendungsseitigen Logik, sondern macht auch Datenschreibvorgänge sehr teuer und langsam, da jeder Schreibvorgang ein Lesen des vorherigen Werts sowie zwei Schreibvorgänge erfordert.

Transaktionen für mehrere Zeilen und große Zeilenkapazität im Vergleich

Bigtable unterstützt keine mehrzeiligen Transaktionen. Da Sie damit jedoch Zeilen speichern können, die viel größer sind als Elemente in DynamoDB, können Sie häufig die beabsichtigte Transaktionalität erhalten, indem Sie Ihre Schemas so entwerfen, 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 beschränkt ist, muss zum Speichern großer Werte entweder der Wert auf 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.

Beispiele für Schemaübersetzung

In den Beispielen in diesem Abschnitt werden Schemas von DynamoDB in Bigtable unter Berücksichtigung der wichtigsten Unterschiede beim Schemadesign übersetzt.

Einfache Schemas migrieren

Produktkataloge sind ein gutes Beispiel, um das grundlegende Muster für Schlüssel/Wert-Paare zu veranschaulichen. So könnte ein solches Schema in DynamoDB aussehen.

Primärschlüssel Attribute
Partitionsschlüssel Sortierschlüssel Beschreibung Preis Miniaturansicht
Hüte fedoras#markeA Aus hochwertiger Wolle... 30 https://storage…
Hüte fedoras#markeB Der robuste, wasserabweisende Canvas, der... 28 https://storage…
Hüte nachrichtenjunge#markeB Verleihen Sie Ihrem Alltagslook einen Vintage-Charme. 25 https://storage…
Schuhe sneakers#markeA Stilvoll und bequem mit... 40 https://storage…
Schuhe Sneaker#MarkeB Klassische Elemente mit modernen Materialien... 50 https://storage…

Für diese Tabelle ist die Zuordnung von DynamoDB zu Bigtable einfach: 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 Aus hochwertiger Wolle... 30 https://storage…
Hüte#fedoras#markeB Der robuste, wasserabweisende Canvas, der... 28 https://storage…
Hüte#newsboy#markeB Verleihen Sie Ihrem Alltagslook einen Vintage-Charme. 25 https://storage…
Schuhe#Sneaker#MarkeA Stilvoll und bequem mit... 40 https://storage…
Schuhe#Sneaker#MarkeB Klassische Elemente mit modernen Materialien... 50 https://storage…

Designmuster für einzelne Tabellen

Ein Designmuster für eine einzelne Tabelle führt mehrere Tabellen in einer relationalen Datenbank zu einer einzigen Tabelle in DynamoDB zusammen. Sie können sich für das vorherige Beispiel entscheiden und dieses Schema unverändert in Bigtable duplizieren. Es ist jedoch besser, dabei die Probleme des Schemas anzugehen.

In diesem Schema enthält der Partitionsschlüssel die eindeutige ID für ein Video. Dies hilft dabei, alle zu diesem Video gehörenden Attribute für einen schnelleren Zugriff zu gruppieren. Angesichts der Größenbeschränkungen für Elemente in DynamoDB können Sie keine unbegrenzte Anzahl von Freitextkommentaren in eine einzelne Zeile einfügen. Daher wird ein Sortierschlüssel mit dem Muster VideoComment#reverse-timestamp verwendet, um jeden Kommentar zu einer separaten Zeile innerhalb der Partition zu machen, die in umgekehrter chronologischer Reihenfolge sortiert ist.

Angenommen, zu diesem Video gibt es 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 jeden Schritt durchlaufen. DynamoDB unterstützt Transaktionen über mehrere Zeilen, aber diese Löschanfrage ist zu groß, um sie in einer einzelnen Transaktion auszuführen.

Primärschlüssel Attribute
Partitionsschlü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 faszinierend.
Videokommentar#86751345 Content
Bei 1:05 scheint es einen Audiofehler zu geben.
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 ihn nicht sehen.
VideoStats ViewCount
45

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

Da Zähler aktualisiert werden können, ohne dass die gesamte Zeile aktualisiert werden muss, müssen Sie sie auch nicht aufteilen. Sie müssen auch keine UploadDate-Spalte verwenden oder einen umgekehrten Zeitstempel berechnen und diesen Sortierschlüssel festlegen, da Bigtable-Zeitstempel automatisch die Kommentare in umgekehrter chronologischer Reihenfolge anzeigen. 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 transaktional entfernen.

Da die Spalten in Bigtable lexikografisch geordnet sind, können Sie die Spalten als Optimierung so umbenennen, dass ein schneller Scanvorgang möglich ist – von Videoeigenschaften bis zu den obersten N neuesten Kommentaren – in einer einzelnen Leseanfrage. Dies ist das, was Sie tun sollten, wenn das Video geladen ist. Später können Sie durch die restlichen Kommentare blättern, während der Betrachter scrollt.

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 faszinierend. @ 2023-09-10T19:01:15
Um 1:05 scheint es eine Audiostörung zu geben. @ 10.09.2023, 16: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 ihn nicht sehen. @2023-10-12T07:08:51

Designmuster für Adjacency-Liste

Betrachten Sie eine etwas andere Version dieses Designs, die DynamoDB häufig als Designmuster für Adacency-Listen bezeichnet.

Primärschlüssel Attribute
Partitionsschlü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":"13 Xyz St..."}
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":"Bob...",
"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 spaltenorientiertes Muster verwenden und diese IDs in Bigtable als separate Spalten definieren. Die Vorteile ähneln dem vorherigen Beispiel.

Rechnung Zahlung
Zeilenschlüssel Details 0680 0789
0123 {"discount": 0.10,
"sales_tax_usd":"8",
"due_date":"2023-10-03.."}
@ 2023-09-10T15: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 konnten, kann das spaltenorientierte Modell von Bigtable mit dem richtigen Schemadesign sehr leistungsstark sein und viele Anwendungsfälle liefern, für die teure Transaktionen über mehrere Zeilen, eine sekundäre Indexierung oder eine Kaskadierung bei Löschvorgängen in anderen Datenbanken erforderlich sind.

Nächste Schritte