Bigtable

Bigtable ist eine dünnbesetzte Tabelle, die auf Milliarden von Zeilen und Tausenden von Spalten skaliert werden kann. Dadurch können Sie Terabyte oder sogar Petabyte an Daten speichern. Ein einzelner Wert in jeder Zeile ist indexiert. Dieser Wert wird als Zeilenschlüssel bezeichnet. Bigtable eignet sich ideal zum Speichern großer Mengen von Einzeldaten mit niedriger Latenz. Es unterstützt einen hohen Lese- und Schreibdurchsatz bei niedriger Latenz und ist eine ideale Datenquelle für MapReduce-Vorgänge.

Anwendungen können über mehrere Clientbibliotheken, darunter eine unterstützte Erweiterung der Apache HBase-Bibliothek für Java, auf Bigtable zugreifen. Daher fügt es sich in das bestehende Apache-System der Open-Source-Software für Big Data ein.

Die leistungsstarken Backend-Server von Bigtable bieten einige entscheidende Vorteile gegenüber einer selbstverwalteten HBase-Installation:

  • Unglaublich hohe Skalierbarkeit. Bigtable skaliert direkt proportional zur Anzahl der Maschinen in Ihrem Cluster. Eine selbstverwaltete HBase-Installation hat einen Engpass im Design, der die Leistung begrenzt, nachdem ein bestimmter Grenzwert erreicht wurde. Bigtable hat diesen Engpass nicht, sodass Sie Ihren Cluster so skalieren können, dass er mehr Lese- und Schreibvorgänge bewältigen kann.
  • Einfache Verwaltung. Bigtable verarbeitet Aktualisierungen und Neustarts transparent und sorgt automatisch für die Langlebigkeit der Daten. Fügen Sie der Instanz einfach einen zweiten Cluster hinzu, um die Daten zu replizieren. Die Replikation wird dann automatisch gestartet. Sie müssen keine Replikate oder Regionen mehr verwalten. Sie müssen lediglich Ihre Tabellenschemas entwerfen und Bigtable übernimmt den Rest für Sie.
  • Größenänderung des Clusters ohne Ausfallzeiten. Sie können die Größe eines Bigtable-Clusters für einige Stunden erhöhen, um eine große Auslastung zu bewältigen, und dann die Größe des Clusters wieder reduzieren – ohne Ausfallzeiten. Nachdem Sie die Größe eines Clusters geändert haben, dauert es unter Last normalerweise nur wenige Minuten, bis Bigtable die Leistung auf alle Knoten in Ihrem Cluster verteilt.

Einsatzmöglichkeit

Bigtable eignet sich ideal für Anwendungen, die einen hohen Durchsatz und eine hohe Skalierbarkeit für Schlüssel/Wert-Paare benötigen, bei denen jeder Wert in der Regel nicht größer als 10 MB ist. Bigtable eignet sich außerdem hervorragend als Speicher-Engine für Batch-MapReduce-Vorgänge, Streamverarbeitung/-analysen und Anwendungen für maschinelles Lernen.

Sie können Bigtable verwenden, um die folgenden Datentypen zu speichern und abzufragen:

  • Zeitachsendaten wie CPU- und Speicherauslastung im Zeitablauf für mehrere Server
  • Marketingdaten wie Einkaufsverlauf und Kundenpräferenzen
  • Finanzdaten wie Transaktionsverlauf, Aktienkurse und Wechselkurse
  • Daten des Internets der Dinge wie Nutzungsberichte von Energiezählern und Haushaltsgeräten
  • Grafikdaten wie Informationen darüber, wie Nutzer miteinander verbunden sind

Bigtable-Speichermodell

Bigtable speichert Daten in äußerst skalierbaren Tabellen, von denen jede eine geordnete Zuordnung von Schlüssel/Wert-Paaren darstellt. Die Tabelle besteht aus Zeilen, von denen jede typischerweise eine einzelne Entität beschreibt, und Spalten, die für jede Zeile individuelle Werte beinhalten. Jede Zeile wird von einem einzelnen Zeilenschlüssel indexiert und Spalten, die sich aufeinander beziehen, sind normalerweise in einer Spaltenfamilie gruppiert. Jede Spalte ist durch eine Kombination aus der Spaltenfamilie und einem Spaltenqualifizierer identifizierbar, bei dem es sich um einen eindeutigen Namen innerhalb der Spaltenfamilie handelt.

Jeder Zeilen-/Spaltenschnittpunkt kann mehrere Zellen enthalten. Jede Zelle enthält eine eindeutige Zeitstempelversion der Daten für diese Zeile und Spalte. Durch Speichern mehrerer Zellen in einer Spalte wird erfasst, wie sich die gespeicherten Daten für diese Zeile und Spalte im Laufe der Zeit geändert haben. Bigtable-Tabellen sind dünnbesetzt, wenn eine Spalte in einer bestimmten Zeile nicht verwendet wird, belegt sie keinen Platz.

Grafik: Bigtable-Speichermodell

In dieser Abbildung gibt es ein paar Dinge zu beachten:

  • Spalten können in einer Zeile unbenutzt sein.
  • Jede Zelle in einer bestimmten Zeile und Spalte hat einen eindeutigen Zeitstempel (t).

Bigtable-Architektur

Das folgende Diagramm zeigt eine vereinfachte Version der Gesamtarchitektur von Bigtable:

Gesamtarchitektur von Bigtable.

Wie im Diagramm gezeigt, laufen alle Clientanfragen durch einen Frontend-Server, bevor sie an einen Knoten in Bigtable gesendet werden. Im ursprünglichen Bigtable-Artikel werden diese Knoten als "Tablet-Server" (Tabellenreihenserver) bezeichnet. Die Knoten sind in einem Bigtable-Cluster organisiert, der zu einer Bigtable-Instanz, einem Container für den Cluster, gehört.

Jeder Knoten im Cluster verarbeitet einen Teil der Anfragen an den Cluster. Durch das Hinzufügen von Knoten zu einem Cluster können Sie die Anzahl der gleichzeitigen Anfragen erhöhen, die der Cluster verarbeiten kann. Durch das Hinzufügen von Knoten wird auch der maximale Durchsatz für den Cluster erhöht. Wenn Sie die Replikation durch Hinzufügen zusätzlicher Cluster aktivieren, können Sie auch verschiedene Arten von Traffic an verschiedene Cluster senden. Wenn dann ein Cluster nicht mehr verfügbar ist, kann ein Failover auf einen anderen Cluster durchgeführt werden.

Eine Bigtable-Tabelle ist in Blöcke von fortlaufenden Zeilen unterteilt, die Tabellenreihen genannt werden. (Tabellenreihen sind HBase-Regionen ähnlich.) Tabellenreihen werden in Colossus, dem Dateisystem von Google, im SSTable-Format gespeichert. Eine SSTable stellt eine dauerhafte, geordnete unveränderliche Map von Schlüsseln und Karten dar, in der sowohl Schlüssel als auch Werte aus beliebigen Byte-Strings bestehen. Jede Tabellenreihe ist einem bestimmten Bigtable-Knoten zugeordnet. Neben den SSTable-Dateien werden alle Schreibvorgänge im gemeinsamen Log von Colossus gespeichert, sobald sie von Bigtable bestätigt wurden. Dadurch erhöht sich die Langlebigkeit.

Wichtig: Daten werden nie in Knoten von Bigtable selbst gespeichert. Jeder Knoten enthält Verweise auf einen in Colossus gespeicherten Satz von Tabellenreihen. Deshalb gilt:

  • Der Austausch der Tabellenreihen von einem Knoten auf einen anderen erfolgt schnell, da die tatsächlichen Daten nicht kopiert werden. Bigtable aktualisiert einfach die Zeiger für jeden Knoten.
  • Die Wiederherstellung nach einem Ausfall eines Bigtable-Knotens ist schnell, da nur Metadaten auf den Ersatzknoten migriert werden müssen.
  • Wenn ein Knoten in Bigtable fehlschlägt, gehen keine Daten verloren.

Weitere Informationen zum Arbeiten mit diesen grundlegenden Bausteinen finden Sie unter Instanzen, Cluster und Knoten.

Load Balancing

Jede Zone in Bigtable wird von einem Primärvorgang verwaltet, der die Arbeitslast und das Datenvolumen im Cluster ausgleicht. Der Vorgang halbiert ausgelastete/große Tabellenreihen und fügt kleine Tabellenreihen oder solche mit weniger Zugriffen zusammen, indem er sie nach Bedarf auf die Knoten aufteilt. Wenn eine bestimmte Tabellenreihe Trafficspitzen erfährt, halbiert Bigtable die Tabellenreihe und verschiebt eine der neuen Tabellenreihen auf einen anderen Knoten. Bigtable verwaltet das Aufteilen, Zusammenführen und Ausgleichen automatisch, sodass Sie Ihre Tabellenreihen nicht manuell verwalten müssen. Unter Leistung verstehen finden Sie weitere Informationen zu diesem Vorgang.

Für die beste Schreibleistung von Bigtable ist es wichtig, Schreibvorgänge so gleichmäßig wie möglich auf Knoten zu verteilen. Eine Art, dieses Ziel zu erreichen, besteht darin, Zeilenschlüssel zu verwenden, die keiner vorhersehbaren Ordnung folgen. Nutzernamen sind beispielsweise mehr oder weniger gleichmäßig im Alphabet verteilt, sodass ein Nutzername am Anfang des Zeilenschlüssels normalerweise für eine gleichmäßige Verteilung der Schreibvorgänge sorgt.

Gleichzeitig ist es sinnvoll, zusammengehörige Zeilen so zu gruppieren, dass sie nebeneinander liegen, wodurch es viel effizienter ist, mehrere Zeilen gleichzeitig zu lesen. Wenn Sie beispielsweise verschiedene Arten von Wetterdaten über einen Zeitraum speichern, könnte der Zeilenschlüssel aus dem Ort, an dem die Daten gesammelt wurden, und aus einem Zeitstempel bestehen (Beispiel: WashingtonDC#201803061617). Dieser Zeilenschlüsseltyp würde alle Daten von einem Ort in einen zusammenhängenden Bereich von Zeilen gruppieren. Für andere Orte würde der Zeilenschlüssel mit einer anderen Kennzeichnung beginnen. Wenn an vielen Orten Daten im gleichen Rhythmus gesammelt werden, wären sie immer noch gleichmäßig über alle Tabellenreihen verteilt.

Weitere Information über die Auswahl eines passenden Zeilenschlüssels für Ihre Daten finden Sie unter Zeilenschlüssel wählen.

Unterstützte Datentypen

Bigtable behandelt alle Daten für die meisten Anwendungen als unverarbeitete Bytestrings. Die einzige Situation, in der Bigtable versucht, den Typ zu ermitteln, ist bei Inkrementierungsvorgängen, bei denen das Ziel eine als 8-Byte-Big-Endian-Wert codierte 64-Bit-Ganzzahl sein muss.

Speicher- und Laufwerksauslastung

In den folgenden Abschnitten wird dargestellt, wie mehrere Komponenten von Bigtable die Speicher- und Laufwerksauslastung Ihrer Instanz beeinflussen.

Nicht verwendete Spalten:

Spalten, die nicht in einer Bigtable-Zeile verwendet werden, belegen keinen Speicherplatz in dieser Zeile. Jede Zeile ist im Wesentlichen eine Sammlung von Schlüssel/Wert-Paaren, wobei der Schlüssel eine Kombination aus Spaltenfamilie, Spaltenqualifizierer und Zeitstempel darstellt. Wenn eine Zeile keinen Wert für eine bestimmte Spalte beinhaltet, ist das Schlüssel/Wert-Paar einfach nicht vorhanden.

Spaltenqualifizierer

Spaltenqualifizierer belegen Platz in einer Zeile, da jeder Spaltenqualifizierer, der in einer Zeile genutzt wird, in dieser Zeile gespeichert ist. Daher sind Spaltenqualifizierer oft effizient als Daten.

Verdichtungen

Bigtable schreibt Ihre Tabellen in regelmäßigen Abständen neu, um gelöschte Einträge zu entfernen und die Daten neu anzuordnen, damit die Lese- und Schreibvorgänge effizienter werden. Dieser Prozess wird als Verdichtung bezeichnet. Es gibt keine Konfigurationseinstellungen für Verdichtungen. Bigtable verdichtet Ihre Daten automatisch.

Mutationen und Löschungen

Mutationen oder Änderungen beanspruchen mehr Speicherplatz, da Mutationen von Bigtable sequenziell gespeichert und nur von Zeit zu Zeit verdichtet werden. Wenn Bigtable eine Tabelle verdichtet, werden alle Werte entfernt, die nicht mehr benötigt werden. Wenn Sie den Wert in einer Zelle aktualisieren, sind für einen gewissen Zeitraum sowohl der alte als auch der neue Wert auf dem Laufwerk gespeichert, bis die Daten verdichtet werden.

Löschungen erfordern ebenfalls zusätzlichen Speicherplatz, zumindest für eine kurze Zeit, da Löschungen genau genommen ein spezieller Mutationstyp sind. Bis die Tabelle verdichtet wird, benötigt das Löschen also mehr Platz, nicht weniger.

Datenkompression

Bigtable komprimiert Ihre Daten automatisch mithilfe eines intelligenten Algorithmus. Sie können keine Einstellungen für die Kompression Ihrer Daten festlegen. Es ist jedoch nützlich zu wissen, wie Daten gespeichert werden müssen, damit sie effizient komprimiert werden können.

  • Zufällige Daten können nicht so effizient komprimiert werden wie Daten, die einem Muster folgen. Unter Daten, die einem Muster folgen, fallen Texte wie die Seite, die Sie gerade lesen.
  • Komprimierung funktioniert am besten, wenn identische Werte nah beieinander liegen, entweder in derselben oder in aneinandergrenzenden Zeilen. Wenn Sie Ihre Zeilenschlüssel so anordnen, dass Zeilen mit identischen Datenblöcken nebeneinander liegen, können die Daten effizient komprimiert werden.
  • Bigtable komprimiert Werte bis zu 1 MiB. Wenn Sie Werte speichern, die größer als 1 MiB sind, komprimieren Sie sie, bevor Sie sie in Bigtable schreiben. So können Sie CPU-Zyklen, Serverarbeitsspeicher und Netzwerkbandbreite sparen.

Datenhaltbarkeit

Wenn Sie Bigtable verwenden, werden Ihre Daten in Colossus, dem internen, äußerst langlebigen Datensystem von Google, gespeichert. Dabei werden Speichergeräte in Googles Datenzentren verwendet. Sie müssen keinen HDFS-Cluster oder ein anderes Datensystem betreiben, wenn Sie Bigtable nutzen. Hinter den Kulissen nutzt Google proprietäre Speichermethoden, um eine Datenlanglebigkeit zu erreichen, die über den Werten liegt, die eine standardmäßige dreifache HDFS-Replikation bietet.

Die Langlebigkeit wird bei der Verwendung der Replikation weiter verbessert. Bigtable verwaltet eine separate Kopie Ihrer Daten an dem Standort, den Sie für jeden Cluster einer replizierten Instanz auswählen.

Konsistenzmodell

Single-Cluster-Bigtable-Instanzen bieten strikte Konsistenz. Standardmäßig bieten Instanzen mit mehr als einem Cluster Eventual Consistency. Sie können jedoch für einige Anwendungsfälle eine Read-Your-Writes-Konsistenz oder strikte Konsistenz konfigurieren, je nach den Einstellungen für Arbeitslast und Anwendungsprofil.

Sicherheit

Der Zugriff auf Ihre Bigtable-Tabellen wird von Ihrem Google Cloud-Projekt und den IAM-Rollen (Identitäts- und Zugriffsverwaltung) gesteuert, die Sie Nutzern zuweisen. Sie können beispielsweise IAM-Rollen zuweisen, die verhindern, dass einzelne Nutzer Tabellen lesen, in Tabellen schreiben oder neue Instanzen erstellen. Wenn jemand keinen Zugriff auf Ihr Projekt hat oder keine IAM-Rolle mit den entsprechenden Berechtigungen für Bigtable besitzt, kann er auf keine Ihrer Tabellen zugreifen.

Sie können den Zugriff auf Tabellendaten auch steuern, indem Sie eine autorisierte Ansicht einer Tabelle erstellen, die eine Teilmenge der Tabellendaten darstellt. Anschließend können Sie einigen Nutzern autorisierte Berechtigungen auf Datenansichtsebene gewähren, ohne ihnen Berechtigungen auf Tabellenebene zu gewähren.

Sie können die Sicherheit auf Projekt-, Instanz-, Tabellen- oder autorisierten Ansichtsebene verwalten. Bigtable unterstützt keine Sicherheitsbeschränkungen auf Zeilen-, Spalten- oder Zellenebene.

Verschlüsselung

Standardmäßig werden alle in Google Cloud gespeicherten Daten, einschließlich der Daten in Bigtable-Tabellen, inaktiv verschlüsselt. Dies geschieht mit dens gleichen gehärteten Schlüsselverwaltungssystemen, die wir für unsere eigenen verschlüsselten Daten verwenden.

Wenn Sie mehr Kontrolle über die Schlüssel haben möchten, mit denen Ihre Bigtable-Daten verschlüsselt werden, können Sie vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK) verwenden.

Sicherungen

Mit Bigtable-Sicherungen können Sie eine Kopie des Schemas und der Daten einer Tabelle speichern und diese zu einem späteren Zeitpunkt in einer neuen Tabelle wiederherstellen. Mithilfe von Sicherungen und Sicherungskopien können Sie Daten in einer neuen Tabelle in einer beliebigen Region oder einem Projekt wiederherstellen, in dem sich eine Bigtable-Instanz befindet, unabhängig davon, wo sich die Quelltabelle befindet.

Change Data Capture

Bigtable bietet Change Data Capture (CDC) in Form von Änderungsstreams. Mit Änderungsstreams können Sie Datenänderungen erfassen und in eine Tabelle streamen, sobald die Änderungen eintreten. Sie können einen Änderungsstream mit einem Dienst wie Dataflow lesen, um Anwendungsfälle wie Datenanalyse, Audits, Archivierungsanforderungen und das Auslösen einer nachgelagerten Anwendungslogik zu unterstützen. Weitere Informationen finden Sie in der Übersicht über Änderungsstreams.

Routing mit Anwendungsprofilen anfordern

Mit den Routingrichtlinien für Anwendungsprofil können Sie steuern, welche Cluster eingehende Anfragen von Ihren Anwendungen verarbeiten. Zu den Optionen für Routingrichtlinien gehören:

  • Single-Cluster-Routing:Sendet alle Anfragen an einen einzelnen Cluster.
  • Multi-Cluster-Routing an einen beliebigen Cluster: Sendet Anfragen an den nächsten verfügbaren Cluster in einer Instanz.
  • Clustergruppen-Routing: Sendet Anfragen an den nächstgelegenen verfügbaren Cluster innerhalb einer ausgewählten Clustergruppe in einer Instanz.

Andere Speicherungs- und Datenbankoptionen

Bigtable ist keine relationale Datenbank. SQL-Abfragen, Joins oder mehrzeilige Transaktionen werden nicht unterstützt.

  • Wenn Sie die volle SQL-Unterstützung für ein System zur Online-Transaktionsverarbeitung (OLTP) benötigen, verwenden Sie Spanner oder Cloud SQL.
  • Wenn Sie interaktive Abfragen in einem System für die analytische Onlineverarbeitung (OLAP) benötigen, ist BigQuery möglicherweise das Richtige für Sie.
  • Wenn Sie stark strukturierte Objekte in einer Dokumentendatenbank mit Unterstützung für ACID-Transaktionen und SQL-ähnliche Abfragen speichern müssen, sollten Sie Firestore in Betracht ziehen.
  • Für die speicherinterne Datenspeicherung mit niedriger Latenz eignet sich Memorystore.
  • Wenn Sie Daten zwischen Nutzern in Echtzeit synchronisieren möchten, verwenden Sie Firebase Realtime Database.

Weitere Informationen zu anderen Datenbankoptionen finden Sie in der Übersicht der Datenbankdienste. Google Cloud bietet außerdem verschiedene Speicheroptionen.

Nächste Schritte