CLOUD SPANNER → STACKIT · ARCHITEKTUR
Google Cloud Spanner: Migrationsstrategien
StackToIT stuft Spanner als Redesign ein und schreibt dafür kein Terraform, weil horizontale Skalierung mit externer Konsistenz bei STACKIT kein Gegenstück hat. Die eigentliche Frage ist, wie viel dieser Garantie Ihr Workload tatsächlich nutzt. Diese Seite stellt vier Optionen nebeneinander, zeigt, was ein Lauf für eine Spanner-Umgebung festhält, und nennt die Fragen, die zwischen PostgreSQL Flex, einer selbst betriebenen verteilten SQL-Datenbank, dem Verbleib von Spanner und einer Aufteilung des Workloads entscheiden.
Was der Lauf mit einer Spanner-Umgebung macht
Eine für diese Seite geschriebene Demo-Umgebung, am 4. November 2026 mit StackToIT bewertet: eine Instanz, eine GoogleSQL-Datenbank mit zwei verschachtelten Tabellen und eine Datenbank im PostgreSQL-Dialekt sowie eine Leseberechtigung. Links die Instanz und die erste Datenbank aus der Eingabe. Rechts drei wörtliche Fragmente der Einheit aus assessment.json (Kennung, Klasse und Ziel, Begründung), danach zwei Konsolenzeilen.
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 Ressourcen, eine Einheit, kein Entwurf
Instanz, beide Datenbanken und die Berechtigung bilden eine Einheit. Der Lauf entwirft dafür nichts: null Einheiten entworfen, eine für Ihre Architekten offen, und terraform/ enthält nur die Provider-Datei, die Variablendatei und eine README, die die Einheit unter den Aufgaben für Ihre Architekten aufführt.
Die Begründung ist die Entscheidung
Die Klasse ist REDESIGN mit mittlerer Konfidenz. Begründet wird sie damit, dass horizontale Skalierung mit externer Konsistenz auf Basis von TrueTime bei STACKIT kein Gegenstück hat. Workloads, die in eine Region passen, ziehen nach PostgreSQL Flex um; wirklich globale brauchen eine verteilte SQL-Datenbank, die auf SKE betrieben wird.
Der Datenumzug ist offen
Die Datei zum Datenumzug führt die Einheit als „Entscheidung erforderlich“ mit unbekanntem Verfahren. Datenmenge, Änderungsrate, Ausfallzeit und Wiederherstellungspunkt stehen nicht in der Quelle, und der Lauf hält fest, dass er nie Daten überträgt.
Regional oder Multi-Region: der Lauf unterscheidet nicht
Die Demo wurde zweimal bewertet, einmal mit einer regionalen Konfiguration und einmal, ohne die Leseberechtigung, mit der Multi-Region-Konfiguration nam-eur-asia1 über drei Kontinente und drei Knoten. Die Google-Dokumentation führt diese Konfiguration als Multi-Region mit Read-Write-, Read-Only- und Witness-Replikaten über mehrere Kontinente.
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."Gleiche Ausgabe, unterschiedliche Workloads
Klasse, Zieldienst und Begründung waren in beiden Läufen identisch. Die Konfiguration steht als kritische Einstellung zur Datenresidenz auf der Liste; der Lauf wählt aus ihr keine Option. Die Instanzkonfiguration zu lesen ist Ihr erster Designschritt.
Worauf die Wahl beruht
Spanner gibt an, dass externe Konsistenz seine strengste Garantie ist, standardmäßig oder mit Serializable-Isolation angewendet, und dass die TrueTime-Zeitstempel Clients konsistente Lesezugriffe über eine ganze Datenbank erlauben, auch über Regionen hinweg, ohne Schreibzugriffe zu blockieren. Ob Ihre Anwendung sich darauf über Regionen hinweg stützt oder nur innerhalb einer, trennt die Optionen.
Vier Optionen im Vergleich
| Option | Wo sie passt | Was Sie übernehmen |
|---|---|---|
| PostgreSQL Flex, eine Region | Workloads, die in eine Region passen; der PostgreSQL-Dialekt von Spanner erleichtert den Umzug | Abfragen und Schema umschreiben; eine Region; Replika-Set aus 3 Knoten, tägliche Backups mit Point-in-Time-Recovery |
| Verteilte SQL-Datenbank auf SKE | Workloads, die in STACKIT eine verteilte Datenbank mit SQL brauchen | Sie betreiben sie selbst: Updates, Backups, Kapazität, Fehlerbehandlung; der Lauf fand im geprüften STACKIT-Katalog keinen solchen verwalteten Dienst |
| Spanner bleibt bestehen | Ein Datenspeicher, dessen Konsistenzmodell die Anwendung nicht aufgeben kann | Die Abhängigkeit von Google Cloud bleibt; Netzwerkpfad, Identität und Latenz zwischen den Clouds gehören zum Design |
| Workload aufteilen | Daten, die von Natur aus regional sind, etwa Hauptbücher pro Land | Routing und regionsübergreifende Lesezugriffe wandern in die Anwendung; allgemeine Praxis, kein Ergebnis der Engine |
Fakten zu PostgreSQL Flex aus der STACKIT-Architekturseite. Der Lauf nennt die ersten beiden Optionen; die letzten beiden sind Designentscheidungen Ihrer Architekten.
Was der Lauf Ihnen zur Entscheidung überlässt
Der Lauf lässt neun kritische Semantiken der Demo-Einheit offen, die zwölf kritische Einstellungen berühren. Der Bericht gruppiert die Einstellungen in sechs Arten, wörtlich im Ausschnitt weiter unten; dies sind die Entscheidungen dahinter.
Datenmodell
Die Wahl zwischen den beiden Zielen und der darauf folgende Umbau des Datenmodells. Hier wird nichts entworfen.
Dialekt und DDL
GoogleSQL oder PostgreSQL-Dialekt legt die SQL-Syntax fest, die Anwendung und Schema-Skripte nutzen. Die DDL legt eine Person neu an, weil die Ziele im Provider keine Schema-Ressource haben.
Versionsaufbewahrung
Das Point-in-Time-Fenster der Spanner-Datenbank, hier drei Tage, wird zum Backup- und Wiederherstellungsdesign dessen, was Spanner ersetzt.
Löschschutz
deletion_protection ist Terraforms eigener Schutz der Spanner-Datenbank. Ein STACKIT-Gegenstück ist nicht benannt; entscheiden Sie es mit dem gewählten Ziel.
Zugriff
Die Leseberechtigung nennt einen Benutzer und eine Rolle. Das neue Ziel hat sein eigenes Zugriffsmodell; eine Person übersetzt die Berechtigung.
Namen und Residenz
Datenbanknamen werden gegen die Anwendungen geprüft, die sie nutzen, die Instanzkonfiguration gegen Ihre Anforderung an die Datenresidenz.
Die offenen Einstellungen und eine Schema-Skizze
Links die gruppierten kritischen Einstellungen aus engineering/architect-report.md. Rechts eine von Hand geschriebene Skizze, wie die beiden verschachtelten Tabellen in PostgreSQL aussehen können. Sie ist keine Engine-Ausgabe; der Lauf führt die DDL als Einstellung für eine Person.
- 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)
);Verschachtelung ist physisch, ein Fremdschlüssel logisch
Spanner-Verschachtelung legt Kindzeilen neben die Elternzeile, und INTERLEAVE IN PARENT erzwingt die Beziehung. Ein Fremdschlüssel legt Zeilen nicht zusammen. In PostgreSQL bleibt die Beziehung als Constraint erhalten; der Vorteil der Nähe ist eine andere Frage.
Schlüssel wurden für Spanner entworfen
Spanner teilt Daten nach Schlüsselbereichen, und die Dokumentation rät zu gehashten, umgestellten oder zufälligen Schlüsseln gegen Hotspots. Diese Entscheidungen haben Ihre Schlüssel geprägt; ein Primärschlüssel in PostgreSQL folgt anderen Abwägungen; prüfen Sie die Schlüssel daher zusammen mit dem Schema.
So entscheiden Sie, der Reihe nach
Messen, was Sie tatsächlich nutzen
Listen Sie, welche Transaktionen Regionen überspannen und wie viel Veraltung beim Lesen sie vertragen. Löst sich alles innerhalb einer Region auf, ist die Ein-Region-Option offen.
Verfügbarkeits- und Wiederherstellungsziele festlegen
Halten Sie Wiederherstellungspunkt und Ausfallzeit fest, die das Geschäft akzeptiert. PostgreSQL Flex bietet ein Replika-Set aus 3 Knoten, tägliche Backups und Point-in-Time-Recovery über die Transaktionslogs; laut STACKIT erfolgt die Wiederherstellung in eine geklonte Instanz, nicht in die bestehende. Vergleichen Sie das mit Ihrem Ziel, bevor Sie wählen.
Das Betriebsmodell durchrechnen
Eine verteilte Datenbank auf SKE verlagert Backups, Updates und Fehlerbehandlung in Ihr Team. Zählen Sie Personal und Bereitschaftslast, nicht nur Instanzen.
Den Datenumzug planen
Spanner kann eine Datenbank als Avro-Dateien über Dataflow in einen Cloud-Storage-Bucket exportieren, optional zum Stand eines früheren Zeitstempels. Für das Laden ins Ziel und das Nachziehen von Änderungen nach dem Export schreiben oder wählen Sie das Werkzeug selbst; der Lauf wählt kein Verfahren.
Eine Datenbank pilotieren
Ziehen Sie zuerst eine unkritische Datenbank um, mit dem gewählten Ziel und einem Rückweg zu Spanner. Lassen Sie Spanner laufen, bis die neue Datenbank echte Last getragen hat.
Fragen von Architekten
Warum gibt es kein Terraform für Spanner?
Die Einheit ist ein Redesign; der Lauf entwirft dafür nichts. Der Entwurfsordner enthält Provider-Datei, Variablen und eine README, die die Instanz als Aufgabe für Ihre Architekten ausweist. Eine Zielressource entsteht erst, nachdem Sie das Ziel gewählt haben.
Macht der PostgreSQL-Dialekt von Spanner PostgreSQL Flex zum Drop-in?
Nein. Der Dialekt erleichtert den Umzug, aber laut Google werden einige PostgreSQL-Sprachfunktionen wie Extensions, benutzerdefinierte Datentypen und Stored Procedures nicht unterstützt, und der Dialekt ergänzt Spanner-eigene Erweiterungen wie verschachtelte Tabellen und Query Hints. Code für Spanner kann sich darauf stützen und muss daher gegen Standard-PostgreSQL geprüft werden.
Können wir Spanner behalten und den Rest auf STACKIT betreiben?
Ja, als Designentscheidung. Die Umgebung hängt dann für diesen Datenspeicher von Google Cloud ab, und der Netzwerkpfad zwischen den Clouds, die dafür genutzte Identität und die Latenz werden Teil des Designs. Der Lauf bildet diese Option nicht ab.
Bietet STACKIT eine global verteilte relationale Datenbank?
Der Lauf hält fest, dass der geprüfte STACKIT-Katalog keine führt; deshalb ist das zweite Ziel eine Datenbank, die Sie auf SKE betreiben. Prüfen Sie den aktuellen STACKIT-Katalog, wenn Sie entscheiden.
Quellen
Ihr nächster Schritt: STACKIT.
Erzählen Sie uns von Ihrer Umgebung. Wir zeigen Ihnen, was StackToIT dafür liefert: Zielarchitektur, Terraform-Artefakte und einen strukturierten Migrationsplan.