Best Practices für Schemadesign

Diese Seite enthält Informationen zum Bigtable-Schemadesign. Bevor Sie sollten Sie sich bereits mit dem Überblick über Bigtable. Folgende Themen werden behandelt: Seite:

  • Allgemeine Konzepte: Grundlegende Konzepte, die Sie beim Erstellen Ihres Schemas berücksichtigen sollten.
  • Best Practices: Gestaltungsrichtlinien, die für die meisten Anwendungsfälle gelten, aufgeschlüsselt nach Tabellenkomponente.
  • Spezielle Anwendungsfälle: Empfehlungen für bestimmte Anwendungsfälle und Datenmuster.

Allgemeine Konzepte

Das Entwerfen eines Bigtable-Schemas unterscheidet sich vom Entwerfen eines Schemas für eine relationale Datenbank. Ein Bigtable-Schema ist definiert durch Anwendungslogik und nicht durch ein Schemadefinitionsobjekt oder eine Schemadefinition. Sie können Spaltenfamilien zu einer Tabelle hinzufügen, wenn Sie die Tabelle erstellen oder aktualisieren, aber Spalten Zeilenschlüsselmuster werden durch die Daten definiert, die Sie in die Tabelle schreiben.

In Bigtable ist ein Schema ein Blueprint oder Modell einer Tabelle, einschließlich der Struktur der folgenden Tabellenkomponenten:

  • Zeilenschlüssel
  • Spaltenfamilien, einschließlich ihrer Richtlinien für die automatische Speicherbereinigung
  • Spalten

In Bigtable beruht das Schemadesign hauptsächlich auf den Abfragen, die Sie an die Tabelle senden möchten. Weil das Lesen einer Zeile Bereich ist die schnellste Möglichkeit, Ihre Bigtable-Daten verwendet werden, sollen die Empfehlungen auf dieser Seite Zeilenbereich-Lesevorgänge optimieren. In den meisten Fällen bedeutet dies, dass Sie basierend auf Zeilenschlüsselpräfixen.

Ein zweitwichtiger Aspekt ist die Vermeidung von Hotspots, um Hotspots zu vermeiden. müssen Sie Schreibmuster berücksichtigen und wie Sie den Zugriff auf einen kleinen Schlüssel in kurzer Zeit zu speichern.

Die folgenden allgemeinen Konzepte gelten für das Schemadesign von Bigtable:

  • Bigtable ist ein Schlüssel/Wert-Speicher, kein relationaler Speicher. Es unterstützt keine Joins und Transaktionen werden nur in einer einzelnen Zeile unterstützt.
  • Jede Tabelle verfügt nur über einen Index, den Zeilenschlüssel. Es gibt keine sekundären Indexe. Zeilenschlüssel dürfen jeweils nur einmal vorkommen.
  • Zeilen werden lexikografisch nach Zeilenschlüssel geordnet, vom kleinsten bis zum größten Bytestring. Zeilenschlüssel werden in Big-Endian-Bytereihenfolge sortiert (manchmal Netzwerk-Bytereihenfolge genannt), das binäre Äquivalent der alphabetischen Reihenfolge.
  • Spaltenfamilien werden nicht in einer bestimmten Reihenfolge gespeichert.
  • Spalten werden nach Spaltenfamilien gruppiert und in lexikografischer Reihenfolge innerhalb der Spaltenfamilie sortiert. Beispiel: In einer Spaltenfamilie mit dem Namen SysMonitor mit Spaltenqualifizierer von ProcessName, User, %CPU, ID, Memory, DiskRead und Priority speichert Bigtable die Spalten in folgender Reihenfolge:
SysMonitor
%CPU DiskRead ID Speicher Priorität ProcessName Nutzer
  • Der Schnittpunkt einer Zeile und Spalte kann mehrere Zellen mit Zeitstempel enthalten. Jede Zelle enthält eine eindeutige, mit Zeitstempel versehene Version der Daten für Zeile und Spalte.
  • Aggregierte Spaltenfamilien enthalten zusammengefasste Zellen. Sie können Spaltenfamilien, die nur aggregierte Zellen enthalten. Mit einer Aggregation können Sie neue Daten mit Daten zusammenführen, die sich bereits in der Zelle befinden.
  • Alle Vorgänge sind auf Zeilenebene atomar. Ein Vorgang wirkt sich entweder auf eine ganze oder gar keine Zeile.
  • Idealerweise sollten Lese- und Schreibvorgänge gleichmäßig über den gesamten Zeilenbereich einer Tabelle.
  • Bigtable-Tabellen sind "Sparse Tables". Eine Spalte belegt keinen Platz in einer Zeile, in der die Spalte nicht verwendet wird.

Best Practices

Ein gutes Schema führt zu exzellenter Leistung sowie Skalierbarkeit und ein schlechtes Schema kann zu einem System mit schwacher Leistung führen. Jeder Anwendungsfall ist anders und erfordert ein eigenes Design, für die meisten Anwendungsfälle gelten die folgenden Best Practices. Ausnahmen sind vermerkt.

In den folgenden Abschnitten werden, beginnend mit der Tabellenebene bis hinunter zur Ebene der Zeilenschlüssel, die Best Practices für den Schemaentwurf beschrieben:

Alle Tabellenelemente, insbesondere Zeilenschlüssel, sollten auf geplante Leseanfragen ausgelegt werden. Empfohlene und feste Größenlimits für alle Tabellenelemente finden Sie unter Kontingente und Limits.

Da alle Tabellen in einer Instanz auf denselben Tabellenreihen gespeichert sind, kann ein Schemadesign, das zu Heißlaufen in einer Tabelle führt, die Latenz anderer Tabellen in derselben Instanz beeinflussen. Hotspots werden dadurch verursacht, dass häufig auf einen Teil der Tabelle in einem in einem kurzen Zeitraum.

Tabellen

Speichern Sie Datasets mit ähnlichen Schemas in derselben Tabelle statt in und separaten Tabellen.

In anderen Datenbanksystemen entscheiden Sie sich möglicherweise, Daten basierend auf dem Thema und der Anzahl der Spalten in mehreren Tabellen zu speichern. In Bigtable dagegen ist es normalerweise besser, alle Daten in einer Tabelle zu speichern. Sie können eine eindeutige Zeilenschlüsselpräfix für jedes Dataset, sodass Bigtable die verwandten Daten in einem zusammenhängenden Bereich von Zeilen speichert, die Sie dann abfragen können Zeilenschlüsselpräfix.

Bigtable hat ein Limit von 1.000 Tabellen pro -Instanz erstellen. Wir raten jedoch davon ab, eine große Anzahl von Tabellen zu erstellen. aus folgenden Gründen:

  • Das Senden von Anfragen an viele verschiedene Tabellen kann den Aufwand der Backend-Verbindung erhöhen, was zu einem Anstieg der Extremwert-Latenz führt.
  • Das Erstellen weiterer Tabellen verbessert das Load-Balancing nicht und kann den Verwaltungsaufwand erhöhen.

Sie möchten vielleicht eine separate Tabelle für einen anderen Anwendungsfall, erfordert ein anderes Schema. Sie sollten jedoch keine separaten Tabellen für ähnliche Daten. Sie sollten z. B. keine neue Tabelle erstellen, weil es ein neues Jahr ist oder Sie haben einen neuen Kunden.

Spaltenfamilien

Legen Sie für verwandte Spalten dieselbe Spaltenfamilie fest. Wenn eine Zeile mehrere Werte enthält, die einen Bezug zueinander haben, empfiehlt es sich, die Spalten mit diesen Werten in derselben Spaltenfamilie zu gruppieren. Gruppieren Sie Daten so nah wie möglich beieinander, damit Sie keine komplexen Filter entwerfen müssen und in Ihren häufigsten Leseanfragen genau die Informationen erhalten, die Sie benötigen, aber nicht mehr.

Sie können bis zu 100 Spaltenfamilien pro Tabelle erstellen. Wenn Sie mehr als 100 Spaltenfamilien erstellen, kann das die Leistung beeinträchtigen.

Wählen Sie kurze Namen für Ihre Spaltenfamilien aus. Namen sind in den Daten enthalten der für jede Anfrage übertragen wird.

Legen Sie für Spalten mit unterschiedlichen Datenaufbewahrungsanforderungen verschiedene Spaltenfamilien fest. Diese Vorgehensweise ist wichtig, wenn Sie die Speicherkosten in Grenzen halten möchten. Richtlinien für die automatische Speicherbereinigung werden auf der Ebene der Spaltenfamilie und nicht auf Spaltenebene festgelegt. Wenn Sie beispielsweise nur die neueste Version einer speichern Sie diese nicht in einer Spaltenfamilie, 1.000 Versionen von etwas anderem. Andernfalls bezahlen Sie für das Speichern von 999 Zellen die Sie nicht benötigen.

Spalten

Erstellen Sie in der Tabelle so viele Spalten wie nötig. Bigtable Tabellen sind dünnbesetzt und es gibt keine Platznachlass für eine Spalte, die nicht in eine Zeile. Sie können in einer Tabelle Millionen von Spalten angeben, solange keine Zeile das Limit von 256 MB pro Zeile überschreitet.

Vermeiden Sie zu viele Spalten in einer einzelnen Zeile. Auch wenn eine Tabelle Millionen von Spalten haben, sollte eine Zeile nicht. Dafür gibt es einige Faktoren. Best Practice:

  • Bigtable benötigt Zeit für die Verarbeitung der einzelnen Zellen in einer Zeile.
  • Jede Zelle erhöht die Menge an Daten, die in Ihrem und über das Netzwerk gesendet werden. Wenn Sie beispielsweise 1 KB (1.024 Byte) von Daten ist es viel platzsparender, diese Daten in einem in einer einzigen Zelle arbeiten, anstatt die Daten auf 1.024 Zellen zu verteilen, enthalten 1 Byte.

Wenn Ihr Dataset logisch mehrere Spalten pro Zeile benötigt, als Bigtable effizient verarbeiten kann, sollten Sie die Daten als protobuf in einer einzelnen Spalte speichern.

Optional können Sie Spaltenqualifizierer als Daten behandeln. Da Sie die Daten Spaltenqualifizierer für jede Spalte haben, können Sie Platz sparen, indem Sie der Spalte durch einen Wert. Stellen Sie sich als Beispiel eine Tabelle vor, in der Daten über Freundschaften in einer Friends-Spaltenfamilie. Jede Zeile repräsentiert eine Person und all ihre Freundschaften. Jeder Spaltenqualifizierer kann die ID eines Freundes sein. Dann wird der Wert für Jede Spalte in dieser Zeile kann der soziale Kreis sein, in dem sich der Freund befindet. In dieser Zeilen können beispielsweise so aussehen:

Zeilenschlüssel Fred Gabriel Hiroshi-Schaf Seo Yoon Jakob
Jose Buchclub produktive Tätigkeiten genutzt wird Tennis
Sofia produktive Tätigkeiten genutzt wird school Schachclub

Vergleichen Sie dieses Schema mit einem Schema für dieselben Daten, die Spalten nicht verarbeiten. als Daten und enthält in jeder Zeile dieselben Spalten:

Zeilenschlüssel Freund Kreis
Jose#1 Fred Buchclub
Jose#2 Gabriel produktive Tätigkeiten genutzt wird
Jose#3 Hiroshi-Schaf Tennis
Sofia#1 Hiroshi-Schaf produktive Tätigkeiten genutzt wird
Sofia#2 Seo Yoon school
Sofia Nr. 3 Jakob Schachclub

Das zweite Schemadesign führt dazu, dass die Tabelle schneller wächst.

Wenn Sie Spaltenqualifizierer zum Speichern von Daten verwenden, Spaltenqualifizierer kurze, aber aussagekräftige Namen geben. Mit diesem Ansatz können Sie die bei jeder Anfrage übertragene Datenmenge reduzieren. Die maximale Größe beträgt 16 KB.

Zeilen

Behalten Sie die Größe aller Werte in einer einzelnen Zeile unter 100 MB. Achten Sie darauf, dass Daten in einer einzelnen Zeile nicht 256 MB überschreiten. Zeilen, die dieses Limit überschreiten, können zu reduzierte Leseleistung.

Bewahren Sie alle Informationen für eine Entität in einer einzelnen Zeile auf. Für die meisten Anwendungsfälle Vermeiden Sie das Speichern von Daten, die atomar oder alle auf einmal gelesen werden müssen, in mehr als um Inkonsistenzen zu vermeiden. Wenn Sie zum Beispiel zwei Zeilen in einer Tabelle aktualisieren, ist es möglich, dass eine Zeile erfolgreich aktualisiert wird und die andere nicht. Ihr Schema darf nicht mehr als eine Zeile gleichzeitig aktualisieren, damit ähnliche Daten korrekt sind. Durch diese Vorgehensweise wird sichergestellt, dass, wenn ein Teil einer Schreibanfrage fehlschlägt oder erneut gesendet werden muss, nicht vorübergehend unvollständig ist.

Ausnahme: Wenn das Speichern einer Entität in einer einzelnen Zeile zu Zeilen mit mehreren MB führt, sollten Sie die Daten auf mehrere Zeilen aufteilen.

Speichern Sie verwandte Entitäten in benachbarten Zeilen, damit Lesevorgänge effizienter werden.

Zellen

Speichern Sie nicht mehr als 10 MB Daten in einem einzigen Zelle. Zur Erinnerung: Eine Zelle sind die Daten, die für eine bestimmte Zeile und Spalte mit einem und dass mehrere Zellen an der Schnittmenge der Daten Zeile und Spalte. Die Anzahl der in einer Spalte beibehaltenen Zellen wird durch den Richtlinie für die automatische Speicherbereinigung, die Sie für die Spalte festgelegt haben die diese Spalte enthält.

Aggregierte Zellen verwenden, um aggregierte Daten zu speichern und zu aktualisieren. Wenn es Ihnen nur wichtig ist zum aggregierten Wert von Ereignissen für eine Entität, z. B. die monatliche Summe Umsatz pro Mitarbeiter in einem Einzelhandelsgeschäft, können Sie Aggregatfunktionen verwenden. Weitere Informationen Weitere Informationen finden Sie unter Werte beim Schreiben aggregieren. (Vorschau).

Zeilenschlüssel

Entwerfen Sie den Zeilenschlüssel basierend auf den Abfragen, mit denen Sie die Daten abrufen. Speziell konzipierte Zeilenschlüssel ermöglichen die optimale Leistung von Bigtable. Die effizientesten Bigtable-Abfragen rufen Daten mit einer der folgenden Optionen ab:

  • Zeilenschlüssel
  • Zeilenschlüsselpräfix
  • Zeilenbereich, der durch den Start und das Ende der Zeilenschlüssel definiert wird

Andere Arten von Abfragen lösen einen Scan der gesamten Tabelle aus, was deutlich weniger effizient ist. Wenn Sie von vornherein den richtigen Zeilenschlüssel wählen, verhindern Sie, dass Sie später mühsam Daten migrieren müssen.

Begrenzen Sie die Größe des Zeilenschlüssels. Ein Zeilenschlüssel darf maximal 4 KB groß sein. Lange Zeilenschlüssel benötigen zusätzlichen Arbeitsspeicher und Speicherplatz bereitstellen und die Antwortzeit erhöhen vom Bigtable-Server.

Speichern Sie mehrere durch Trennzeichen getrennte Werte in den einzelnen Zeilenschlüsseln. Die effizienteste Methode zum effizienten Abfragen von Bigtable ist der Zeilenschlüssel. Daher ist es oft nützlich, mehrere Kennungen in Ihren Zeilenschlüssel aufzunehmen. Wenn Ihr Zeilenschlüssel mehrere Werte enthält, ist es besonders wichtig, ein klares Verständnis von der Verwendung der Daten zu haben.

Zeilenschlüsselsegmente werden normalerweise durch ein Trennzeichen getrennt, z. B. einen Doppelpunkt, einen Schrägstrich oder ein Rautezeichen. Das erste Segment oder der Satz zusammenhängender Segmente ist der Zeilenschlüssel. und das letzte Segment bzw. der letzte Satz zusammenhängender Segmente der Zeilenschlüssel .

Grafik: Beispiel für einen Zeilenschlüssel

Mit sorgfältig ausgewählten Zeilenschlüsselpräfixen können Sie die eingebaute Sortierung von Bigtable für das Speichern verwandter Daten in benachbarten Zeilen nutzen. Das Speichern zusammengehöriger Daten in angrenzenden Zeilen bietet Ihnen die Möglichkeit, auf verwandte Daten als Zeilenbereich zuzugreifen und keine ineffiziente Tabellensuche ausführen zu müssen.

Wenn Ihre Daten Ganzzahlen enthalten, die Sie numerisch speichern oder sortieren möchten, versehen Sie die Ganzzahlen mit vorangestellten Nullen auf. Bigtable speichert Daten lexikografisch. Beispiel: lexikografisch, 3 > 20, aber 20 > 03. Wenn Sie die Drei mit einer vorangestellten Null versehen, werden die Zahlen numerisch sortiert. Diese Taktik ist für Zeitstempel wichtig, in denen bereichsbasierte Abfragen genutzt werden.

Es ist wichtig, einen Zeilenschlüssel zu erstellen, mit dem ein klar definierter Zeilenbereich abgerufen werden kann. Andernfalls erfordert Ihre Abfrage einen Tabellenscan, der viel langsamer ist als das Abrufen bestimmter Zeilen.

Wenn Ihre Anwendung beispielsweise Mobilgerätedaten erfasst, können Sie einen Zeilenschlüssel haben, der aus dem Gerätetyp, der Geräte-ID und dem Tag besteht, an dem die Daten aufgezeichnet werden. Zeilenschlüssel für diese Daten können so aussehen:

        phone#4c410523#20200501
        phone#4c410523#20200502
        tablet#a0b81f74#20200501
        tablet#a0b81f74#20200502

Mit diesem Zeilenschlüssel-Design können Sie Daten mit einer einzigen Anfrage für Folgendes abrufen:

  • Einen Gerätetyp
  • Eine Kombination aus Gerätetyp und Geräte-ID

Dieses Zeilenschlüsseldesign ist nicht ideal, wenn Sie alle Daten für einen bestimmten Tag abrufen möchten. Da der Tag im dritten Segment oder im Suffix des Zeilenschlüssels gespeichert wird, können Sie nicht einfach einen Zeilenbereich anhand des Suffixes oder des mittleren Abschnitts des Zeilenschlüssels anfordern. Stattdessen müssen Sie eine Leseanfrage mit einem Filter senden, der die gesamte Tabelle auf den Tageswert hin scannt.

Verwenden Sie für Ihre Zeilen lesbare Stringwerte, sofern dies möglich ist. Diese Vorgehensweise erleichtert die Verwendung des Key Visualizer-Tools zum Beheben von Problemen mit Bigtable.

Oft sollten Sie Zeilenschlüssel entwerfen, die mit einem gemeinsamen Wert beginnen und mit einen detaillierten Wert. Wenn Ihr Zeilenschlüssel z. B. einen Kontinent, ein Land, und Stadt, können Sie Zeilenschlüssel erstellen, die so aussehen, automatisch zuerst nach Werten mit niedrigerer Kardinalität sortieren:

        asia#india#bangalore
        asia#india#mumbai
        asia#japan#osaka
        asia#japan#sapporo
        southamerica#bolivia#cochabamba
        southamerica#bolivia#lapaz
        southamerica#chile#santiago
        southamerica#chile#temuco

Zu vermeidende Zeilenschlüssel

Einige Arten von Zeilenschlüsseln können das Abfragen Ihrer Daten erschweren und andere die Leistung beeinträchtigen. In diesem Teil werden einige Arten von Zeilenschlüsseln beschrieben, deren Verwendung Sie in Bigtable vermeiden sollten.

Zeilenschlüssel, die mit einem Zeitstempel beginnen: Dieses Muster bewirkt, dass sequenzielle Schreibvorgänge auf einen einzelnen Knoten übertragen werden, wodurch ein Heißlaufen verursacht wird. Wenn fügen Sie einen Zeitstempel in einen Zeilenschlüssel ein und stellen ihm einen Wert mit hoher Kardinalität wie um Hotspots zu vermeiden.

Zeilenschlüssel, die dazu führen, dass ähnliche Daten nicht gruppiert werden: Vermeiden Sie Zeilenschlüssel, werden verwandte Daten in nicht zusammenhängenden Zeilenbereichen gespeichert, ineffizient zusammen lesen können.

Sequenzielle numerische IDs. Angenommen, Ihr System vergibt eine numerische ID an jeden Nutzer Ihrer Anwendung. Es mag in diesem Fall bequem erscheinen, die numerische ID der Nutzer als Zeilenschlüssel für Ihre Tabelle zu verwenden. Da neue Nutzer jedoch wahrscheinlich aktiver sind, verschiebt diese Herangehensweise den Großteil Ihres Traffics auf wenige Knoten.

Eine sicherere Herangehensweise wäre es, eine umgekehrte Version der numerischen ID der Nutzer zu verwenden. Dadurch verteilt sich der Traffic gleichmäßiger auf die Knoten Ihrer Bigtable-Tabelle.

Häufig aktualisierte IDs. Vermeiden Sie die Verwendung eines einzelnen Zeilenschlüssels zur Identifizierung eines Wertes, der oft aktualisiert werden muss. Wenn Sie z. B. die Speichernutzung speichern, für eine bestimmte Anzahl von Geräten einmal pro Sekunde, verwenden Sie keinen einzelnen Zeilenschlüssel für jedes Gerät, das aus der Geräte-ID und dem gespeicherten Messwert besteht, z. B. als 4c410523#memusage und aktualisieren Sie die Zeile wiederholt. Diese Art von Vorgang überlastet das Tablet, in dem die häufig verwendete Zeile gespeichert ist. Außerdem kann es zu einer Zeile so groß ist, dass sie ihre Größenbeschränkung überschreitet, da die vorherigen Werte einer Spalte Platz belegen bis die Zellen während der automatischen Speicherbereinigung entfernt wurden.

Speichern Sie stattdessen jeden neuen Lesevorgang in einer neuen Zeile. Im Beispiel zur Speichernutzung kann jeder Zeilenschlüssel die Geräte-ID, den Messwerttyp und einen Zeitstempel enthalten, sodass die Zeilenschlüssel etwa so aussehen: 4c410523#memusage#1423523569918. Diese Strategie ist effizient, da in Bigtable nicht mehr nötig ist, als beim Erstellen einer neuen Zelle. Außerdem können Sie mit dieser Strategie Daten aus einem bestimmten Zeitraum lesen, indem Sie die entsprechenden Start- und Endtasten.

Für Werte, die sich häufig ändern, wie etwa ein Zähler, der mit Hunderten von einmal pro Minute werden die Daten am besten im Gedächtnis gespeichert Anwendungsebene und schreiben Sie neue Zeilen in Bigtable. regelmäßig.

Hashwerte Durch das Hashing eines Zeilenschlüssels können Sie nicht mehr von den Vorteilen der natürlichen Sortierreihenfolge von Bigtable profitieren, sodass Zeilen nicht so gespeichert werden können, wie es für Abfragen optimal wäre. Aus dem gleichen Grund können auch Hash-Werte ist es schwierig, mit dem Key Visualizer-Tool Probleme mit Bigtable. Verwenden Sie für Nutzer lesbare Werte anstelle von Hash-Werten.

Werte werden als Rohbyte ausgegeben und nicht als für Menschen lesbare Strings. Rohbyte eignen sich gut für Spaltenwerte. Verwenden Sie zur Verbesserung der Lesbarkeit und Fehlerbehebung jedoch Stringwerte in Zeilenschlüsseln.

Besondere Anwendungsfälle

Möglicherweise haben Sie ein einzigartiges Dataset, auf das beim Entwerfen eines Schemas für die Speicherung in Bigtable besonderes Augenmerk gelegt werden muss. In diesem Abschnitt werden einige, aber nicht alle unterschiedlichen Arten von Bigtable-Daten sowie einige empfohlene Speicherpraktiken beschrieben.

Zeitbasierte Daten

Fügen Sie Ihrem Zeilenschlüssel einen Zeitstempel hinzu, wenn Sie häufig Daten zum Zeitpunkt der Aufnahme.

Ihre Anwendung könnte beispielsweise leistungsbezogene Daten wie die CPU-Leistung und Arbeitsspeichernutzung, bei vielen Computern einmal pro Sekunde. Ihr Zeilenschlüssel für diese Daten eine Kennzeichnung für die Maschine mit einem Zeitstempel für die Daten (für Beispiel: machine_4223421#1425330757685). Beachten Sie, dass Zeilenschlüssel lexikografisch sortiert sind.

Verwenden Sie keinen Zeitstempel allein oder am Anfang eines Zeilenschlüssels. führt dies dazu, dass sequenzielle Schreibvorgänge auf einen einzelnen Knoten übertragen werden, Hotspot. In diesem Fall müssen Sie sowohl Schreibmuster als auch Lesemuster berücksichtigen, Muster zu erkennen.

Wenn Sie in der Regel die am kürzesten zurückliegenden Aufzeichnungen zuerst abrufen, können Sie einen umgekehrten Zeitstempel im Zeilenschlüssel verwenden. Dazu ziehen Sie den Zeitstempel vom Maximalwert Ihrer Programmiersprache für lange Ganzzahlen ab (in Java, java.lang.Long.MAX_VALUE). Mit einem umgekehrten Zeitstempel werden die Aufzeichnungen von der letzten bis zur ersten geordnet.

Spezifische Informationen zum Arbeiten mit Zeitreihendaten finden Sie unter Schemas Designs für Zeitreihendaten entwickeln.

Mehrinstanzenfähigkeit

Zeilenschlüsselpräfixe bieten eine skalierbare Lösung für einen Anwendungsfall mit erforderlicher Mehrinstanzenfähigkeit. In einem solchen Szenario werden ähnliche Daten mit dem gleichen Datenmodell für mehrere Clients gespeichert. Eine Tabelle für alle Mandanten ist die effizienteste Methode um mandantenfähige Daten zu speichern und darauf zuzugreifen.

Angenommen, Sie speichern und verfolgen den Bestellverlauf für viele Unternehmen. Dabei können Sie Ihre eindeutige ID für jedes Unternehmen als Zeilenschlüsselpräfix nutzen. Alle Daten für einen Mandanten werden in zusammenhängenden Zeilen in derselben Tabelle gespeichert, und Sie können anhand des Zeilenschlüsselpräfixes abfragen oder filtern. Wenn ein Unternehmen nicht mehr zu Ihnen gehört, und Sie müssen die bisherigen Daten zu den bisherigen Käufen löschen, die Sie angegeben haben, können Sie den Bereich der Zeilen löschen, Zeilenschlüsselpräfix des Kunden.

Wenn Sie beispielsweise die Daten von Mobilgeräten der Kunden altostrat und examplepetstore speichern, können Sie folgende Zeilenschlüssel erstellen. Wenn dann altostrat nicht mehr Ihr Kunde ist, werden alle Zeilen mit dem Zeilenschlüsselpräfix altostrat gelöscht.

        altostrat#phone#4c410523#20190501
        altostrat#phone#4c410523#20190502
        altostrat#tablet#a0b41f74#20190501
        examplepetstore#phone#4c410523#20190502
        examplepetstore#tablet#a6b81f79#20190501
        examplepetstore#tablet#a0b81f79#20190502

Wenn Sie dagegen die Daten für ein Unternehmen in einer eigenen Tabelle speichern, besteht die Gefahr von Leistungs- und Skalierungsproblemen. Außerdem wird dann oft ungewollt die Grenze von Bigtable von 1.000 Tabellen pro Instanz überschritten. Nachdem eine Instanz dieses Limit erreicht hat, können Sie in Bigtable keine weiteren Tabellen in der Instanz erstellen.

Datenschutz

Sofern Ihr Anwendungsfall dies nicht erfordert, sollten Sie keine personenidentifizierbaren Informationen verwenden. (PII) oder Nutzerdaten in Zeilenschlüsseln oder Spaltenfamilien-IDs enthalten. Die Werte in Zeilenschlüsseln und Spaltenfamilien sowohl Kundendaten als auch Dienstdaten sind, und Anwendungen, wie Verschlüsselung oder Protokollierung, können sie ungewollt für Nutzer die keinen Zugriff auf private Daten haben sollten.

Weitere Informationen dazu, wie Dienstdaten verarbeitet werden, finden Sie in der Google Cloud Platform Datenschutz Hinweis:

Domainnamen

Sie können Domainnamen als Bigtable-Daten speichern.

Große Bereich von Domainnamen

Sollten Sie Daten über Entitäten speichern, die als Domainnamen dargestellt werden können, ist es sinnvoll, als Zeilenschlüssel einen umgekehrten Domainnamen zu verwenden (z. B. com.company.product). Dies ist besonders dann zu empfehlen, wenn die Daten in den einzelnen Zeilen sich häufiger mit denen in benachbarten Zeilen überschneiden. In diesem Fall kann Bigtable Ihre Daten besser komprimieren.

Im Gegensatz dazu können Standarddomainnamen, die nicht umgekehrt werden, so sortiert werden, dass zusammengehörige Daten an einem Ort gruppiert werden. Dies kann zu einer weniger effizienten Komprimierung und zu weniger effizienten Lesevorgängen führen.

Diese Vorgehensweise funktioniert außerdem am besten, wenn Ihre Daten über viele verschiedene umgekehrte Domainnamen verteilt sind.

Betrachten Sie zur Veranschaulichung dieses Punkts die folgenden Domainnamen, die automatisch in lexikografischer Reihenfolge von Bigtable sortiert werden:

      drive.google.com
      en.wikipedia.org
      maps.google.com

Das ist nicht sinnvoll für den Anwendungsfall, in dem Sie alle Zeilen für google.com abfragen möchten. Betrachten Sie im Gegensatz dazu dieselben Zeilen, in denen die Domainnamen umgekehrt wurden:

      com.google.drive
      com.google.maps
      org.wikipedia.en

Im zweiten Beispiel werden die verbundenen Zeilen automatisch so sortiert, vereinfacht das Abrufen als Zeilenbereich.

Wenige Domainnamen

Wenn Sie davon ausgehen, dass nur eine oder eine kleine Anzahl von Domainnamen gespeichert werden sollen, sollten Sie andere Werte für Ihren Zeilenschlüssel verwenden. Andernfalls können Sie Schreibvorgänge auf einen einzelnen Knoten in Ihrem Cluster, was zu Hotspots oder einer Erhöhung der Zeilenanzahl zu groß.

Wechselnde oder unsichere Abfragen

Wenn Sie nicht immer dieselben Abfragen für Ihre Daten ausführen oder sich nicht sicher sind, können Sie alle Daten für eine Zeile in einer anstelle von mehreren Spalten. Bei diesem Ansatz verwenden Sie ein Format, erschwert die spätere Extraktion einzelner Werte, wie etwa das Protokollprotokoll Puffer im Binärformat oder eine JSON-Datei.

Der Zeilenschlüssel ist immer noch sorgfältig entworfen, um sicherzustellen, dass Sie die benötigten Daten abrufen können, aber jede Zeile hat normalerweise nur eine Spalte, die alle Daten für die Zeile in einem einzigen protobuf enthält.

Das Speichern der Daten als protobuf-Nachricht in einer Spalte, anstatt sie auf mehrere Spalten zu verteilen, hat Vor- und Nachteile. Zu den Vorteilen gehören:

  • Da die Daten weniger Speicherplatz verbrauchen, fallen weniger Kosten an.
  • Sie bewahren sich eine bestimmte Flexibilität, da Sie sich nicht auf Spaltenfamilien und Spaltenqualifizierer festlegen.
  • Ihre Leseanwendung muss das Tabellenschema nicht „kennen“.

Einige Nachteile sind:

  • Die protobuf-Nachrichten müssen nach dem Lesen aus Bigtable deserialisiert werden.
  • Sie können die Daten in protobuf-Nachrichten nicht mehr mit Filtern abrufen.
  • Sie können BigQuery nicht verwenden, um föderierte Abfragen für Felder in protobuf-Nachrichten auszuführen, nachdem diese aus Bigtable gelesen wurden.

Nächste Schritte