Google Bigtable ist ein verwalteter, sparsamer Key-Value-Speicher für Workloads mit sehr vielen Zeilen, hohem Durchsatz und niedriger Latenz. Typische Kandidaten sind Zeitreihen, Geräte- und Telemetriedaten, Ereignisse oder andere Datensätze, die über einen bekannten Schlüssel beziehungsweise Schlüsselbereich gelesen werden. Bigtable ist keine relationale Datenbank mit Joins: Das Datenmodell, die Row Keys und die erwarteten Lesezugriffe müssen vor dem Betrieb zusammenpassen.

Was ist Bigtable und für wen?

Bigtable richtet sich an Plattform-, Daten- und Anwendungsteams, die große Mengen einzelner Schlüsselwerte in Google Cloud speichern und über Client Libraries, APIs oder passende Analysepfade verarbeiten. Die Tabellen sind spärlich; Daten liegen in Zeilen, Column Families und versionierten Cells. Für einen Dienst, der Beziehungen per Join auflöst, viele kleine transaktionale Aggregate über mehrere Zeilen benötigt oder nur eine kleine relationale Anwendung betreibt, ist Bigtable meist die falsche Abstraktion.

Welche Komponenten entscheiden über das Ergebnis?

Eine Bigtable-Instanz umfasst Cluster und Nodes; Application Profiles steuern bei replizierten Instanzen, wie Anwendungen die Cluster ansprechen. Row Keys werden lexikografisch sortiert, und die effizientesten Lesevorgänge arbeiten mit einer einzelnen Row, einem Prefix oder einem Row Range. Operationen sind atomar auf Row-Ebene, nicht über beliebige Zeilen hinweg. Die Enterprise- und Enterprise-Plus-Edition unterscheiden sich bei verfügbaren Fähigkeiten, Speicher- und Analyseoptionen sowie dem Preis. Client Library, IAM, Monitoring und Backup-Plan gehören deshalb zum Dienstdesign, nicht zu späterem Feinschliff.

Praktischer Einführungs-Workflow

  1. Zuerst Entitäten, Datenlebensdauer und die wichtigsten Leseabfragen mit realen Beispielen dokumentieren. Die Abfragen bestimmen das Schema, nicht umgekehrt.
  2. Row-Key-Präfixe, Column Families, Garbage-Collection-Regeln und die Grenze einer atomaren Änderung festlegen. Zeitstempel am Anfang eines Schlüssels können Hotspots erzeugen; Schreiblast muss über den Schlüsselraum verteilt werden.
  3. Einen repräsentativen Test mit echten Schreibmustern, Row-Größen, Filtern und Fehlerfällen aufbauen. Key Visualizer und Cloud Monitoring nutzen, um Hotspots, CPU und Latenz sichtbar zu machen.
  4. Erst nach dem Schema-Test Storage-Typ, Clusterzahl, Autoscaling, Replication und Application Profiles festlegen. Eine zusätzliche Region bedeutet nicht nur Resilienz, sondern auch mehr Speicher- und Replikationslast.
  5. Vor dem Go-live Restore, Rollen, Alerting, Quoten, Client-Retry-Verhalten und einen kontrollierten Schemawechsel in einer isolierten Umgebung üben.

Betrieb, Integration und Wiederherstellung

Google übernimmt die Infrastruktur des verwalteten Dienstes, aber nicht die Folgen eines schlechten Row Keys oder unpassender Abfragen. Autoscaling kann Nodes anhand von CPU- und Storage-Zielen anpassen; Mindest- und Höchstwerte müssen trotzdem zum Budget und zur Spitzenlast passen. Replizierte Instanzen verteilen Writes zwischen Clustern, wobei Routing und Konfliktverhalten in den Anwendungstest gehören.

Backups speichern Schema und Daten und werden in eine neue Tabelle wiederhergestellt, nicht in eine bestehende. Es gibt Standard- und Hot-Backups mit unterschiedlichen Recovery-Eigenschaften; Aufbewahrung, Zielinstanz und Berechtigungen müssen in den DR-Plan. Ein Restore-Test sollte auch Applikationskonfiguration, IAM, Row-Key-Erwartungen und den Umschaltvorgang prüfen. Für große Lesejobs kann Data Boost den Kernbetrieb entlasten; verfügbare Analysefähigkeiten hängen von der Edition ab.

Qualität, Evaluation und Grenzen

Ein gutes Benchmarking misst nicht nur durchschnittliche Latenz. Vergleiche unter identischem Schema p95/p99-Latenz, Durchsatz, Hotspot-Verhalten, Scan-Anteil, Node-Auslastung, Autoscaling-Reaktion und Restore-Dauer. Prüfe, ob das Team seine häufigsten Abfragen tatsächlich als Row- oder Range-Reads formulieren kann. Ein Full-Table-Scan als Standardpfad ist ein Warnsignal.

Bigtable unterstützt keine Joins und Transaktionen nur innerhalb einer Row. Eine Row kann bis zu 256 MB groß werden, aber große Rows verschlechtern die Performance; einzelne Cells sollten nicht als beliebiger Dateispeicher missbraucht werden. Für relationale Beziehungen, flexible Dokumentabfragen oder starke Mehrzeilen-Transaktionen sind andere Datenbanken oft einfacher. Diese Grenzen sollten in einer Entscheidungsmatrix stehen, bevor Daten migriert werden.

Sicherheit, Datenschutz und Governance

Zugriffe auf Bigtable werden über das Google-Cloud-Projekt und IAM-Rollen kontrolliert. Daten sind standardmäßig at rest verschlüsselt; CMEK über Cloud KMS gibt zusätzlich Kontrolle über Schutzlevel, Standort, Rotation, Berechtigungen und Auditierbarkeit. Die Schlüsselverwaltung ist aber eine zusätzliche Abhängigkeit: Verlorene KMS-Berechtigungen können den Zugriff auf Ressourcen und Backups verhindern.

Row Keys und Column-Family-IDs sind Teil der Kundendaten und können in Logs, Diagnose- oder Verschlüsselungskontexten sichtbar werden. Personenbezogene Daten gehören dort nur hinein, wenn das fachlich erforderlich und die Exposition bewertet ist. Dokumentiere Region, Datenflüsse, Aufbewahrung, Löschung, Export, Service Accounts, Break-Glass-Zugriffe und Backup-Rollen. Prüfe außerdem Quoten und die aktuellen Release Notes vor Änderungen an Client Libraries oder Edition-Features.

Kosten und Entscheidungskriterien

Bigtable wird nicht einfach nach gespeicherten Gigabytes bezahlt. Die Rechnung umfasst die gewählte Edition und die Node-Kapazität in den Clustern, Tabellenspeicher und Netzwerkverkehr. Zusätzlich können interregionale Replikation, initiales Kopieren beim Hinzufügen eines Clusters, Backup-Speicher und weitere Google-Cloud-Dienste relevant werden. Nodes werden für bereitgestellte Kapazität berechnet, auch wenn die Anwendung gerade wenig Last erzeugt.

Für eine belastbare Schätzung gehören Schreibvolumen, Row- und Backup-Wachstum, Storage-Typ, Clusterregionen, Replikationsmenge, Spitzenlast, Retention und Data-Boost- oder Analysejobs in ein Messmodell. Vergleiche Editionen und Regionen mit dem offiziellen Pricing Calculator; eine pauschale Monatszahl wäre ohne dieses Profil irreführend.

Redaktionelle Einschätzung

Wir empfehlen Bigtable Teams, die einen großen, schlüsselorientierten Datenbestand mit vorhersehbaren Lesewegen, niedriger Latenz und einem Google-Cloud-Betriebsmodell betreiben. Der Nutzen ist am größten, wenn Row-Key-Design, Lastprofil und Recovery-Prozess praktisch getestet sind und jemand die Kosten über Nodes, Speicher und Replikation verantwortet.

Für kleine relationale Anwendungen, stark join-lastige Systeme oder Teams ohne Bereitschaft, Datenmodell und Restore selbst zu betreiben, ist Bigtable keine gute Standardwahl. Dann sind Firestore, Spanner oder DynamoDB je nach Datenmodell und Cloud-Bindung oft die passendere, enger zugeschnittene Option.

👉 Zum Anbieter: https://cloud.google.com/bigtable

FAQ aufklappen

FAQ

Braucht Bigtable ein relationales Schema?

Nein. Row Keys, Column Families, Qualifier und Garbage-Collection-Regeln bilden das praktische Schema; die Anwendung definiert weitere Spalten beim Schreiben. Die Leseabfragen sollten vorab feststehen, weil Bigtable nicht automatisch relationale Zugriffe oder Joins optimiert.

Sind mehrere Zeilen gemeinsam transaktional änderbar?

Nein, die Atomizität gilt auf Row-Ebene. Wenn eine fachliche Änderung mehrere Zeilen konsistent aktualisieren muss, ist das ein wichtiges Gegenargument oder verlangt ein anderes Datenmodell.

Ist Autoscaling eine automatische Kostenbremse?

Nicht automatisch. Autoscaling reagiert auf konfigurierte CPU- und Storage-Ziele innerhalb von Mindest- und Höchstwerten. Mehr Nodes können Lastspitzen abfangen, erhöhen aber die bereitgestellte Kapazität und damit die Rechnung.

Wie sollte ein Restore getestet werden?

Eine Sicherung wird in eine neue Tabelle und nicht in die bestehende Tabelle wiederhergestellt. Teste deshalb Berechtigungen, Zielinstanz, Konfiguration, Garbage Collection, Applikationsumschaltung und die Zeit bis zu wiederherstellbarer Produktionsleistung.

Wann ist Cloud Spanner die bessere Wahl?

Wenn das Modell relationale Joins und Transaktionen über mehrere Tabellen benötigt oder SQL der zentrale Zugriffspfad ist. Bigtable ist sinnvoller, wenn skalierbare Row- und Range-Reads für einen schlüsselorientierten Datenbestand den Kern bilden.