Schemadesign für Zeitachsendaten

Auf dieser Seite werden Konzepte, Muster und Beispiele für das Schemadesign zum Speichern von Zeitachsendaten in Cloud Bigtable erläutert. Voraussetzung dafür ist die Kenntnis der Übersicht über Cloud Bigtable. Außerdem sollten Sie mit dem Entwerfen von Schemas vertraut sein.

Immer dann, wenn Sie etwas messen und diese Messungen im Zeitablauf zuordnen, verwenden Sie eine Zeitachse. Zeitachsen begegnen uns an vielen Stellen. Beispiele:

  • Wenn Ihr Computer nur langsam läuft und Sie deshalb wissen möchten, wie sein Arbeitsspeicher genutzt wird, erscheint der Verlauf der Speichernutzung als Zeitachse.

  • Wenn in einer Nachrichtensendung die Temperaturentwicklung über einen gewissen Zeitraum dargestellt wird, erfolgt dies über Zeitachsen.

  • Wenn Sie mit Devisen handeln und den gleitenden Durchschnitt der Kurse für Euro/USD über 5, 10 oder 30 Tage grafisch darstellen müssen, verwenden Sie Zeitachsen.

Zeitachsen spielen in vielen Fällen eine wichtige Rolle:

  • Sie helfen bei der Optimierung der Ressourcennutzung, der Senkung des Energieverbrauchs, der Minimierung der Umweltbelastung und der Reduzierung von Kosten.

  • Mit Zeitachsen können wir Trends in Daten ermitteln und dabei anschaulich darstellen, was in der Vergangenheit geschehen ist, sowie sachkundige Einschätzungen darüber abgeben, was in der Zukunft zu erwarten ist.

  • Zeitachsen unterstützen oft komplexe Analysen und das maschinelle Lernen in Bereichen wie Finanzdienstleistung, Einzelhandel, Versicherung, Physik und Chemie.

Dieser Leitfaden bietet detaillierte Strategien und eine Schritt-für-Schritt-Anleitung zum Speichern und Abfragen von Zeitachsendaten in Cloud Bigtable.

Zeitachsen und Cloud Bigtable

Das Speichern von Zeitachsendaten in Cloud Bigtable ist eine ideale Lösung. Cloud Bigtable speichert Daten als unstrukturierte Spalten in Zeilen. Jede Zeile hat einen Schlüssel und die Zeilenschlüssel werden lexikografisch geordnet.

Es gibt zwei häufig verwendete Arten, Daten aus Cloud Bigtable abzurufen:

  • Sie können eine einzelne Zeile erhalten, wenn Sie ihren Zeilenschlüssel angeben.
  • Sie können mehrere Zeilen erhalten, wenn Sie eine Reihe von Zeilenschlüsseln angeben.

Diese Methoden sind ideal, um Zeitachsendaten abzufragen, da oft Daten aus einem gewissen Zeitraum benötigt werden (beispielsweise alle Marktdaten des Tages oder die CPU-Statistiken der letzten 15 Minuten für einen Server). Daher funktioniert Cloud Bigtable hervorragend mit Zeitachsendaten.

Natürlich steckt der Teufel immer im Detail. Der Teufel bei Cloud Bigtable steckt im Schema für Ihre Daten. Die Struktur der Spalten und der Zeilenschlüssel muss sorgfältig entworfen werden. Ein gutes Schema führt zu exzellenter Leistung sowie Skalierbarkeit und ein schlechtes Schema kann zu einem System mit schwacher Leistung führen. Es gibt jedoch kein einzelnes Schema, das für alle Fälle am besten geeignet ist.

Der Rest des Dokuments besteht aus einigen Mustern für das Schemadesign in Cloud Bigtable. Anhand dieser Muster können Sie ein ideales Schema für Ihren Anwendungsfall entwerfen. Nach der Aufzählung und Erklärung der Muster für das Schemadesign können Sie aus Beispielen für die folgenden Anwendungsfälle lernen:

  • Finanzmarktdaten
  • Servermesswerte (beispielsweise CPU-, Speicher- und Netzwerknutzung)
  • Intelligente Energiezähler (Internet der Dinge bzw. IoT)

Schemadesignmuster für Zeitachsen

Die Schemadesignmuster für die Speicherung von Zeitachsen in Cloud Bigtable lassen sich in folgende Kategorien aufteilen:

  • Allgemeine Muster
  • Muster für das Zeilenschlüsseldesign
  • Muster für das Spaltendesign

Allgemeine Muster

Kurze, aber aussagekräftige Namen

Wenn Sie Daten von Cloud Bigtable übertragen, übertragen Sie auch Metadaten wie:

  • Den Zeilenschlüssel
  • Die Spaltenfamilie, also eine Kennung, die verwendet wird, um verwandte Spalten zu gruppieren
  • Den Spaltenqualifizierer, ein eindeutiger Name innerhalb der Spaltenfamilie

Daher ist es wichtig, aussagekräftige Namen zu wählen, die gleichzeitig so kurz wie möglich sind, da die Größe jedes Namens zum Speicher- und RPC-Aufwand beiträgt. Beispielsweise sollten Sie als Spaltenqualifizierer statt CELLPHONE_NUMBER eher CELL wählen, eine kurze, aber aussagekräftige Abkürzung.

Muster für das Zeilenschlüsseldesign

Hohe und schmale Tabellen verwenden

In einer hohen und schmalen Tabelle gibt es wenige Ereignisse pro Zeile – es könnte sogar nur ein Ereignis pro Zeile sein – wohingegen es in kurzen und breiten Tabellen viele Ereignisse pro Zeile gibt. Wie sogleich beschrieben, eignen sich hohe und schmale Tabellen am besten für Zeitachsendaten.

Angenommen, Sie messen jeden Morgen die Temperatur in Ihrem Gemüsegarten. Wenn Sie sich jetzt für eine Zeile pro Tag entscheiden, da Sie die Temperatur jeden Morgen messen, erhalten Sie eine hohe und schmale Tabelle. Beachten Sie, dass der Zeitstempel nicht das erste Element des Zeilenschlüssels ist. Wie später beschrieben, kann es vielfältige Probleme verursachen, wenn der Zeitstempel das erste Element des Zeilenschlüssels ist.

Zeilenschlüssel Spaltendaten
VEGGIEGARDEN#20150301 DAILY:TEMP:60.4
VEGGIEGARDEN#20150302 DAILY:TEMP:61.2
VEGGIEGARDEN#20150303 DAILY:TEMP:61.0
VEGGIEGARDEN#20150304 DAILY:TEMP:65.1
VEGGIEGARDEN#20150305 DAILY:TEMP:62.2
VEGGIEGARDEN#20150331 DAILY:TEMP:60.4

Angenommen, Sie möchten im Gegensatz dazu den Temperaturverlauf eines ganzen Monats aufzeichnen, und zwar in einer Zeile pro Monat. Das folgende Beispiel zeigt die kurze und breite Tabelle, die Sie als Ergebnis erhalten:

Zeilenschlüssel Spaltendaten
VEGGIEGARDEN#20150301 TEMP:1:60.4 TEMP:2:61.2 TEMP:3:61.0 TEMP:4:65.1 TEMP:5:62.2 TEMP:31:60.4

Für Zeitachsen sollten Sie im Allgemeinen hohe und schmale Tabellen verwenden. Dafür gibt es zwei Gründe: Einerseits können Sie Ihre Daten einfacher abfragen, wenn Sie nur ein Ereignis pro Zeile speichern. Andererseits ist die Wahrscheinlichkeit höher, dass die Zeilengröße das empfohlene Maximum überschreitet, wenn Sie mehrere Ereignisse pro Zeile speichern (siehe Große Zeilen sind möglich, die Größe ist aber begrenzt).

Als Optimierung können Sie kurze und breite Tabellen verwenden, aber eine unbeschränkte Anzahl an Ereignissen vermeiden. Wenn Sie beispielsweise im Normalfall die Ereignisse eines ganzen Monats abrufen, ist die Tabelle oben eine vernünftige Optimierung. Die Größe der Zeilen ist nämlich auf die Anzahl der Tage in einem Monat begrenzt.

Zeilen den Vorzug vor Spaltenversionen geben

In Cloud Bigtable gibt es Spaltenversionen mit Zeitstempel. Daher ist es theoretisch möglich, eine Zeitachse als eine Reihe von Versionen einer Spalte zu speichern. Wenn Sie beispielsweise täglich den Schlusskurs von ZXZZT-Aktien festhalten möchten, können Sie dies in einer einzelnen Spalte mit Zeitstempelversionen für jeden Tag tun.

Zeilenschlüssel Spaltendaten
ZXZZT AKTIE:KURS (V1 03/01/15):558.40 AKTIE:KURS (V2 03/02/15):571.34 AKTIE:KURS (V3 03/03/15):573.64 AKTIE:KURS (V4 03/04/15):573.37 AKTIE:KURS (V5 03/05/15):575.33

Dies ist aber nicht die beste Art, diese Daten zu speichern.

Standardmäßig sollten Sie neue Zeilen statt Spaltenversionen verwenden. Mehrere Zeilen mit einer einzelnen Version von jedem Ereignis in jeder Zeile zu verwenden, ist die einfachste Art, Ihre Daten darzustellen, zu verstehen und abzufragen.

Für Anwendungsfälle, bei denen Werte geändert werden, aber auch der Verlauf der Werte wichtig ist, kann es akzeptabel sein, Versionen einer Spalte zu verwenden. Angenommen, Sie haben anhand des Schlusskurses von ZXZZT eine Reihe von Berechnungen durchgeführt und anfänglich wurde für den Schlusskurs fälschlicherweise 559,40 statt 558,40 eingetragen. In diesem Fall kann es wichtig sein, den Verlauf des Werts zu kennen, für den Fall, dass der falsche Wert noch andere Fehlkalkulationen verursacht hat.

Beim Zeilenschlüsseldesign die Abfragen berücksichtigen

Wenn Cloud Bigtable Zeilen speichert, ordnet es die Zeilen in lexikografischer Ordnung nach dem Zeilenschlüssel. Es gibt nur einen Index pro Tabelle, nämlich den Zeilenschlüssel. Abfragen, die auf eine einzelne Zeile oder auf einen Bereich mit fortlaufenden Zeilen zugreifen, sind schnell und effizient. Alle anderen Abfragen führen zu einem Scan der gesamten Tabelle, was wesentlich länger dauert. Ein Scan der gesamten Tabelle ist genau das, wonach es klingt – jede Zeile der Tabelle wird untersucht. In Cloud Bigtable, wo Sie viele Petabyte an Daten in einer einzelnen Tabelle speichern können, wird die Leistung bei einem Scan der gesamten Tabelle immer schlechter, je größer das System wird.

Nehmen Sie zum Beispiel eine Tabelle an, in der die Spielergebnisse eines Videospiels gespeichert werden. Diese könnte folgendermaßen aussehen.

Zeilenschlüssel Spaltendaten
LoL#20150301 SPIEL:SPIELER:Corrie SPIEL:SIEG:false SPIEL:KDA:4.25
LoL#20150302 SPIEL:SPIELER:Jo SPIEL:SIEG:true SPIEL:KDA:7.00
LoL#20150302 SPIEL:SPIELER:Sam SPIEL:SIEG:true SPIEL:KDA:7.00
LoL#20150303 SPIEL:SPIELER:Corrie SPIEL:SIEG:true SPIEL:KDA:9.50
Starcraft#20150303 SPIEL:SPIELER:Eriko SPIEL:SIEG:true SPIEL:KDA:6.00

Angenommen Sie möchten diese Daten abfragen, um die Frage "Wieviele LoL-Spiele hat Corrie im März gewonnen?" zu beantworten. Mit dem obigen Schema müssen Sie den größten Teil Ihrer Tabelle scannen, um die Frage zu beantworten. Wenn Sie Ihre Tabelle im Gegensatz wie unten entwerfen, könnten Sie diese Abfrage durch den Abruf einer bestimmte Reihe an Zeilenschlüsseln erledigen:

Zeilenschlüssel Spaltendaten
LoL#Corrie#20150301 SPIEL:SIEG:false SPIEL:KDA:4.25
LoL#Corrie#20150303 SPIEL:SIEG:true SPIEL:KDA:9.50
LoL#Jo#20150302 SPIEL:SIEG:true SPIEL:KDA:7.00
LoL#Sam#20150302 SPIEL:SIEG:true SPIEL:KDA:7.00
Starcraft#Eriko#20150303 SPIEL:SIEG:true SPIEL:KDA:6.00

Es ist von überragender Bedeutung für die Gesamtleistung Ihres Systems, Zeilenschlüssel zu wählen, die gängige Abfragen erleichtern. Listen Sie Ihre Abfragen auf, ordnen Sie sie nach Wichtigkeit und entwerfen Sie Zeilenschlüssel, die für diese Abfragen geeignet sind.

Wie geht man mit einer Situation um, in der es keinen perfekten Zeilenschlüssel gibt? Angenommen, die Abfragen für alle LoL-Spiele im März und alle von Corrie im März gespielten LoL-Spiele sind von gleicher Wichtigkeit. Das Schema oben würde uns ermöglichen, alle LoL-Spiele von Corrie im März abzufragen, es würde uns aber nicht dabei helfen, alle LoL-Spiele im März abzufragen – Ihre beste Möglichkeit wäre, alle LoL-Spiele abzufragen und dann nach März zu filtern. Es gibt zwei Arten, dieses Problem zu lösen:

Denormalisierung

  • Sie können zwei Tabellen verwenden, deren Zeilenschlüssel jeweils für eine der Abfragen optimiert sind. Mit dieser Lösung erhalten Sie ein robustes, skalierbares System.

Abfragen und Filter

  • Sie können auch bei dem oben gezeigten Schema bleiben. Dann ist die Leistung für eine der beiden Abfragen unterdurchschnittlich (alle LoL-Spiele im März), weil Sie sehr viele Zeilen filtern. Dies ist normalerweise keine gute Lösung, da damit ein schlechter skalierbares System entsteht, dessen Leistung sich bei steigender Nutzung wahrscheinlich verschlechtert.

Heißlaufen durch Zeilenschlüssel verhindern

Das häufigste Problem bei Zeitachsen in Cloud Bigtable ist das Heißlaufen. Dieses Problem kann jede Art von Zeilenschlüssel betreffen, der einen kontinuierlich steigenden Wert enthält.

Kurz gesagt: Wenn ein Zeilenschlüssel für eine Zeitachse einen Zeitstempel enthält, zielen alle Schreibvorgänge auf einen einzigen Serverknoten. Die Vorgänge schreiben auf diesen Knoten, bis er voll ist, und gehen erst dann zum nächsten Knoten in Ihrem Cluster über, wodurch der Knoten heiß läuft. Wenn Sie beispielsweise den Akkustand eines Handys speichern möchten und Ihr Zeilenschlüssel aus dem Wort "AKKU" und einem Zeitstempel besteht (wie unten gezeigt), steigen die Werte der Zeilenschlüssel sequenziell an. Da Cloud Bigtable angrenzende Zeilenschlüssel auf dem gleichen Serverknoten speichert, finden alle Schreibvorgänge auf nur einem Knoten statt, bis dieser Knoten voll ist. Danach werden Schreibvorgänge auf den nächsten Knoten im Cluster verlegt.

Zeilenschlüssel Spaltendaten
AKKU#20150301124501001 MESSWERT:NUTZER:Corrie MESSWERT:PROZENT:98
AKKU#20150301124501002 MESSWERT:NUTZER:Jo MESSWERT:PROZENT:54
AKKU#20150301124501003 MESSWERT:NUTZER:Corrie MESSWERT:PROZENT:96
AKKU#20150301124501004 MESSWERT:NUTZER:Sam MESSWERT:PROZENT:43
AKKU#20150301124501005 MESSWERT:NUTZER:Sam MESSWERT:PROZENT:38

Es gibt verschiedene Möglichkeiten, dieses Problem zu lösen:

  • Felder hochstufen. Verschieben Sie Felder von den Spaltendaten in den Zeilenschlüssel, damit die Schreibvorgänge nicht fortlaufend sind.

  • Salting. Fügen Sie zum Zeilenschlüssel ein zusätzliches, berechnetes Element hinzu, damit die Schreibvorgänge nicht fortlaufend sind.

Mit dem Key Visualizer-Tool können Sie Hotspots leichter identifizieren und Probleme mit Cloud Bigtable leichter beheben.

Felder hochstufen

In diesem Beispiel stufen Sie USER von einer Spalte zu einem Element im Zeilenschlüssel hoch. Diese Änderung würde das Problem des Heißlaufens lösen, da Nutzerkennungen eine gleichmäßigere Verteilung an Zeilenschlüsseln liefern. Daher werden Schreibvorgänge auf mehrere Knoten in Ihrem Cluster verteilt.

Der Vorteil des Felder Hochstufens liegt darin, dass es Abfragen oftmals effizienter macht, wodurch diese Strategie zum klaren Sieger wird. Der (kleine) Nachteil liegt darin, dass Ihre Abfragen von Ihren hochgestuften Feldern beschränkt wird, was Nachbesserungen notwendig machen kann, falls Sie die falschen Felder hochstufen.

Zeilenschlüssel Spaltendaten
AKKU#Corrie#20150301124501001 MESSWERT:PROZENT:98
AKKU#Corrie#20150301124501003 MESSWERT:PROZENT:96
AKKU#Jo#20150301124501002 MESSWERT:PROZENT:54
AKKU#Sam#20150301124501004 MESSWERT:PROZENT:43
AKKU#Sam#20150301124501005 MESSWERT:PROZENT:38

Salting

In diesem Beispiel nehmen Sie einen Hash des Zeitstempels und teilen ihn durch 3, nehmen das, was nach dieser Berechnung übrig bleibt und addieren den Rest zum Zeilenschlüssel. Warum 3? Das ist eine Schätzung der Zahl an Knoten im Cluster in diesem Fall und würde eine gute Aufteilung der Aktivität über die Knoten bieten.

Der Vorteil von Salting ist die Einfachheit – es ist im Kern eine einfache Hashfunktion. Der Nachteil besteht darin, dass Sie bei Abfragen nach Zeiträumen mehrere Scans durchführen – einen Scan pro Salt-Wert – und die Ergebnisse in Ihrem eigenen Code kombinieren müssen. Ein weiterer Nachteil besteht darin, dass es schwierig ist, einen Salt-Wert auszuwählen, der sowohl die Aktivität gleichmäßig über Knoten verteilt als auch gut funktioniert, wenn Sie ihr System nach unten oder oben skalieren. Aufgrund dieser Nachteile und weil für Menschen lesbare Zeilenschlüssel immer noch am besten funktionieren, sollten Sie Salting vermeiden – außer es gibt keinen anderen Weg, um Heißlaufen zu verhindern.

Zeilenschlüssel Spaltendaten
AKKU#1#20150301124501003 MESSWERT:NUTZER:Jo MESSWERT:PROZENT:96
AKKU#1#20150301124501004 MESSWERT:NUTZER:Sam MESSWERT:PROZENT:43
AKKU#2#20150301124501002 MESSWERT:NUTZER: Corrie MESSWERT:PROZENT:54
AKKU#3#20150301124501005 MESSWERT:NUTZER:Sam MESSWERT:PROZENT:38
AKKU#3#20150301124501001 MESSWERT:NUTZER:Corrie MESSWERT:PROZENT:98

Felder hochstufen und standardmäßig bevorzugen. Das Hochstufen der Felder vermeidet das Heißlaufen in fast allen Fällen und macht es tendenziell leichter einen Zeilenschlüssel zu entwerfen, der Abfragen erleichtert.

Salting nur verwenden, wenn das Hochstufen der Felder Heißlaufen nicht verhindert. Für den seltenen Fall, dass Sie eine Salting-Funktion anwenden, achten Sie darauf, nicht zu viele Annahmen über die zugrunde liegende Größe des Clusters zu treffen. Das Beispiel oben nutzt eine Salting-Funktion, die annimmt, dass es im Cluster drei Knoten gibt. Diese Annahme kann sicher getroffen werden, da sie mit der begrenzten Anzahl an Knoten, die in einem Cloud Bigtable-Cluster vorhanden sein können, skalieren würde. Wenn Sie Cluster mit Hunderten von Knoten erstellen können, sollten Sie eine andere Salting-Funktion anwenden.

Zeitstempel nur umkehren wenn nötig

Sie können Zeitstempel umkehren, wenn Sie den Zeitstempel vom maximalen Wert für lange Ganzzahlen Ihrer Programmiersprache abziehen (z. B. java.lang.Long.MAX_VALUE in Java). Durch das Umkehren des Zeitstempels können Sie einen Zeilenschlüssel entwerfen, bei dem das jüngste Ereignis am Anfang der Tabelle statt am Ende steht. Daher können Sie die N jüngsten Ereignisse abfragen, wenn Sie die ersten N Zeilen der Tabelle abfragen.

Sie sollten umgekehrte Zeitstempel nur dann bevorzugen, wenn Ihre häufigsten Abfragen auf die jüngsten Werte zielen. Das liegt daran, dass umgekehrte Zeitstempel alle anderen Abfrage komplexer machen und dadurch das gesamte Schema komplizierter wird.

Muster für das Spaltendesign

Große Zeilen sind möglich, die Größe ist aber begrenzt

Zeilen in Cloud Bigtable können ~100 Spaltenfamilien und Millionen von Spalten beinhalten, mit einer Begrenzung von 100 MB für jeden in einer Spalte gespeicherten Wert. Diese großzügigen Begrenzungen sorgen für große Flexibilität. Sie sollten jedoch nicht davon ausgehen, dass große Zeilen die richtige Art sind, Daten zu speichern, und dass Sie daher jede Zeile mit so vielen Daten wie möglich füllen sollten. Beachten Sie immer, dass das Abfragen von großen Werten mehr Zeit und Speicher in Anspruch nimmt.

Grundsätzlich sollte die Größe der Zeilen kleiner als etwa 100 MB bleiben. Dies ist eher eine Richtlinie als eine Regel – Zeilen dürfen größer als 100 MB sein. Wenn jedoch viele Ihrer Zeilen größer sind, ist mit Leistungsproblemen zu rechnen.

Grundsätzlich sollte die Größe der Spalten unter etwa 10 MB bleiben. Auch dies ist eher eine Richtlinie als eine Regel – Sie können einige Werte, die größer als 10 MB sind speichern, aber diese verursachen wahrscheinlich Leistungsprobleme.

Zur Betonung: Wenn Sie auf viele große Zeilen oder große individuelle Werte zurückgreifen, ist mit Leistungsproblemen zu rechnen.

Cloud Bigtable ist ein Schlüssel/Wert-Speicher, kein relationaler Speicher. Joins und Transaktionen, außer innerhalb einer einzelnen Zeile, werden nicht unterstützt. Daher ist es am besten, auf Daten in einzelnen Zeilen oder in einem fortlaufenden Bereich von Zeilen zuzugreifen.

Eine Folge dieses Musters ist recht offensichtlich. In der überwiegenden Mehrheit der Fälle greifen Zeitachsen-Abfragen auf einen gegebenen Datensatz für einen Zeitraum zu. Stellen Sie daher sicher, dass alle Daten für einen gegebenen Zeitraum in fortlaufenden Zeilen gespeichert werden, außer dies würde ein Heißlaufen verursachen.

Eine weitere Folge ist, dass die Daten beim Lesen von Daten in einer Zeile oder einem Zeilenbereich für sich selbst genommen nützlich sein sollten. Sie sollten die Daten nicht mit anderen Daten kombinieren müssen. Angenommen, Sie speichern die Nutzeraktivität einer Shopping-Website und müssen oft die letzten fünf Aktionen eines Nutzers abfragen, um sie in einer Seitenleiste anzuzeigen. In diesem Fall sollten Sie das Denormalisieren Ihrer Daten und das Einbeziehen einiger Nutzer- und Produktinformationen in die Tabelle in Betracht ziehen. Im Gegensatz dazu würden Sie mit einer relationalen Datenbank die Nutzer-ID und die Produkt-ID in einer Tabelle speichern und die Tabelle dann mit separaten Nutzer- und Produkttabellen in Ihrer SQL-Abfrage verbinden.

Allerdings müssten Sie nicht jedes einzelne Datum über eine Entität in jeder einzelnen Zeile speichern. Wenn Sie beispielsweise Informationen über die kürzlichen Aktivitäten eines Nutzers anzeigen, müssen Sie nicht die Telefonnummer des Nutzers oder die Adresse eines Produktherstellers speichern, da Sie diese Informationen nicht in der Seitenleiste anzeigen werden.

Nach Möglichkeiten zum Denormalisieren Ausschau halten, um Abfragen zu genügen, aber nur so viele Daten aufnehmen, wie von den Abfragen benötigt.

Daten, auf die Sie in einer einzelnen Abfrage zugreifen, in einer einzelnen Spaltenfamilie speichern

Spaltenqualifizierer in einer einzelnen Spaltenfamilie haben eine physische sowie logische Verbindung. Grundsätzlich werden alle Spaltenqualifizierer in einer einzelnen Spaltenfamilie zusammen gespeichert, abgerufen und im Cache gespeichert. Daher ist eine Abfrage, die auf eine einzelne Spaltenfamilie zugreift, möglicherweise effizienter als eine Abfrage, die sich auf mehrere Spaltenfamilien erstreckt.

Sorgen Sie dafür, dass Ihre häufigsten Abfragen so effizient wie möglich sind. Dazu fragen Sie Daten aus so wenigen Spaltenfamilien wie möglich ab.

Nutzen Sie nicht die Atomarität einzelner Zeilen aus

Cloud Bigtable unterstützt keine Transaktionen, mit einer Ausnahme: Vorgänge auf einer einzelnen Zeile sind transaktional. Transaktionen sind also teuer. Daher leistet ein System, das auf Transaktionen zurückgreift, weniger als ein System, das dies nicht tut.

Das transaktionale Verhalten der Zeilen bei der Arbeit mit Zeitachsen nicht fördern. Änderungen an Daten in einer vorhandenen Zeile sollten als neue, separate Zeilen gespeichert und nicht in der vorhandenen Zeile geändert werden. Dieses Modell ist einfacher zu konstruieren und ermöglicht Ihnen, einen Verlauf der Aktivitäten zu speichern, ohne auf Spaltenversionen zurückzugreifen.

Beispiele für Schemadesigns

Jetzt wenden Sie Schemadesign-Muster an, um Beispiele für die folgenden Datenarten zu erstellen:

  • Finanzmarktdaten
  • Servermesswerte
  • Intelligente Energiezähler (Internet der Dinge)

Beachten Sie, dass dies nur Beispiele sind! Für das beste Schema für Ihre Zeitachsendaten müssen Sie berücksichtigen, welche Daten Sie speichern, und wie Sie die Daten abrufen möchten und dann die Design-Muster aus dem vorherigen Abschnitt anwenden.

Finanzmarktdaten

Dieses Beispiel nimmt eine hypothetische Datenmitteilung zum Aktienmarkt, die Informationen über eine imaginäre Aktie darstellt

Feld Beispieldaten
Börsenkürzel ZXZZT
Kaufen 600,55
Verkaufen 600,60
Höhe des Gebots 500
Verkaufen Umfang 1.500
Letzter Verkauf 600,58
Letzter Umfang 300
Zeit des Angebots 12:53:32.156
Zeit des Handels 12:53:32.045
Börse NASDAQ
Volumen 89000

Beachten Sie vor dem Start einige Hinweise zu den Nachrichten für Aktienmarktdaten:

  • Jede Nachricht fasst logisch getrennte Angebots- und Handelsdaten zusammen.

  • Es gibt eine relativ hohe Anzahl an Börsenkürzeln, nämlich mehrere tausend.

  • Ein paar hundert dieser Kürzel machen 90 % der erhaltenen Nachrichten aus, da relativ wenige Aktien aktiv gehandelt werden.

  • Nachrichten gehen sehr häufig ein, im Bereich von hundert bis zu zehntausend Nachrichten pro Sekunde; durchschnittlich sind es mehrere tausend pro Sekunde.

  • Typische Abfragen betreffen entweder Angebotsdaten oder Handelsdaten, aber nicht beide gleichzeitig.

  • Für Angebotsdaten wie auch für Handelsdaten enthält eine typische Abfrage folgende Elemente:

    • Eine Börse (wie NASDAQ)
    • Ein Börsenkürzel (wie ZXZZT)
    • Eine Start- und Endzeit

Jetzt können Sie die Tabelle für diesen Anwendungsfall erstellen:

Verwandte Daten in der gleichen Tabelle speichern, nicht verwandte Daten in verschiedenen Tabellen speichern

  • Speichern Sie Angebotsdaten in einer Tabelle mit dem Namen ANGEBOT.
  • Speichern Sie Handelsdaten in einer Tabelle mit dem Namen HANDEL.
  • Abfragen können beliebige Zeiträume umfassen, daher werden in jeder Zeile die Daten einer einzelnen Nachricht gespeichert.

Große Zeilen sind möglich, die Größe ist aber begrenzt

  • In jeder Zeile sind Daten von einer einzelnen Nachricht gespeichert. Dies ruft keine Bedenken bezüglich der Größe hervor.

Nutzen Sie nicht die Atomarität einzelner Zeilen aus

  • Jede Nachricht ist unabhängig, es gibt keine Bedenken.

Kurze, aber aussagekräftige Namen

  • Der Einfachheit halber nutzt dieses Beispiel die Felder der Nachricht als Namen, großgeschrieben mit entfernten Leerzeichen:

Diese Festlegungen führen zu folgendem Spaltenaufbau:

ANGEBOT-Beispieltabelle:

Spaltendaten
MD:KÜRZEL:ZXZZT MD:KAUFEN:
600,55
MD:VERKAUFEN:
600,60
MD:KAUFENUMFANG:
500
MD:VERKAUFENUMFANG:
1.500
MD:ANGEBOTZEIT:
1426535612156
MD:BÖRSE:
NASDAQ

HANDEL-Beispieltabelle:

Spaltendaten
MD:KÜRZEL:
ZXZZT
MD:LETZTERVERKAUF:
600,58
MD:LETZTERUMFANG:
300
MD:HANDELZEIT:
1426535612045
MD:BÖRSE:
NASDAQ
MD:VOLUMEN:
89.000

Als Nächstes den Zeilenschlüssel entwerfen:

Hohe und schmale Tabellen verwenden

  • Jede Zeile speichert Daten von einer Nachricht. Dies führt zu einer sehr hohen Anzahl an relativ schmalen Zeilen.

Zeilen den Vorzug vor Spaltenversionen geben

  • Spaltenversionen nur verwenden, wenn ausnahmsweise ein Wert unrichtig war.

Beim Zeilenschlüsseldesign die Abfragen berücksichtigen

  • QUOTE- und TRADE-Zeilenschlüssel können die gleiche Form haben.
  • Da es sich um eine Zeitachse handelt, kann man standardmäßig davon ausgehen, dass QUOTETIME Teil des Zeilenschlüssels wird.
  • Zur Abfrage nach Börse und Kürzel innerhalb eines festgelegten Zeitraums verwenden Sie die Werte von EXCHANGE, SYMBOL und QUOTETIME.
  • Deshalb stufen Sie EXCHANGE (als Code mit 6 Zeichen, Börsen mit weniger als 6 Zeichen werden mit Leerzeichen von rechts aufgefüllt), SYMBOL (als Code mit 5 Zeichen, Kürzel mit weniger als 5 Zeichen werden mit Leerzeichen von rechts aufgefüllt) und QUOTETIME (als Zahl mit 13 Stellen) hoch. Durch Einfügen von Leerzeichen für EXCHANGE und SYMBOL hat jeder Teil des Zeilenschlüssels garantiert den nötigen Offset.
  • Diese Werte ergeben insgesamt einen Zeilenschlüssel in der Form EXCHANGE + SYMBOL + QUOTETIME (z. B. NASDAQ#ZXZZT#1426535612156).

Heißlaufen durch Zeilenschlüssel verhindern

  • Durch EXCHANGE und SYMBOL an den vorderen Positionen im Zeilenschlüssel wird die Aktivität gleichmäßig verteilt.
  • Da sich 90 % der Nachrichten auf ein paar hundert Kürzel konzentrieren, besteht das Risiko des Heißlaufens. Bevor Sie weitere Änderungen vornehmen, sollten Sie das System einem Belastungstest unterziehen. Wenn diese Ballung der Nachrichten zu einer schlechten Leistung führt, können Sie die Aktivität mithilfe von Salting effektiver aufteilen.

Zeitstempel nur umkehren wenn nötig

  • In diesem Fall benötigen Sie keine umgekehrten Zeitstempel, da Abfragen nicht immer auf die jüngsten Daten abzielen.

Nach dieser Design-Übung haben Sie die folgenden Tabellen:

ANGEBOT-Beispieltabelle:

Zeilenschlüssel Spaltendaten
NASDAQ#ZXZZT#1426535612156 MD:KÜRZEL:
ZXZZT
MD:KAUFEN:
600,55
MD:VERKAUFEN:
600,60
MD:KAUFENUMFANG:
500
MD:VERKAUFENUMFANG:1
500
MD:ANGEBOTZEIT:
1426535612156
MD:BÖRSE:
NASDAQ

HANDEL-Beispieltabelle:

Zeilenschlüssel Spaltendaten
NASDAQ#ZXZZT#1426535612045 MD:KÜRZEL:
ZXZZT
MD:LETZTERVERKAUF:
600,58
MD:LETZTERUMFANG:
300
MD:HANDELZEIT:
1426535612045
MD:BÖRSE:
NASDAQ
MD:VOLUMEN:
89.000

Diese Tabellen wachsen um Hunderte von Millionen Zeilen pro Tag. Cloud Bigtable bewältigt dies ohne Probleme.

Servermesswerte

Das folgende Beispiel verwendet ein hypothetisches System zur Serverüberwachung, das viele verschiedene Messwerte (wie die CPU-Nutzung pro Kern, die Speichernutzung und die Laufwerknutzung) von einer Vielzahl von Geräten sammelt. Sie werden in diesem Beispiel mehrere verschiedene Ausführungen des Schemas kennenlernen.

Sie können die folgenden Annahmen über die Daten treffen:

  • Sammelt 100 Messwerte pro Gerät.
  • Sammelt Messwerte von 100.000 Geräten.
  • Messwerte werden alle 5 Sekunden gesammelt.
  • Typische Abfragen sehen so aus:

    • Messwerte für ein bestimmtes Gerät und eine Start- und Endzeit
    • Die letzten Messwerte für alle Geräte

Anhand dieses Anwendungsfalls können Sie die Tabelle entwerfen:

Ausführung 1

Verwandte Daten in der gleichen Tabelle speichern, nicht verwandte Daten in verschiedenen Tabellen speichern

  • Sie speichern Messwerte in einer Tabelle mit dem Namen METRIC.
  • Es gibt mehrere Kategorien von Messwerten. Sie gruppieren diese mithilfe geeigneter Spaltenfamilien.
  • Abfragen können beliebige Zeiträume umfassen. Es wird daher in jeder Zeile ein einzelner Satz von Messwerten von einem Gerät zu einem bestimmten Zeitpunkt gespeichert.

Große Zeilen sind möglich, die Größe ist aber begrenzt

  • In jeder Zeile wird ein einzelner Satz Messwerte gespeichert. Dies gibt keinen Anlass zur Besorgnis wegen der Größe.

Nutzen Sie nicht die Atomarität einzelner Zeilen aus

  • Nicht auf die Atomarität der Zeilen in Ihrem Schema zurückgreifen.

Kurze, aber aussagekräftige Namen

  • Der Einfachheit halber werden die Feldnamen der Messwerte, großgeschrieben und ohne Leerzeichen, als Namen der Spaltenqualifizierer verwendet.

Diese Festlegungen führen zu folgendem Spaltenaufbau:

Spaltendaten
MESSWERT:
HOSTNAME:
server1.bbb.com
MESSWERT:
CPU/CPU1_USR:
0,02
MESSWERT:
CPU/CPU1_NICE:
0,00
MESSWERT:
IO/BLK_READ:
253453634
MESSWERT:
MIO/BLK_WRTN:
657365234

Als Nächstes entwerfen Sie den Zeilenschlüssel beruhend auf den Mustern:

Hohe und schmale Tabellen verwenden

  • Jede Zeile der Tabelle speichert eine Reihe von Messwerten für ein Gerät. Dies führt zu einer hohen Anzahl an Zeilen.

Zeilen den Vorzug vor Spaltenversionen geben

  • Sie verwenden keine Spaltenversionen

Beim Zeilenschlüsseldesign die Abfragen berücksichtigen

  • Da dies eine Zeitachse ist, nehmen Sie den Zeitstempel TS in den Zeilenschlüssel auf.
  • Wenn Sie Messwerte eines bestimmten Geräts für einen bestimmten Zeitraum abrufen möchten, fragen Sie einen Zeilenbereich mithilfe von HOSTNAME und TS ab.
  • Das Abrufen der letzten Messwerte für alle Geräte ist ein komplexer Vorgang. Dazu können Sie nicht einfach den Zeitstempel umkehren und n Zeilen scannen, da damit nicht garantiert ist, dass auch wirklich jedes Gerät erfasst wird.

Damit stehen Sie beim Entwerfen des Zeilenschlüssels vor einem Problem. Die Lösung hier ist Denormalisieren. Sie erstellen eine separate Tabelle mit dem Namen CURRENT_METRIC, die die neuesten Versionen der aufgerufenen Messwerte enthält. Diese aktualisieren Sie immer dann, wenn Sie METRIC aktualisieren. Wenn Sie die vorhandenen Messwerte für ein Gerät aktualisieren, überschreiben Sie einfach die Zeilen für diese Maschine.

Passen Sie als Nächstes das ursprüngliche Design an:

Ausführung 2

Verwandte Daten in der gleichen Tabelle speichern, nicht verwandte Daten in verschiedenen Tabellen speichern

  • Sie speichern Messwerte in einer Tabelle mit dem Namen METRIC.
  • Sie speichern die letzte Version der Messwerte in einer Tabelle mit dem Namen CURRENT_METRIC.
  • Alles Weitere entspricht Ausführung 1.

Große Zeilen sind möglich, die Größe ist aber begrenzt

  • Bleibt wie in Ausführung 1.

Nutzen Sie nicht die Atomarität einzelner Zeilen aus

  • Sie greifen auf die Atomarität der Zeilen zur Aktualisierung der Daten für jedes Gerät in CURRENT_METRIC zurück. Dies ist eine einfache Zeilenmutation mit wenig Konfliktpotential, daher wird sie keine Probleme verursachen.

Kurze, aber aussagekräftige Namen

  • Bleibt wie in Ausführung 1.

Als Nächstes entwerfen Sie den Zeilenschlüssel beruhend auf den Mustern:

Hohe und schmale Tabellen verwenden

  • In beiden Tabellen speichert jede Zeile der Tabelle jeweils einen Satz Messwerte für ein Gerät. Dies führt zu einer sehr hohen Anzahl an Zeilen.

Zeilen den Vorzug vor Spaltenversionen geben

  • Bleibt wie in Ausführung 1.

Beim Zeilenschlüsseldesign die Abfragen berücksichtigen

  • Da dies eine Zeitachse ist, nehmen Sie den Zeitstempel TS in den Zeilenschlüssel auf. Zum Abrufen von Messwerten eines bestimmten Geräts für einen bestimmten Zeitraum fragen Sie einen Zeilenbereich von METRIC mithilfe von HOSTNAME und TS ab.
  • Deshalb stufen Sie HOSTNAME zum Zeilenschlüssel hoch und verwenden einen Zeilenschlüssel in der Form HOSTNAME + TS.
  • Um die neuesten Messwerte für bestimmte Geräte zu finden, scannen Sie CURRENT_METRIC, gefiltert nach dem Zeilenschlüsselpräfix oder HOSTNAME dieser Geräte.
  • Um die neuesten Messwerte für alle Geräte zu finden, scannen Sie CURRENT_METRIC, ohne einen Zeilenschlüssel anzugeben.
  • Sie benötigen deshalb keine zusätzlichen Felder im Zeilenschlüssel. Der Zeilenschlüssel hat die einfache Form HOSTNAME + TS. Dies führt zu einem einfachen, leicht verständlichen Schema, mit dem sich Tabellen effizient fragmentieren lassen.
  • In der Tabelle CURRENT_METRIC ist der Schlüssel der Einfachheit halber wieder HOSTNAME, da Sie den Zeitstempel nicht mehr benötigen.

    Beispiel für den Zeilenschlüssel METRIC: server1.aaa.bbb.com#1426535612045

    Beispiel für den Zeilenschlüssel CURRENT_METRIC: server1.aaa.bb.com

Heißlaufen durch Zeilenschlüssel verhindern

  • Sowohl für METRIC als auch für CURRENT_METRIC gibt es keine Bedenken bezüglich des Heißlaufens. Der Hostname am Anfang des Zeilenschlüssels sorgt dafür, dass die Aktivität auf Regionen verteilt wird.

Zeitstempel nur umkehren wenn nötig

  • Sie speichern Daten der jüngsten Messwerte in einer separaten Tabelle, damit Sie Zeitstempel nicht umkehren müssen.

Nach der Designübung haben Sie Folgendes:

Tabelle METRIC:

Zeilenschlüssel Spaltendaten
server1.bbb.com#1426535612045 MESSWERT:
CPU/CPU1_USR:
0,02
MESSWERT:
CPU/CPU1_NICE:
0,00
MESSWERT:
IO/BLK_READ:
253453634
MESSWERT:
MIO/BLK_WRTN:
657365234

Diese Tabellen wachsen um ungefähr 2 Milliarden Zeilen pro Tag. Cloud Bigtable bewältigt dies ohne Probleme.

Tabelle CURRENT_METRIC:

Zeilenschlüssel Spaltendaten
server1.bbb.com MESSWERT:
CPU/CPU1_USR:
0,02
MESSWERT:
CPU/CPU1_NICE:
0,00
MESSWERT:
IO/BLK_READ:
253453634
MESSWERT:
MIO/BLK_WRTN:
657365234

Intelligente Energiezähler (Internet der Dinge)

Dies ist ein Beispiel zu einem hypothetischen IdD-Szenario, in dem intelligente Energiezähler regelmäßig Sensormesswerte an ein zentralisiertes System schicken. Sie werden in diesem Beispiel wieder mehrere verschiedene Ausführungen des Schemas kennenlernen.

Sie können die folgenden Annahmen über die Daten treffen:

  • Es sind 10 000 000 einsatzbereite Messgeräte vorhanden.
  • Jedes Messgerät sendet alle 15 Minuten einen Messwert.
  • Die ID des Messgeräts ist eine einzigartige numerische ID.
  • Typische Abfragen sehen so aus:

    • Alle Daten eines bestimmten Messgeräts von einem Tag
    • Alle Daten eines Tages

Anhand dieses Anwendungsfalls können Sie die Tabelle entwerfen:

Verwandte Daten in der gleichen Tabelle speichern, nicht verwandte Daten in verschiedenen Tabellen speichern

  • Sie speichern die Sensordaten in einer Tabelle mit dem Namen SENSOR
  • Abfragen erfolgen täglich, sodass in jeder Zeile Daten von einem Messgerät und einem Tag gespeichert sind

Große Zeilen sind möglich, die Größe ist aber begrenzt

  • Jede Zeile enthält Daten von einem Messgerät und einem Tag. Die insgesamt 96 Spalten (24 Stunden pro Tag * 60 Minuten pro Stunde / 1 Lesung alle 15 Minuten) geben keinen Anlass zur Besorgnis wegen der Größe.

Nutzen Sie nicht die Atomarität einzelner Zeilen aus

  • Sie nutzen die Atomarität der Zeilen, weil die Daten beim Empfang zu der entsprechenden täglichen Zeile addiert werden. Dies ist eine einfache Zeilenmutation mit wenig Konfliktpotential, daher wird sie keine Probleme verursachen.

Kurze, aber aussagekräftige Namen

  • ID zum Speichern der Messgerät-ID (eine eindeutige Ganzzahl).
  • Eine Reihe von Spalten mit den Namen 0000 bis 2345 für die 96 Werte, die tagsüber alle 15 Minuten erfasst werden. Dieses Schema wurde gewählt, damit sich bei Bedarf andere Intervalle als alle 15 Minuten einstellen lassen.

Diese Festlegungen führen zu folgendem Spaltenaufbau:

Ausführung 1

Spaltendaten
GERÄT:ID:987654 METER:0000:
12,34
METER:0015:
13,45
METER:2330:
27,89
METER:2345:
28,90

Als Nächstes den Zeilenschlüssel entwerfen:

Hohe und schmale Tabellen verwenden

  • In jeder Zeile werden Daten für einen Tag gespeichert, wie oben beschrieben.

Zeilen den Vorzug vor Spaltenversionen geben

  • Spaltenversionen nur verwenden, wenn ausnahmsweise ein Wert unrichtig war.

Beim Zeilenschlüsseldesign die Abfragen berücksichtigen

  • Da es sich um eine Zeitachse handelt, nehmen Sie DATE in den Zeilenschlüssel auf. Weil nur eine Tagesgenauigkeit erforderlich ist, sind die letzten fünf Stellen des Zeitstempels null und werden daher weggelassen.
  • Zur Abfrage eines bestimmten Messgeräts für einen bestimmten Tag rufen Sie eine einzelne Zeile mithilfe von METER und DATE ab.
  • Rufen Sie eine Reihe an Zeilen mit DATE ab, um alle Messgeräte für einen bestimmten Tag abzufragen.
  • Sie stufen deshalb DATE (als Zahl mit 8 Stellen) und METER (als Zahl mit 10 Stellen, mit der Geräte-ID am Anfang der 10 Stellen, sodass eine Milliarde Geräte bei Einhaltung der lexikografischen Ordnung möglich sind) hoch.
  • Betrachtet man beide Abfragen, muss der Zeilenschlüssel die Form DATE + METER haben, z. B. |20170726|0000987654|.

An dieser Stelle fällt Ihnen vielleicht ein Problem auf: Zu Beginn jedes Tages werden alle Messgeräte auf einen einzigen Knoten schreiben, da das Datum am Anfang des Zeilenschlüssels steht. Mit 10 Millionen Messgeräten ist die Wahrscheinlichkeit hoch, dass dieses Problem jeden Tag die Leistung beeinträchtigt. Die Lösung liegt in einer besseren Abfrage der Messdaten für einen bestimmten Tag. Wenn Sie jeden Abend eine Einzelabfrage ausführen und die Ergebnisse als neue Tabelle mit dem Namen SENSOR_YYYYMMDD speichern, brauchen Sie Ihren Zeilenschlüssel für die Abfragen nach Datum nicht optimieren.

Wir optimieren, um das Problem zu lösen:

Ausführung 2

Verwandte Daten in der gleichen Tabelle speichern, nicht verwandte Daten in verschiedenen Tabellen speichern

  • Sie speichern die Sensordaten in einer Tabelle mit dem Namen SENSOR.
  • Abfragen werden täglich ausgeführt, d. h., in einer Zeile werden Daten von einem Messgerät und einem Tag gespeichert.
  • Sie führen über Nacht eine Batch-Abfrage aus, die eine weitere Tabelle mit dem Namen SENSOR_YYYYMMDD für das Datum generiert, um alle Messdaten für dieses Datum zu speichern.

Große Zeilen sind möglich, die Größe ist aber begrenzt

  • Bleibt wie in Ausführung 1.

Nutzen Sie nicht die Atomarität einzelner Zeilen aus

  • Bleibt wie in Ausführung 1.

Kurze, aber aussagekräftige Namen

  • Bleibt wie in Ausführung 1.

All dies zusammengeführt ergibt eine Beispielzeile, die sowohl für die Tabelle SENSOR als auch für die Tabellen SENSOR_YYYYMMDD so aussieht:

Spaltendaten
GERÄT:ID:987654 METER:0000:
12,34
METER:0015:
13,45
METER:2330:
27,89
METER:2345:
28,90

Als Nächstes den Zeilenschlüssel entwerfen:

Hohe und schmale Tabellen verwenden

  • Bleibt wie in Ausführung 1.

Zeilen den Vorzug vor Spaltenversionen geben

  • Bleibt wie in Ausführung 1.

Beim Zeilenschlüsseldesign die Abfragen berücksichtigen

  • Da es sich um eine Zeitachse handelt, nehmen Sie DATE in den Zeilenschlüssel auf.
  • Zur Abfrage eines bestimmtes Messgeräts für einen bestimmten Tag rufen Sie eine einzelne Zeile mithilfe von METER und DATE ab.
  • Sie stufen deshalb DATE (als Zahl mit 8 Stellen) und METER (als Zahl mit 10 Stellen, mit der Geräte-ID am Anfang der 10 Stellen, sodass eine Milliarde Geräte bei Einhaltung der lexikografischen Ordnung möglich sind) hoch.
  • Der Zeilenschlüssel muss die Form METER + DATE haben (z. B. "0000987654#20170726"), damit er der Abfrage genügt und zu einer optimalen Verteilung der Aktivität über die Knoten führt.
  • Außerdem führen Sie einmal täglich eine Batch-Abfrage durch, die die gesamte Tabelle scannt und die Daten vom vorherigen Tag in einer neuen Tabelle mit dem Namen SENSOR_YYYYMMDD speichert, wobei YYYYMMDD das Datum des vorherigen Tages ist.

Heißlaufen durch Zeilenschlüssel verhindern

  • Heißlaufen ist kein Problem für die SENSOR-Tabelle. Schreibvorgänge werden gleichmäßig verteilt, da METER im Zeilenschlüssel an der ersten Position steht.
  • Heißlaufen ist kein Problem für die SENSOR_YYYYMMDD-Tabellen. Jede Tabelle wird nur einmal als Batch-Abfrage erstellt, bei der die Leistung weniger wichtig ist. Zum Erstellen dieser Tabellen ist allerdings ein kompletter Scan von SENSOR erforderlich. Sie sollten deshalb eher die SENSOR_YYYYMMDD-Tabellen erstellen, wenn es nur wenige andere Abfragen der SENSOR-Tabelle gibt.

Zeitstempel nur umkehren wenn nötig

  • In diesem Fall müssen Sie die Zeitstempel nicht umkehren.

Nach der Design-Übung haben Sie Folgendes sowohl für die SENSOR-Tabelle als auch für die SENSOR_YYYYMMDD-Tabellen:

Zeilenschlüssel Spaltendaten
0000987654#20170726 GERÄT:ID:987654 METER:0000:
12,34
METER:0015:
13,45
METER:2330:
27,89
METER:2345:
8,90

Die Tabelle wächst um etwas weniger als zehn Millionen Zeilen pro Tag. Cloud Bigtable bewältigt dies ohne Probleme.

Nächste Schritte