Bigtable-Migration: die Wide-Column-Schicht neu entwerfen

Eine Bigtable-Instanz mit ihren Policies, bewertet

Eine für diese Seite geschriebene Umgebung, am 4. November 2026 von StackToIT bewertet: eine Instanz mit zwei Clustern, eine Tabelle mit zwei Column Families, zwei Garbage-Collection-Policies und ein Application Profile. Rechts steht ein wörtlicher Auszug aus engineering/architect-report.md zur Instanz: die Begründung, die enthaltene Tabelle und die drei Warnungen zu den nicht katalogisierten Nachbarn. Für keine der vier Einheiten hat der Lauf Terraform geschrieben.

resource "google_bigtable_instance" "telemetry" {
  name                = "telemetry"
  deletion_protection = true

  cluster {
    cluster_id   = "telemetry-ew3-a"
    zone         = "europe-west3-a"
    num_nodes    = 3
    storage_type = "SSD"
  }

  cluster {
    cluster_id   = "telemetry-ew3-b"
    zone         = "europe-west3-b"
    num_nodes    = 3
    storage_type = "SSD"
  }
}

resource "google_bigtable_table" "readings" {
  name          = "device-readings"
  instance_name = google_bigtable_instance.telemetry.name
  split_keys    = ["a", "m", "t"]

  column_family {
    family = "metrics"
  }

  column_family {
    family = "meta"
  }
}

resource "google_bigtable_gc_policy" "metrics_ttl" {
  instance_name = google_bigtable_instance.telemetry.name
  table         = google_bigtable_table.readings.name
  column_family = "metrics"

  max_age {
    duration = "720h"
  }
}

resource "google_bigtable_gc_policy" "meta_versions" {
  instance_name = google_bigtable_instance.telemetry.name
  table         = google_bigtable_table.readings.name
  column_family = "meta"

  max_version {
    number = 1
  }
}

resource "google_bigtable_app_profile" "ingest" {
  instance       = google_bigtable_instance.telemetry.name
  app_profile_id = "ingest"

  single_cluster_routing {
    cluster_id                 = "telemetry-ew3-a"
    allow_transactional_writes = false
  }

  ignore_warnings = true
}

- **Why:** STACKIT has no wide-column database service; row-key design and the HBase/Bigtable client API move to a self-operated store or a redesigned data model.
- **Includes:** `google_bigtable_table.readings`
- **WARNING** (uncatalogued-related): google_bigtable_app_profile.ingest (google_bigtable_app_profile) is linked to this unit but not in the knowledge base; its effect on the migration is not assessed.
- **WARNING** (uncatalogued-related): google_bigtable_gc_policy.meta_versions (google_bigtable_gc_policy) is linked to this unit but not in the knowledge base; its effect on the migration is not assessed.
- **WARNING** (uncatalogued-related): google_bigtable_gc_policy.metrics_ttl (google_bigtable_gc_policy) is linked to this unit but not in the knowledge base; its effect on the migration is not assessed.

• Vier Einheiten, keine im Entwurf

  Die Tabelle wird als Facette der Instanz mitgeführt. Die beiden Garbage-Collection-Policies und das Application Profile sind eigene Einheiten der Klasse MANUAL_REVIEW, weil sie nicht im Katalog der Engine stehen: Nichts davon wird bewertet oder entworfen, und der Lauf sagt das ausdrücklich.

• Warum die Konfidenz hier LOW ist

  Für sich allein, in der Umgebung mit zwölf Ressourcen auf unserer Seite zur Dienstzuordnung, kam dieselbe Instanz auf MEDIUM. Hier führt der Architektenbericht die Instanz bei den verknüpften Einheiten der nicht katalogisierten Garbage-Collection-Policies mit der Konfidenzgrenze LOW. Das heißt: Policies und Profil brauchen den Blick eines Architekten; über die Portierbarkeit der Instanz sagt es nichts.

Was der Lauf einstuft

Der Datenumzug steht auf DECISION REQUIRED, das Verfahren auf UNKNOWN: Die Quelle nennt weder Datenmenge noch Änderungsrate, und der Lauf rät nicht.

Die Optionen mit ihren Abwägungen

Die ersten beiden sind die Ziele, die die Engine nennt. Die letzten beiden sind allgemeine Praxis, die die Engine nicht vorschlägt; sie passen nur, wenn die Last kleiner oder kälter ist, als ein Bigtable-Einsatz vermuten lässt.

Wohin welches Bigtable-Konstrukt geht

So wählen Sie

1. 01

   1. Zugriffsmuster aus dem Code lesen

   Listen Sie die Abfragen auf: Punktzugriffe per Schlüssel, Präfix- oder Bereichs-Scans, zeitlich geordnete Zugriffe je Gerät. Bereichs-Scans auf einem zusammengesetzten Schlüssel kann ein Wide-Column-Speicher am besten, und jede andere Option muss sie nachbauen.

2. 02

   2. Die Zahlen beschaffen, die der Lauf nicht liefert

   Datenmenge, Änderungsrate und Schreibdurchsatz stehen nicht im Terraform. Die Datei data-movement.md hält fest, dass Größe und Änderungsrate nicht in der Quelle stehen und tolerierte Ausfallzeit und Recovery Point nicht angegeben wurden; erheben Sie all das im laufenden System, bevor Sie etwas in die engere Wahl nehmen.

3. 03

   3. Die akzeptierte Konsistenz benennen

   Eine Bigtable-Instanz mit mehreren Clustern arbeitet standardmäßig mit Eventual Consistency. War das eine bewusste Entscheidung, genügt womöglich ein Primary mit Replikat; hat es niemand bemerkt, klären Sie es jetzt.

4. 04

   4. Aufbewahrung als Anforderung festhalten

   Die Regeln 30 Tage und eine Version im Beispiel sind Anforderungen, keine Einstellungen zum Kopieren. Formulieren Sie die Aufbewahrung fachlich und setzen Sie sie dann im Ziel um.

5. 05

   5. Betriebsaufwand realistisch rechnen

   Ein selbst betriebener Speicher bringt das nächste Modell und braucht ein Team, das ihn betreiben kann. Ein verwalteter Dienst senkt diesen Aufwand und vergrößert den Umbau. Der Lauf bepreist keines von beiden.

6. 06

   6. Den Datenumzug zuletzt planen, nicht zuerst

   Verfahren, Zeitfenster und Validierung hängen vom Ziel ab. Wählen Sie sie nach dem Speicher und mit Rollback im Blick: Halten Sie Bigtable lesbar, bis der neue Speicher echten Verkehr bedient hat.

Fragen von Architekten

Quellen

• Google-Cloud-Dokumentation: Bigtable im Überblick
• Google-Cloud-Dokumentation: Garbage Collection in Bigtable
• Google-Cloud-Dokumentation: Schemadesign für Bigtable
• STACKIT-Dokumentation: MongoDB Flex