Migratiestrategieën voor Google Cloud Spanner

Wat de run doet met een Spanner-omgeving

Een demo-omgeving die voor deze pagina is geschreven en op 4 november 2026 door StackToIT is beoordeeld: één instance, een GoogleSQL-database met twee interleaved tabellen en een database met PostgreSQL-dialect, plus een leesrecht. Links: de instance en de eerste database uit de invoer. Rechts: drie letterlijke fragmenten van de eenheid in assessment.json (id, klasse en doel, reden), daarna twee consoleregels.

resource "google_spanner_instance" "ledger" {
  name             = "ledger"
  config           = "regional-europe-west3"
  display_name     = "Ledger"
  processing_units = 1000
}

resource "google_spanner_database" "accounts" {
  instance            = google_spanner_instance.ledger.name
  name                = "accounts"
  database_dialect    = "GOOGLE_STANDARD_SQL"
  deletion_protection = true
  version_retention_period = "3d"

  ddl = [
    "CREATE TABLE Accounts (AccountId STRING(36) NOT NULL, Owner STRING(128), Balance NUMERIC) PRIMARY KEY (AccountId)",
    "CREATE TABLE Entries (AccountId STRING(36) NOT NULL, EntryId STRING(36) NOT NULL, Amount NUMERIC, CreatedAt TIMESTAMP OPTIONS (allow_commit_timestamp=true)) PRIMARY KEY (AccountId, EntryId), INTERLEAVE IN PARENT Accounts ON DELETE CASCADE",
  ]
}

"id":"google_spanner_instance.ledger"
"class":"REDESIGN","confidence":"MEDIUM","target":{"service":"PostgreSQL Flex (single region) or a self-managed distributed SQL database — data-model redesign","resources":["stackit_postgresflex_instance"]
"reason":"Spanner's horizontal scale-out with external consistency (TrueTime) has no STACKIT counterpart. Workloads that fit one region move to PostgreSQL Flex (Spanner's PostgreSQL dialect eases this); truly global ones need a distributed SQL database operated on SKE."

Source        4 resources · 1 unit · visibility: Complete
Migration     0 drafted · 1 manual (of 1 units the draft considered)

• Vier resources, één eenheid, geen concept

  De instance, beide databases en het leesrecht vormen samen één eenheid. De run schrijft er niets voor: nul eenheden als concept geschreven, één over voor de architect, en terraform/ bevat alleen het providerbestand, het variabelenbestand en een README die de eenheid vermeldt onder "Left for the architect".

• De reden is de beslissing

  De klasse is REDESIGN met zekerheidsniveau MEDIUM. De genoemde reden is dat horizontaal uitschalen met externe consistentie, gebouwd op TrueTime, op STACKIT geen tegenhanger heeft. Workloads die in één regio passen, gaan naar PostgreSQL Flex; echt globale workloads vereisen een gedistribueerde SQL-database die u op SKE beheert.

• Dataverplaatsing is nog niet beslist

  Het bestand over dataverplaatsing noemt de eenheid "decision required", met onbekend mechanisme. De omvang van de data, de wijzigingssnelheid, de downtime en het herstelpunt staan niet in de bron, en de run meldt dat hij nooit data verplaatst.

Regionaal of multiregionaal: de run maakt geen onderscheid

De demo is twee keer beoordeeld: één keer met een regionale configuratie en één keer, zonder het leesrecht, met de multiregionale configuratie nam-eur-asia1 over drie continenten en drie nodes. De documentatie van Google noemt die configuratie multiregionaal, met lees-schrijf-, alleen-lezen- en witness-replica's verspreid over continenten.

  name             = "ledger"
  config           = "regional-europe-west3"
  display_name     = "Ledger"
  processing_units = 1000

  name             = "ledger"
  config           = "nam-eur-asia1"
  display_name     = "Ledger"
  num_nodes = 3

"id":"google_spanner_instance.ledger"
"class":"REDESIGN","confidence":"MEDIUM","target":{"service":"PostgreSQL Flex (single region) or a self-managed distributed SQL database — data-model redesign","resources":["stackit_postgresflex_instance"]
"reason":"Spanner's horizontal scale-out with external consistency (TrueTime) has no STACKIT counterpart. Workloads that fit one region move to PostgreSQL Flex (Spanner's PostgreSQL dialect eases this); truly global ones need a distributed SQL database operated on SKE."

• Dezelfde uitvoer, andere workloads

  Klasse, doeldienst en reden waren in beide runs identiek. De configuratie staat als kritieke instelling voor dataresidentie in de lijst en de run kiest er geen optie op. Het lezen van de instanceconfiguratie is uw eerste ontwerpstap.

• Waarop de keuze rust

  Spanner geeft aan dat externe consistentie de strengste garantie is, standaard toegepast of met serializable isolation, en dat TrueTime-tijdstempels clients in staat stellen consistent over een hele database te lezen, ook over regio's heen, zonder schrijfacties te blokkeren. Of uw applicatie daar over regio's heen op leunt of alleen binnen één regio, is het gegeven dat de opties van elkaar onderscheidt.

Vier opties vergeleken

De feiten over PostgreSQL Flex komen van de architectuurpagina van STACKIT. De run noemt de eerste twee opties; de laatste twee zijn ontwerpkeuzes voor uw architect.

Wat de run aan u overlaat

De run laat negen kritieke semantische punten van de demo-eenheid open, die twaalf kritieke instellingen raken. Het rapport groepeert de instellingen in zes soorten, letterlijk in het paneel hieronder; dit zijn de beslissingen erachter.

• Datamodel

  De keuze tussen de twee doelen en het redesign van het datamodel dat daarop volgt. Hier wordt niets als concept geschreven.

• Dialect en DDL

  GoogleSQL of PostgreSQL-dialect bepaalt de SQL-syntaxis die de applicatie en de schemascripts gebruiken. De DDL wordt door een persoon opnieuw opgebouwd, omdat de doelen in de provider geen schema-resource hebben.

• Versiebehoud

  Het point-in-time-venster van de Spanner-database, hier drie dagen, wordt het back-up- en herstelontwerp van wat Spanner vervangt.

• Beveiliging tegen verwijderen

  deletion_protection is de eigen beveiliging van Terraform op de Spanner-database. Er is geen tegenhanger op STACKIT genoemd, dus beslis hierover samen met het gekozen doel.

• Toegang

  Het leesrecht noemt een gebruiker en een rol. Het nieuwe doel heeft een eigen toegangsmodel, dus een persoon vertaalt het recht.

• Namen en dataresidentie

  Databasenamen worden getoetst aan de applicaties die ze gebruiken, en de instanceconfiguratie aan uw eis voor dataresidentie.

De open instellingen en een schemaschets

Links: de gegroepeerde kritieke instellingen uit engineering/architect-report.md. Rechts: een handmatig geschreven schets van wat de twee interleaved tabellen op PostgreSQL worden. Het is geen uitvoer van de engine; de run noemt de DDL als instelling voor een persoon.

  - identity access (2; REVIEW 2): `google_spanner_database_iam_member.reader.member`, `google_spanner_database_iam_member.reader.role`
  - backup retention (1; REVIEW 1): `google_spanner_database.accounts.version_retention_period`
  - deletion protection (2; REVIEW 2): `google_spanner_database.accounts.deletion_protection`, `google_spanner_database.audit.deletion_protection`
  - residency compliance (1; REVIEW 1): `config`
  - workload compatibility (5; REVIEW 5): `name`, `google_spanner_database.accounts.database_dialect`, `google_spanner_database.accounts.name`, `google_spanner_database.audit.database_dialect`, `google_spanner_database.audit.name`
  - data semantics (1; REVIEW 1): `google_spanner_database.accounts.ddl`

-- Sketch written by hand, not engine output.
-- Spanner DDL (input):  INTERLEAVE IN PARENT Accounts ON DELETE CASCADE
CREATE TABLE accounts (
  account_id varchar(36) PRIMARY KEY,
  owner      varchar(128),
  balance    numeric
);

CREATE TABLE entries (
  account_id varchar(36) NOT NULL REFERENCES accounts ON DELETE CASCADE,
  entry_id   varchar(36) NOT NULL,
  amount     numeric,
  created_at timestamptz,          -- was TIMESTAMP with allow_commit_timestamp
  PRIMARY KEY (account_id, entry_id)
);

• Interleaving is fysiek, een foreign key is logisch

  Spanner-interleaving slaat onderliggende rijen naast de bovenliggende rij op en INTERLEAVE IN PARENT dwingt de relatie af. Een foreign key plaatst rijen niet bij elkaar. Op PostgreSQL blijft de relatie bestaan als constraint; het voordeel van nabijheid is een andere vraag.

• Sleutels zijn voor Spanner ontworpen

  Spanner verdeelt data op sleutelbereik en de documentatie raadt gehashte, herordende of willekeurige sleutels aan om hotspots te vermijden. Die keuzes hebben uw sleutels gevormd; een primaire sleutel in PostgreSQL kent andere afwegingen, dus beoordeel de sleutels samen met het schema.

Zo beslist u, in volgorde

1. 01

   Meet wat u werkelijk gebruikt

   Inventariseer welke transacties meerdere regio's omvatten en hoeveel verouderde data ze verdragen. Als alles binnen één regio blijft, staat de optie met één regio open.

2. 02

   Leg de doelen voor beschikbaarheid en herstel vast

   Schrijf op welk herstelpunt en welke downtime het bedrijf accepteert. PostgreSQL Flex biedt een replicaset van 3 nodes, dagelijkse back-ups en point-in-time recovery vanuit de transactielogs; STACKIT geeft aan dat herstel naar een gekloonde instance gaat, niet naar de bestaande. Vergelijk dat met uw doel voordat u kiest.

3. 03

   Reken het beheermodel door

   Een gedistribueerde database op SKE verlegt back-ups, upgrades en foutafhandeling naar uw team. Tel de mensen en de piketdienst mee, niet alleen de instances.

4. 04

   Plan de dataverplaatsing

   Spanner kan een database via Dataflow als Avro-bestanden exporteren naar een Cloud Storage-bucket, desgewenst op een eerder tijdstip. Het laden in het doel, en het inhalen van wijzigingen na de export, is tooling die u zelf schrijft of kiest; de run kiest geen mechanisme.

5. 05

   Pilot met één database

   Verplaats eerst één database met laag risico, met het gekozen doel en een rollback naar Spanner. Laat Spanner draaien totdat de nieuwe database echte belasting heeft verwerkt.

Vragen die architecten stellen

Bronnen

• Spanner: TrueTime en externe consistentie
• Spanner: instanceconfiguraties
• Spanner: PostgreSQL-interface
• Spanner: schema en datamodel
• Spanner: een database exporteren
• Architectuur van STACKIT PostgreSQL Flex