Bigtable

Bigtable ist eine dünn besetzte Tabelle, die auf Milliarden von Zeilen und Tausende von Spalten skaliert werden kann. Dadurch können Datenmengen im Terabyte- oder sogar Petabytebereich gespeichert werden. Ein einzelner Wert in jeder Zeile ist indexiert. Dieser Wert wird als Zeilenschlüssel bezeichnet. Bigtable ist ideal für die Speicherung großer einfach verschlüsselter Datenmengen bei niedriger Latenz. Cloud Bigtable unterstützt einen hohen Durchsatz an Lese- und Schreibvorgängen bei niedriger Latenz und ist die 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 beschränkt, nachdem ein bestimmter Schwellenwert erreicht ist. Bigtable hat diesen Engpass nicht. Daher können Sie den Cluster so skalieren, dass er mehr Lese- und Schreibvorgänge verarbeiten kann.
  • Einfache Verwaltung. Bigtable verarbeitet Aktualisierungen und Neustarts transparent und sorgt automatisch für die Langlebigkeit der Daten. Fügen Sie zum Replizieren Ihrer Daten der Instanz einfach einen zweiten Cluster hinzu. Die Replikation wird dann automatisch gestartet. Sie müssen keine Replikate oder Regionen mehr verwalten. Entwerfen Sie einfach die Tabellenschemas und Bigtable erledigt 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. Nach der Änderung der Clustergröße dauert es unter Last meist nur wenige Minuten, bis Bigtable die Leistung auf alle Knoten im Cluster verteilt.

Einsatzmöglichkeit

Bigtable eignet sich ideal für Anwendungen, die einen hohen Durchsatz und eine hohe Skalierbarkeit für Schlüssel/Wert-Paar-Daten erfordern, bei denen in der Regel kein Wert größer als 10 MB ist. Bigtable eignet sich außerdem hervorragend als Speicher-Engine für Batch-MapReduce-Vorgänge, die Verarbeitung und Auswertung von Streams sowie Anwendungen im Bereich des maschinellen Lernens.

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 Währungskurse
  • 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 typischerweise in Spaltenfamilien 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 Schnittpunkt einer Zeile und Spalte 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 werden zu einem Bigtable-Cluster zusammengefasst, der zu einer Bigtable-Instanz gehört, einem Container für die Cluster.

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 an simultanen Anfragen, die der Cluster verarbeiten kann, erhöhen. Durch das Hinzufügen von Knoten wird auch der maximale Durchsatz für den Cluster erhöht. Wenn Sie durch Hinzufügen weiterer Cluster die Replikation aktivieren, können Sie außerdem verschiedene Arten von Traffic an verschiedene Cluster senden. Wenn ein Cluster nicht mehr verfügbar ist, können Sie ein Failover auf einen anderen Cluster ausführen.

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 Tabellenzeile ist einem bestimmten Bigtable-Knoten zugeordnet. Zusätzlich zu den SSTable-Dateien werden alle Schreibvorgänge im gemeinsamen Log von Colossus gespeichert, sobald sie von Bigtable bestätigt wurden. Dadurch verbessert 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:

  • Das Umverteilen von Tablets von einem Knoten auf einen anderen erfolgt schnell, da die tatsächlichen Daten nicht kopiert werden. Bigtable aktualisiert die Verweise für jeden Knoten.
  • Die Wiederherstellung nach dem Ausfall eines Bigtable-Knotens geht 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 oder größere 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 übernimmt das Aufteilen, Zusammenführen und Ausgleichen automatisch und erspart Ihnen den Aufwand, die Tabellenreihen manuell verwalten zu müssen. Weitere Informationen finden Sie unter Leistung verstehen.

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 enthält, 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 ist es oft effizient, Spaltenqualifizierer als Daten zu nutzen.

Weitere Informationen zu Spaltenqualifizierern finden Sie unter Spalten.

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 eng beieinander liegen, entweder in der gleichen oder in aneinandergrenzenden Zeilen. Wenn Sie Ihre Zeilenschlüssel so organisieren, dass Zeilen mit identischen Datenstücken nebeneinander liegen, können Daten effizient komprimiert werden.
  • Bigtable komprimiert Werte mit einer Größe von 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 sparen Sie CPU-Zyklen, Serverspeicher und Netzwerkbandbreite.

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 Berechtigungen auf Ebene der autorisierten Ansicht gewähren, ohne ihnen Berechtigungen auf Tabellenebene zu erteilen.

Sie können die Sicherheit auf Projekt-, Instanz-, Tabellen- oder autorisierten Ansichtsebene verwalten. Bigtable unterstützt keine Sicherheitseinschrä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, die zum Verschlüsseln Ihrer inaktiven Bigtable-Daten verwendet werden, können Sie vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) verwenden.

Sicherungen

Mit Bigtable-Sicherungen können Sie eine Kopie des Schemas und der Daten einer Tabelle speichern und später in einer neuen Tabelle wiederherstellen. Mit Sicherungen und Sicherungskopien können Sie eine neue Tabelle in jeder Region oder jedem Projekt wiederherstellen, in dem Sie eine Bigtable-Instanz haben, 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 in Echtzeit erfassen und in eine Tabelle streamen. Sie können einen Änderungsstream mit einem Dienst wie Dataflow lesen, um Anwendungsfälle wie Datenanalysen, Audits, Archivierungsanforderungen und das Auslösen der Downstream-Anwendungslogik zu unterstützen. Weitere Informationen finden Sie im Überblick über Änderungsstreams.

Routing mit Anwendungsprofilen anfordern

Mit den Routingrichtlinien von App-Profilen 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. Dabei sind folgende Optionen verfügbar:
    • Beliebiger Cluster: Jeder Cluster in der Instanz kann Anfragen empfangen.
    • Clustergruppen-Routing: Eine bestimmte Gruppe von Clustern in der Instanz kann Anfragen empfangen.

Andere Speicherungs- und Datenbankoptionen

Bigtable ist keine herkömmliche relationale Datenbank. Sie unterstützt zwar SQL-Abfragen, für bestimmte Anwendungsfälle ist jedoch möglicherweise eine andere Datenbankoption besser geeignet.

  • 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 sich Firestore ansehen.
  • Für speicherinterne Datenspeicherung mit niedriger Latenz empfiehlt sich Memorystore.
  • Wenn Sie Daten zwischen Nutzern in Echtzeit synchronisieren möchten, verwenden Sie die 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