Bigtable-migratie: de wide-column-laag ontwerpen

Een Bigtable-instance en bijbehorende beleidsregels, beoordeeld

Een omgeving die voor deze pagina is geschreven en op 4 november 2026 door StackToIT is beoordeeld: één instance met twee clusters, een tabel met twee column families, twee garbage collection-beleidsregels en een application profile. Het rechterpaneel is een letterlijk fragment van engineering/architect-report.md voor de instance: de reden, de tabel die erbij hoort en de drie waarschuwingen over de naastliggende eenheden die niet in de catalogus staan. De run schreef voor geen van de vier eenheden Terraform.

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 eenheden, geen enkele als concept geschreven

  De tabel reist als facet mee met de instance. De twee garbage collection-beleidsregels en het application profile zijn aparte eenheden met klasse MANUAL_REVIEW, omdat ze niet in de catalogus van de engine staan: er wordt niets over beoordeeld of als concept geschreven, en de run meldt dat ook.

• Waarom het zekerheidsniveau hier LOW is

  Dezelfde instance, los in de omgeving van twaalf resources op onze pagina over service mapping, kwam uit op MEDIUM. Hier noemt het architectenrapport de instance onder de gekoppelde eenheden van de garbage collection-beleidsregels die niet in de catalogus staan, met een plafond van LOW voor het zekerheidsniveau. Dat geeft aan dat de beleidsregels en het profiel een architect nodig hebben, niet dat de instance meer of minder overdraagbaar is.

Wat de run classificeert

Dataverplaatsing meldt DECISION REQUIRED met het mechanisme UNKNOWN: de bron noemt noch de omvang van de data, noch de wijzigingssnelheid, en de run gokt er niet naar.

De opties, met hun afwegingen

De eerste twee zijn de doelen die de engine noemt. De laatste twee zijn algemene praktijk die de engine niet voorstelt; ze passen alleen als de workload kleiner of kouder is dan een Bigtable-implementatie doet vermoeden.

Waar elk Bigtable-onderdeel naartoe gaat

Zo kiest u

1. 01

   1. Lees het toegangspatroon uit de code

   Som de query's op: puntleesacties op sleutel, prefix- of bereikscans, op tijd geordende leesacties per apparaat. Bereikscans op een samengestelde sleutel zijn waar een wide-column-store het best in is en wat elke andere optie moet nabouwen.

2. 02

   2. Verzamel de cijfers die de run u niet kan geven

   Omvang van de data, wijzigingssnelheid en schrijfdoorvoer staan niet in de Terraform. Het bestand over dataverplaatsing geeft aan dat omvang en wijzigingssnelheid niet in de bron staan en dat de acceptabele downtime en het herstelpunt niet zijn opgegeven; verzamel ze allemaal uit het draaiende systeem voordat u iets op de shortlist zet.

3. 03

   3. Leg de consistentie vast die uw lezers accepteren

   Een Bigtable-instance met meerdere clusters leest standaard eventually consistent. Was dat een bewuste keuze, dan kan een enkele primary met een replica volstaan; heeft niemand het gemerkt, zeg dat dan nu.

4. 04

   4. Schrijf bewaartermijnen op als eis

   De regels van 30 dagen en één versie in het voorbeeld zijn eisen, geen instellingen om over te nemen. Benoem de bewaartermijn in zakelijke termen en druk die dan uit in het doel.

5. 05

   5. Tel de beheerkosten mee

   Een zelf beheerde store levert het dichtstbijzijnde model op en kost een team dat het kan beheren. Een managed dienst verlaagt die kosten en verhoogt het herschrijfwerk. De run geeft voor geen van beide een prijs.

6. 06

   6. Plan de dataverplaatsing als laatste, niet als eerste

   Mechanisme, venster en validatie hangen af van het doel. Kies ze na de store, met rollback in het achterhoofd: houd Bigtable leesbaar totdat de nieuwe store echt verkeer heeft verwerkt.

Vragen die architecten stellen

Bronnen

• Documentatie van Google Cloud: Bigtable-overzicht
• Documentatie van Google Cloud: Bigtable garbage collection
• Documentatie van Google Cloud: Bigtable-schemaontwerp
• Documentatie van STACKIT: MongoDB Flex