Bigtable für DynamoDB-Nutzer
Dieses Dokument richtet sich an DynamoDB-Entwickler und -Datenbanken. Administratoren, die Daten migrieren oder Anwendungen zur Verwendung mit Bigtable als Datenspeicher. 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 werden Highlights die Ähnlichkeiten und Unterschiede zwischen den beiden Datenbanksystemen.
Steuerungsebene
In DynamoDB und Bigtable können Sie mit der Steuerungsebene 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 stellen Sie Ihre Lese- und Schreibanfrageeinheiten bereit, wählen Ihre Regionen und die Replikation aus und verwalten Sicherungen. 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 Steuerungsebene für DynamoDB und Bigtable.
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 Replikationen
und Verbindungsrouting. Replikationsrichtlinien werden festgelegt an der
Instanzebene. Cluster: Eine Gruppe von Knoten in derselben geografischen Google Cloud-Zone, die aus Gründen der Latenz und der Replikation idealerweise mit Ihrem Anwendungsserver zusammenliegen. Die Kapazität wird verwaltet von und die Anzahl der Knoten in jedem Cluster anpassen. 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 Rechenressource, die für
das Lesen und Schreiben von Daten. 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 abhängig von der Kombination Ihrer
Latenzziele,
Anzahl der Anfragen und Nutzlastgröße. SSD-Knoten bieten denselben Durchsatz für Lese- und Schreibvorgänge, im Gegensatz zum deutlichen Unterschied zwischen RCU und WCU. Weitere Informationen Siehe Leistung bei typischer Arbeitslast |
Partition : Ein Block von zusammenhängenden Zeilen, unterstützt durch
Solid State Drives (SSDs), die zusammen mit Knoten platziert sind. Jede Partition unterliegt einem festen Limit von 1.000 WCUs, 3.000 RCUs, und 10 GB Daten. |
Tablet: Ein Block von zusammenhängenden Zeilen mit dem
Speichermedium Ihrer Wahl (SSD oder HDD) Tabellen werden in Tabellenreihen aufgeteilt, um die Arbeitslast auszugleichen. Tablets sind nicht auf Knoten in Bigtable gespeichert, sondern auf den verteilten Dateisystem, das eine schnelle Umverteilung von Daten ermöglicht bei der Skalierung und erhöhen die Langlebigkeit, da in mehreren Kopien. |
Globale Tabellen: Eine Möglichkeit, die Verfügbarkeit und Langlebigkeit Ihrer Daten zu 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 wie ein Client-API-Aufruf an die entsprechenden Cluster in der Instanz. 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 Ausfall.
- 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 auf einem Gerät implementieren müssen und auf die Replikation auf Bereitstellungscluster angewiesen sind.
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 Daten automatisch clusterübergreifend in einem Multi-primäre Topologie, d. h., Sie können in jedem Cluster lesen und schreiben. Die Bigtable-Replikation ist letztendlich konsistent. Weitere Informationen finden Sie unter die Replikation – Übersicht
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 und ihre Verfügbarkeit aufgeführt in DynamoDB und Bigtable.
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 | Schließlich 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 | Globale Tabelle mit einem Tabellenreplikat in jeder ausgewählten Tabelle erstellen
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, mit dem Stream das sowohl das neue als auch das alte Bild des Artikels enthält. 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 clusterübergreifend 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, der an das nächstgelegene geografische Replikat weitergeleitet wird. 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) beträgt
Replikaten synchronisiert. Die Lesekapazität in replizierten Lesekapazitätseinheiten (R-RCU) beträgt pro Replikat. |
Sie können Cluster unabhängig skalieren, indem Sie Knoten in jeden replizierten Cluster nach Bedarf. |
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 fallen keine Kosten für die Netzwerkreplikation an zonenübergreifend. Kosten fallen an, wenn die Replikation regions- oder kontinentübergreifend erfolgt. |
SLA | 99,999 % | 99,999 % |
Datenebene
In der folgenden Tabelle werden Datenmodellkonzepte für DynamoDB verglichen und Bigtable. 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 sich anhand ihres Primärschlüssels 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 jedes Element jedoch auf 400 KB begrenzt ist, gilt für einen Artikel mit nur einem Attribut das Attribut bis zu 400 KB abzüglich der vom Attributnamen. | Spaltenqualifizierer : Die eindeutige Kennung innerhalb einer
Spaltenfamilie für eine Spalte. Die vollständige Kennzeichnung einer Spalte wird als „Spaltenfamilie:Spaltenqualifizierer“ ausgedrückt. Spaltenqualifizierer sind
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. Dies kann ein Partitionierungsschlüssel oder ein zusammengesetzter Schlüssel sein. Partitionierungsschlüssel: Ein einfacher Primärschlüssel, der aus einem Schlüssel . 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 bestimmt innerhalb einer Partition. 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 kann das Verhalten der Daten übermittelt werden. entspricht dem Sortierschlüssel von DynamoDB. Kompositschlüssel können mit zusammenhängenden Zeilenschlüsseln und Spaltenqualifizierern erstellt werden. Weitere Informationen finden Sie im Beispiel zur Schemaübersetzung unter „Schema“ Design dieses Dokuments. |
Lebensdauer: Mithilfe von Zeitstempeln pro Element wird festgelegt, wann ein Element nicht mehr benötigt wird. Nach dem Datum und der Uhrzeit der angegebenen wird das Element aus der Tabelle gelöscht, ohne Durchsatz für Schreibvorgänge. | Garbage Collection : Mit Zeitstempeln pro Zelle wird bestimmt, wenn ein Artikel 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 Vorgängen auf der Datenebene können Sie Erstellen, Lesen, Aktualisieren und Löschen (CRUD) ausführen Aktionen für Daten in einer Tabelle. 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
|
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 für die Tabellenspalten oder Datentypen eine tabelleweite Erzwingung erforderlich ist. Ebenso kann sich eine bestimmte Spalte oder ein bestimmter Attributdatentyp von einer Zeile unterscheiden. oder Element zu einem anderen Element. 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 Byte und erwartet den Clientcode um Typ und Codierung zu erfahren, damit der Client die Antworten korrekt parsen kann. Hiervon ausgenommen sind inkrementieren Operationen, 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 : Wird als Datentyp zurückgegeben. deskriptor-Token in der Serverantwort. | Byte : Byte werden in die gewünschten Typen im Client umgewandelt.
. Increment interpretiert den Wert als vorzeichenbehaftete 64-Bit-Big-Endian-Ganzzahl. |
Menge: Eine unsortierte Sammlung eindeutiger Elemente. | Spaltenfamilie : Sie können Spaltenqualifizierer wie festgelegt verwenden. Mitgliedsnamen und geben Sie für jedes Mitglied ein einzelnes 0-Byte als Zelle Wert. Satzmitglieder werden innerhalb ihrer Spaltenfamilie lexikografisch 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 als Wert. Zuordnungsschlüssel lexikografisch sortiert werden. |
Liste : Eine sortierte Sammlung von Elementen. | Spaltenqualifizierer Verwenden Sie den Einfügen-Zeitstempel, um das Äquivalent von list_append zu erhalten. Umgekehrt zum Einfügen des Zeitstempels für das Präfix. |
Schemadesign
Eine wichtige Überlegung beim Schemadesign ist die Speicherung der Daten. Zu den wichtigsten Unterschieden zwischen Bigtable und DynamoDB gehört die Verarbeitung der folgenden Elemente:
- Aktualisierungen für einzelne Werte
- Datensortierung
- Datenversionsverwaltung
- Speicherung großer Werte
Aktualisierung 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 separaten Zeilen, auch wenn sie logisch in dieselbe Zeile gehören,
anderen Spalten.
Bigtable kann eine Zelle genauso effizient aktualisieren, unabhängig davon, ob es sich um die nur eine Spalte in einer bestimmten Zeile oder eine aus vielen Tausend. Weitere Informationen finden Sie unter Einfache Schreibvorgänge.
Datensortierung
DynamoDB-Hashes und zufällig verteilte Partitionsschlüssel, während Bigtable speichert Zeilen in lexikografischer Reihenfolge nach Zeilenschlüssel und jegliche Hash-Technologie bleibt dem Nutzer überlassen.
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 insbesondere bei Anwendungsfällen mit einer Zeitdimension.
Umgang mit dieser Art von Zugriffsmuster – Scans, die bereichsübergreifend arbeiten Grenzen – erfordert einen sekundären Index in DynamoDB, aber Bigtable verarbeitet sie, ohne dass ein sekundärer Index erforderlich ist. 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, Schreibfragmentierung, bei der Schreibvorgänge zufällig auf mehrere logische Partitionen aufgeteilt werden Schlüsselwerten.
Um dieses Designmuster anzuwenden, müssen Sie eine Zufallszahl aus (z. B. 1 bis 10) und diese Zahl dann als logische Partition . 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 und den neuesten Zeitstempel ist immer der Standardwert für eine gegebene Spalte. Ein häufiger Anwendungsfall für ist die Versionsverwaltung, also das Schreiben einer neuen Zelle in eine Spalte, die von vorherigen Versionen der Daten für diese Zeile und Spalte durch ihre Zeitstempel.
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 Null, z. B. v0_
, am Anfang
des Sortierschlüssels und eine weitere Kopie mit dem Versionsnummernpräfix 1, 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
Anwendungsseitige Logik zu verwalten,
macht aber auch Datenschreibvorgänge sehr kostspielig und
langsam, da jeder Schreibvorgang einen Lesevorgang des vorherigen Werts plus zwei erfordert.
schreibt.
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 entwerfen, dass relevante Elemente unter einem gemeinsamen Zeilenschlüssel gruppiert werden. Für eine Ein Beispiel für diesen Ansatz finden Sie unter Design einer einzelnen Tabelle. Muster.
Große Werte speichern
Da ein DynamoDB-Element, das einer Bigtable-Zeile entspricht, auf 400 KB begrenzt ist, muss der Wert entweder geteilt werden, oder die Speicherung in anderen Medien, S3: Beide Ansätze erhöhen die Komplexität Ihrer Anwendung. Im Gegensatz dazu Bigtable-Zelle kann bis zu 100 MB speichern und eine Bigtable- kann 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 wichtigsten Unterschiede im Schemadesign.
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 | Filzhut#brandA | Hergestellt 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 |
hats#fedoras#brandA | Hergestellt aus hochwertiger Wolle... | 30 | https://storage… |
hats#fedoras#brandB | 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 | 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 Partitionierungsschlüssel die eindeutige ID für ein Video, die
werden alle Attribute im Zusammenhang mit diesem Video gruppiert, um einen schnelleren Zugriff zu ermöglichen. Angegeben
Aufgrund der Größenbeschränkungen von DynamoDB ist es nicht möglich,
in einer einzelnen Zeile. 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 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 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…"} | |
Videokommentar#98765481 | Inhalt | |||
Das gefällt mir wirklich gut. Spezialeffekte sind erstaunlich. | ||||
Videokommentar#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…"} | |
Videokommentar#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 eine viel größere als DynamoDB-Elemente und kann eine große Anzahl von Kommentaren verarbeiten. Bis wenn ein Video Millionen von Kommentaren erhält, kannst du eine automatische Datenerhebungsrichtlinie, um nur einen festen Anzahl der neuesten Kommentare
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 kein UploadDate oder einen umgekehrten Zeitstempel berechnen und diesen als Sortierschlüssel festlegen, weil Bigtable-Zeitstempel die umgekehrte chronologische automatisch sortierte Kommentare. Dies vereinfacht das Schema erheblich und ein Video entfernt wird, können Sie die Zeile des Videos alle Kommentare in einer einzigen Anforderung.
Da Spalten in Bigtable geordnet sind, lexikografisch können Sie die Spalten zur Optimierung so umbenennen, ermöglicht einen schnellen Bereichsscan – von Videoeigenschaften bis zu den N in einer einzigen Leseanforderung zusammenfassen. Video wird geladen. Später kannst du dann durch die restlichen Kommentare blättern wenn 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 wirklich gut. Spezialeffekte sind toll. @
2023-09-10T19:01:15 Bei 1:05 Uhr ist ein Audiofehler aufgetreten. @ 2023-09-10T16: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 . @2023-10-12T07:08:51 |
Designmuster der Adjacency-Liste
Betrachten Sie eine etwas andere Version dieses Designs, die DynamoDB häufig wird auch als das Benachbarungslisten-Designmuster bezeichnet.
Primärschlüssel | Attribute | |||
---|---|---|---|---|
Partitionsschlüssel | Sortierschlüssel | DateCreated | Details | |
Invoice-0123 | Rechnung-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 ..."} |
||
Rechnung-0124 | Rechnung-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 voneinander trennen Spalten in Bigtable mit ähnlichen Vorteilen 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 Bigtable-Modell mit breiter Spalte mit dem richtigen Schemadesign sehr leistungsfähig sein und viele Anwendungsfälle bieten, 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
- Erfahren Sie mehr über das Bigtable-Schemadesign.
- Erfahren Sie mehr über den Bigtable-Emulator.
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center