Bigtable für DynamoDB-Nutzer

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

Bigtable und DynamoDB sind verteilte Schlüssel/Wert-Speicher, die Millionen von Abfragen pro Sekunde (QPS) unterstützen, Speicher für eine Skalierung bis zu Petabyte an Daten bieten und Knotenausfälle tolerieren.

Die Feature-Sets dieser Datenbankdienste sind ähnlich, ihre zugrunde liegenden Architekturen und Interaktionsdetails unterscheiden sich jedoch grundlegend. Das ist wichtig zu wissen, bevor Sie mit einer Migration beginnen. In diesem Dokument wird auf die Ähnlichkeiten und Unterschiede zwischen den beiden Datenbanksystemen ausführlich eingegangen.

Steuerungsebene

In DynamoDB und Bigtable können Sie mit der Steuerebene Ihre Kapazität konfigurieren und Ressourcen einrichten und verwalten. DynamoDB ist ein serverloses Produkt und die höchste Interaktionsebene mit DynamoDB ist die Tabellenebene. Im Modus mit bereitgestellter Kapazität können Sie Ihre Lese- und Schreibanfrageeinheiten bereitstellen, Regionen und Replikation auswählen und Sicherungen verwalten. Bigtable ist kein serverloses Produkt. Sie müssen eine Instanz mit einem oder mehreren Clustern erstellen, deren Kapazität von der Anzahl der Knoten bestimmt wird. Weitere Informationen zu diesen Ressourcen finden Sie unter Instanzen, Cluster und Knoten.

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

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

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

Tabelle: Eine logische Struktur von Werten, die durch den Zeilenschlüssel indexiert sind.

Sicherungen werden auf Tabellenebene gesteuert.
Lesekapazitätseinheit (Read Capacity Unit, RCU) und Schreibkapazitätseinheit (Write Capacity Unit, WCU): Einheiten, die Lese- oder Schreibvorgänge pro Sekunde mit fester Nutzlastgröße ermöglichen. Für jeden Vorgang mit einer größeren Nutzlast 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 dem Update – auch wenn das Update nur einen Teil der Attribute des Elements betrifft.		 Knoten: Eine virtuelle Computing-Ressource, die für das Lesen und Schreiben von Daten verantwortlich ist. Die Anzahl der Knoten eines Clusters wirkt sich auf die Durchsatzlimits für Lese-, Schreib- und Scanvorgänge aus. Sie können die Anzahl der Knoten je nach 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 zum deutlichen Unterschied zwischen RCU und WCU. Weitere Informationen finden Sie unter Leistung bei typischer Arbeitslast.
Partition: Ein Block zusammenhängender Zeilen, der von SSDs (Solid State Drives) unterstützt wird, die sich an denselben Standorten wie die Knoten befinden.

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

Tabellen werden in Tabellenreihen aufgeteilt, um die Arbeitslast auszugleichen. Tabellenzeilen werden nicht auf Knoten in Bigtable, sondern im verteilten Dateisystem von Google gespeichert. Dies ermöglicht eine schnelle Neuverteilung von Daten bei der Skalierung und bietet zusätzliche Zuverlässigkeit durch die Verwaltung mehrerer Kopien.
Globale Tabellen: Mit globalen Tabellen können Sie die Verfügbarkeit und Langlebigkeit Ihrer Daten erhöhen, indem Datenänderungen automatisch auf mehrere Regionen angewendet werden. Replikation: Möglichkeit, die Verfügbarkeit und Langlebigkeit von Daten zu erhöhen, indem Datenänderungen automatisch auf mehrere Regionen oder Zonen innerhalb derselben Region übertragen werden.
Nicht zutreffend (N/A) Anwendungsprofil: Einstellungen, die festlegen, wie Bigtable einen Client-API-Aufruf an den entsprechenden Cluster in der Instanz weiterleiten soll. Außerdem können Sie ein App-Profil als Tag verwenden, um Messwerte für die Attribution zu segmentieren.

Geografische Replikation

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

  • Hochverfügbarkeit für die Geschäftskontinuität bei zonalen oder regionalen Ausfällen.
  • Ihre Dienstdaten in der Nähe von Endnutzern platzieren, um eine Bereitstellung mit geringer Latenz zu ermöglichen, unabhängig davon, wo sich die Nutzer befinden.
  • Arbeitslastisolierung, wenn Sie eine Batcharbeitslast in einem Cluster implementieren und die Replikation für die Bereitstellung von Clustern nutzen möchten.

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. Weitere Informationen finden Sie unter Regionen und Zonen.

Bigtable repliziert Daten automatisch in einer Multi-Primär-Topologie zwischen Clustern. Das bedeutet, dass Sie in jedem Cluster lesen und schreiben können. Die Bigtable-Replikation ist letztendlich konsistent. Weitere Informationen finden Sie im Hilfeartikel Replikation.

DynamoDB bietet globale Tabellen, um die Replikation von Tabellen über mehrere Regionen hinweg zu unterstützen. Globale Tabellen haben mehrere Primärschlüssel und werden automatisch über Regionen hinweg repliziert. Die Replikation ist letztendlich konsistent.

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

Attribut DynamoDB Bigtable
Replikation mit mehreren primären Knoten Ja.

Sie können jede globale Tabelle lesen und in sie schreiben.		 Ja.

Sie können in jedem Bigtable-Cluster lesen und schreiben.
Konsistenzmodell Letztendlich konsistent.

Read-Your-Writes-Konsistenz auf regionaler Ebene für globale Tabellen.		 Letztendlich konsistent.

Read-Your-Writes-Konsistenz auf Clusterebene für alle Tabellen, sofern Sie sowohl Lese- als auch Schreibvorgänge an denselben Cluster senden.
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 Repliken hinweg durch Umwandlung einer Tabelle in eine globale Tabelle.

Für die Tabellen müssen DynamoDB-Streams aktiviert sein. Der Stream muss sowohl die neuen als auch die alten Bilder des Artikels enthalten.

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

Zonale Ebene.

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

Bei einem Fehler wird mithilfe benutzerdefinierter Geschäftslogik festgelegt, wann Anfragen an andere Regionen weitergeleitet werden.		 Verwenden Sie Anwendungsprofile, um Richtlinien für das Cluster-Traffic-Routing zu konfigurieren.

Mit Multi-Cluster-Routing Traffic automatisch an den nächsten intakten Cluster weiterleiten.

Bei einem Ausfall unterstützt Bigtable den automatischen Failover zwischen Clustern für HA.
Skalierung Die Schreibkapazität in replizierten Schreibanfrageeinheiten (R-WRU) wird zwischen den Replikaten synchronisiert.

Die Lesekapazität in replizierten Lesekapazitätseinheiten (R-RCU) wird pro Replikat angegeben.		 Sie können Cluster unabhängig skalieren, indem Sie jedem replizierten Cluster nach Bedarf Knoten hinzufügen oder daraus entfernen.
Cost R-WRUs kosten 50% mehr als normale WRUs. Ihnen werden die Knoten und der Speicherplatz jedes Clusters in Rechnung gestellt.
Für die regionale Replikation zwischen Zonen fallen keine Netzwerkreplikationskosten an.
Kosten fallen an, wenn die Replikation regions- oder kontinentübergreifend erfolgt.
SLA 99,999 % 99,999 %

Datenebene

In der folgenden Tabelle werden die Datenmodellkonzepte für DynamoDB und Bigtable verglichen. In jeder Zeile der Tabelle werden analoge Funktionen beschrieben. Ein Element in DynamoDB ähnelt beispielsweise einer Zeile in Bigtable.

DynamoDB Bigtable
Element: Eine Gruppe von Attributen, die sich durch ihren Primärschlüssel eindeutig von allen anderen Elementen unterscheiden lässt. Die maximale 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, in dem Spalten gruppiert werden.
Attribut: Eine Gruppierung aus einem Namen und einem Wert. Ein Attributwert kann ein Skalar-, Satz- oder Dokumenttyp sein. Die Attributgröße selbst ist nicht explizit begrenzt. Da jeder Artikel jedoch auf 400 KB begrenzt ist, kann das Attribut eines Artikels mit nur einem Attribut bis zu 400 KB minus der Größe des Attributnamens betragen. Spaltenqualifizierer: Die eindeutige Kennung einer Spalte innerhalb einer Spaltenfamilie. Die vollständige Kennzeichnung einer Spalte wird als „Spaltenfamilie:Spaltenqualifizierer“ ausgedrückt. 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 Kennung für ein Element in einer Tabelle. Es kann sich um einen Partitionsschlüssel oder einen zusammengesetzten Schlüssel handeln.

Partitionsschlüssel: Ein einfacher Primärschlüssel, der aus einem Attribut besteht. Damit wird die physische Partition festgelegt, in der sich der Artikel 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 Eigenschaften besteht, dem Partitionsschlüssel und einem Sortierschlüssel oder Bereichsattribut.		 Zeilenschlüssel: Eine eindeutige Kennung für ein Element in einer Tabelle. Wird in der Regel durch eine Konkatenierung von Werten und Trennzeichen dargestellt. Die maximal zulässige Größe beträgt 4 KB.

Mit Spaltenqualifizierern können Sie ein Verhalten erzielen, das dem des Sortierschlüssels von DynamoDB entspricht.

Kompositschlüssel können mit zusammenhängenden Zeilenschlüsseln und Spaltenqualifizierern erstellt werden.

Weitere Informationen finden Sie im Beispiel für die Schemaübersetzung im Abschnitt zum Schemadesign dieses Dokuments.
Lebensdauer : Mithilfe von Zeitstempeln pro Element wird festgelegt, wann ein Element nicht mehr benötigt wird. Nach dem Datum und der Uhrzeit des angegebenen Zeitstempels wird der Artikel aus der Tabelle gelöscht, ohne dass der Schreibdurchsatz beeinträchtigt 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 namens „Verdichtung“ gelöscht. Richtlinien für die automatische Speicherbereinigung werden auf der Ebene der Spaltenfamilie festgelegt. Elemente können nicht nur anhand ihres Alters, sondern auch anhand der Anzahl der Versionen gelöscht werden, die der Nutzer beibehalten möchte. Sie müssen bei der Festlegung der Größe Ihrer Cluster keine Kapazität für die Komprimierung berücksichtigen.

Operations-Suite

Mit Dataplane-Vorgängen können Sie CRUD-Vorgänge (Erstellen, Lesen, Aktualisieren und Löschen) für Daten in einer Tabelle ausführen. In der folgenden Tabelle werden ähnliche Datenebenen-Vorgä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, Rückwärtssuche)
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 zum Zeitpunkt der Datenaufnahme definiert werden, ohne dass es eine tabellenweite Erzwingung für das Vorhandensein von Spalten oder Datentypen gibt. Ebenso kann sich der Datentyp einer bestimmten Spalte oder eines bestimmten Attributs von Zeile zu Zeile oder von Element zu Element unterscheiden. Die DynamoDB- und Bigtable-APIs gehen jedoch unterschiedlich mit Datentypen um.

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

Bigtable behandelt alles als Bytes und erwartet, dass der Clientcode den Typ und die Codierung kennt, damit der Client die Antworten richtig parsen kann. Eine Ausnahme bilden Inkrementierungsvorgänge, bei denen die Werte als 64‑Bit-Big-Endian-Ganzzahlen mit Vorzeichen interpretiert werden.

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

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

Increment interpretiert den Wert als vorzeichenbehaftete 64-Bit-Big-Endian-Ganzzahl.
Menge: Eine unsortierte Sammlung eindeutiger Elemente. Spaltenfamilie : Sie können Spaltenqualifizierer als Namen von Satzelementen verwenden und für jeden ein einzelnes 0-Byte als Zellenwert angeben. Die Mitglieder eines Sets werden innerhalb ihrer Spaltenfamilie lexikografisch sortiert.
Map: Eine unsortierte Sammlung von Schlüssel/Wert-Paaren mit eindeutigen Schlüsseln. Spaltenfamilie
Verwenden Sie den Spaltenqualifizierer als Zuordnungsschlüssel und den Zellenwert als Wert. Kartenschlüssel werden lexikalisch sortiert.
Liste : Eine sortierte Sammlung von Elementen. Spaltenqualifizierer
Mit dem Insert-Zeitstempel können Sie das Verhalten von „list_append“ erzielen, also das Gegenteil des Insert-Zeitstempels für „prepend“.

Schemadesign

Ein wichtiger Aspekt beim Schemadesign ist die Speicherung der Daten. Zu den wichtigsten Unterschieden zwischen Bigtable und DynamoDB gehört die Verarbeitung der folgenden Elemente:

  • Aktualisierungen einzelner Werte
  • Datensortierung
  • Datenversionierung
  • Speichern großer Werte

Aktualisierungen einzelner Werte

UpdateItem-Vorgänge in DynamoDB belegen die Schreibkapazität für die größere der beiden Artikelgrößen „vorher“ und „nachher“, auch wenn das Update nur einen Teil der Artikelattribute betrifft. Das bedeutet, dass Sie in DynamoDB häufig aktualisierte Spalten in separate Zeilen einfügen können, 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 von vielen Tausenden handelt. Weitere Informationen finden Sie unter Einfache Schreibvorgänge.

Datensortierung

DynamoDB hasht und verteilt Partitionsschlüssel nach dem Zufallsprinzip, während Bigtable Zeilen in lexikalischer Reihenfolge nach dem Zeilenschlüssel speichert und das Hashing dem Nutzer überlässt.

Die Zufallsschlüsselverteilung ist nicht für alle Zugriffsmuster optimal. Dadurch wird das Risiko von Hot-Row-Bereichen reduziert, aber Zugriffsmuster, die Scans über Partitionsgrenzen hinweg umfassen, werden teuer und ineffizient. Diese unbegrenzten Scans sind häufig, insbesondere bei Anwendungsfällen mit einer Zeitdimension.

Für die Verarbeitung dieses Zugriffsmusters – Scans, die Partitionsgrenzen überschreiten – ist in DynamoDB ein sekundärer Index erforderlich. In Bigtable ist das jedoch ohne sekundären Index möglich. In DynamoDB sind Abfrage- und Scanvorgänge ebenfalls auf 1 MB gescannte Daten beschränkt. Über dieses Limit hinaus ist eine Paginierung erforderlich. Für Bigtable gibt es keine solche Beschränkung.

Trotz der zufällig verteilten Partitionsschlüssel kann es in DynamoDB Hot-Partitionen geben, 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 das Schreiben per Sharding, bei dem Schreibvorgänge zufällig auf mehrere Schlüsselwerte der logischen Partition 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 Partitionsschlüssel zufällig generieren, werden die Schreibvorgänge in die Tabelle gleichmäßig auf alle Partitionsschlüsselwerte verteilt.

In Bigtable wird dieses Verfahren als Schlüsselsalzen bezeichnet. Es kann eine effektive Methode sein, um Hot-Tablets zu vermeiden.

Datenversionierung

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 Versionierung: In eine Spalte wird eine neue Zelle geschrieben, die sich durch ihren Zeitstempel von früheren Versionen der Daten für diese Zeile und Spalte unterscheidet.

DynamoDB bietet kein solches Konzept und erfordert komplexe Schemadesigns, um die Versionsverwaltung zu unterstützen. Dabei werden von jedem Element zwei Kopien erstellt: eine Kopie mit dem Präfix „0“ für die Versionsnummer, z. B. v0_, am Anfang des Sortierschlüssels und eine weitere Kopie mit dem Präfix „1“ für die Versionsnummer, z. B. v1_. Jedes Mal, wenn das Element aktualisiert wird, 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 0. So kann die neueste Version eines Artikels mit dem Präfix „0“ gefunden werden. Diese Strategie erfordert nicht nur die Pflege von anbieterseitiger Logik, sondern macht auch Datenschreibvorgänge sehr teuer und langsam, da für jede Schreiboperation der vorherige Wert gelesen und zwei Schreibvorgänge ausgeführt werden müssen.

Transaktionen mit mehreren Zeilen im Vergleich zu einer großen Zeilenkapazität

Bigtable unterstützt keine mehrzeiligen Transaktionen. Da Sie hier jedoch Zeilen speichern können, die viel größer sind als Elemente in DynamoDB, können Sie die gewünschte Transaktionalität oft erreichen, indem Sie Ihre Schemas so gestalten, dass relevante Elemente unter einem gemeinsamen Zeilenschlüssel gruppiert werden. Ein Beispiel für diesen Ansatz 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, müssen große Werte entweder auf mehrere Elemente aufgeteilt oder in anderen Medien wie S3 gespeichert werden. Beide Ansätze erhöhen die Komplexität Ihrer Anwendung. Eine Bigtable-Zelle kann dagegen bis zu 100 MB und eine Bigtable-Zeile bis zu 256 MB speichern.

Beispiele für Schemaübersetzungen

In den Beispielen in diesem Abschnitt werden Schemas von DynamoDB in Bigtable übertragen. Dabei werden die wichtigsten Unterschiede beim Schemadesign berücksichtigt.

Grundlegende Schemas migrieren

Produktkataloge sind ein gutes Beispiel für das grundlegende Schlüssel/Wert-Muster. Unten sehen Sie, wie ein solches Schema in DynamoDB aussehen könnte.

Primärschlüssel Attribute
Partitionsschlüssel Sortierschlüssel Beschreibung Preis Miniaturansicht
Hüte fedoras#brandA Aus hochwertiger Wolle… 30 https://storage…
Hüte fedoras#brandB Robustes, wasserabweisendes Canvas, das.. 28 https://storage…
Hüte newsboy#brandB Verleihen Sie Ihrem Alltagslook einen Hauch von Vintage-Charme. 25 https://storage…
Schuhe sneakers#brandA Mit diesen Produkten können Sie stilvoll und bequem unterwegs sein: 40 https://storage…
Schuhe sneakers#brandB Klassische Elemente mit modernen Materialien… 50 https://storage…

Für diese Tabelle ist die Zuordnung von DynamoDB zu Bigtable ganz einfach: Sie wandeln den zusammengesetzten Primärschlüssel von DynamoDB in einen zusammengesetzten Bigtable-Zeilenschlüssel um. Sie erstellen eine Spaltenfamilie (SKU), die dieselben Spalten enthält.

SKU
Zeilenschlüssel Beschreibung Preis Miniaturansicht
hüte#filzhüte#markeA Aus hochwertiger Wolle… 30 https://storage…
hüte#fedoras#markeB Robustes, wasserabweisendes Canvas, das.. 28 https://storage…
hüte#newsboy#markeB Verleihen Sie Ihrem Alltagslook einen Hauch von Vintage-Charme. 25 https://storage…
schuhe#sneakers#markeA Mit diesen Produkten können Sie stilvoll und bequem unterwegs sein: 40 https://storage…
schuhe#sneaker#markeB Klassische Elemente mit modernen Materialien… 50 https://storage…

Designmuster für eine einzelne Tabelle

Bei einem Designmuster mit einer einzelnen Tabelle werden mehrere Tabellen in einer relationalen Datenbank in einer einzigen Tabelle in DynamoDB zusammengeführt. Sie können wie im vorherigen Beispiel vorgehen und dieses Schema unverändert in Bigtable duplizieren. Es ist jedoch besser, die Probleme des Schemas im Prozess anzugehen.

In diesem Schema enthält der Partitionsschlüssel die eindeutige ID für ein Video. So können alle zugehörigen Attribute für einen schnelleren Zugriff zusammen gespeichert werden. Aufgrund der Einschränkungen der Artikelgröße in DynamoDB können Sie nicht eine 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 in der Partition in umgekehrter chronologischer Reihenfolge in eine separate Zeile zu verschieben.

Angenommen, dieses Video hat 500 Kommentare und der Inhaber möchte es 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 stellen, wobei Sie jede durchgehen. DynamoDB unterstützt Transaktionen mit mehreren Zeilen. Diese Löschanfrage ist jedoch zu groß, um in einer einzelnen Transaktion ausgeführt zu werden.

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…"}
VideoComment#98765481 Inhalt
Das gefällt mir sehr gut. Spezialeffekte sind erstaunlich.
VideoComment#86751345 Inhalt
Bei 1:05 gibt es einen Audiofehler.
VideoStatsLikes Anzahl
3
VideoStatsViews Anzahl
156
0124 Video 2023-09-10T17:03:21 {"480": "https://storage…", "720": "https://storage…"}
VideoComment#97531849 Inhalt
Ich habe das mit allen meinen Freunden geteilt.
VideoComment#87616471 Inhalt
Der Stil erinnert mich an einen Filmregisseur, aber ich kann mir nicht genau vorstellen, welchen.
VideoStats ViewCount
45

Ändern Sie dieses Schema während der Migration, um Ihren Code zu vereinfachen und Datenabfragen schneller und kostengünstiger zu machen. 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 Sammlung von Junk-Dateien festlegen, damit nur eine bestimmte Anzahl der neuesten Kommentare gespeichert wird.

Da Zähler ohne den Overhead der Aktualisierung der gesamten Zeile aktualisiert werden können, müssen Sie sie auch nicht aufteilen. Sie müssen auch keine Spalte „UploadDate“ verwenden oder einen umgekehrten Zeitstempel berechnen und als Sortierschlüssel festlegen, da Sie mit Bigtable-Zeitstempeln automatisch die Kommentare in umgekehrter chronologischer Reihenfolge erhalten. Das vereinfacht das Schema erheblich. Wenn ein Video entfernt wird, kannst du die Zeile des Videos einschließlich aller Kommentare in einer einzigen Transaktion entfernen.

Da Spalten in Bigtable lexikalisch sortiert sind, kannst du sie zur Optimierung so umbenennen, dass ein schneller Bereichsabgleich – von Videoeigenschaften bis zu den N aktuellsten Kommentaren – in einer einzigen Leseanfrage möglich ist. Das ist das, was du beim Laden des Videos tun möchtest. Später kannst du dann durch die restlichen Kommentare blättern, während der Zuschauer 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 gut. Spezialeffekte sind erstaunlich. @ 2023-09-10T19:01:15
Bei 1:05 gibt es einen Audiofehler. @ 2023-09-10T16:30:42
0124 {"480": "https://storage…", "720":"https://storage…"} @2023-09-10T17:03:21 45 Der Stil erinnert mich an einen Filmregisseur, aber ich kann mir nicht genau vorstellen, welchen. @2023-10-12T07:08:51

Designmuster für die Nachbarschaftsliste

Sehen wir uns eine etwas andere Version dieses Designs an, die in DynamoDB oft als das Designmuster der Adjazenzliste bezeichnet wird.

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 Zahlungs-IDs. Sie können also ein anderes Muster für breite Spalten verwenden und diese IDs in Bigtable in separate Spalten einfügen. Die Vorteile ähneln denen im 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 können, kann das Wide Column-Modell von Bigtable mit dem richtigen Schemadesign sehr leistungsfähig sein und viele Anwendungsfälle abdecken, für die in anderen Datenbanken teure Transaktionen mit mehreren Zeilen, sekundäre Indexierung oder das Löschen von Kaskaden erforderlich wären.

Nächste Schritte