Google Cloud Professional Cloud Database Engineer
Zuletzt überprüft: Mai 2026
Eine übersichtliche Referenz der Architekturmuster, die in der PCDE-Prüfung getestet werden. Von oben nach unten lesen oder zu einem Abschnitt springen.
Globale E-Commerce-Plattform, die ACID-Transaktionen, starke Konsistenz und 99,999 % Verfügbarkeit über mehrere Kontinente hinweg erfordert.
Cloud Spanner mit einer Multi-Region-Konfiguration (z. B. nam-eur-asia).
Warum: Spanner ist der einzige verwaltete GCP-Dienst, der global verteilte, stark konsistente ACID-Transaktionen in großem Maßstab mit einem 99,999 % SLA bietet.
Migration einer großen, hochleistungsfähigen Oracle OLTP-Datenbank mit komplexen gespeicherten Prozeduren und analytischen Abfrageanforderungen.
AlloyDB für PostgreSQL.
Warum: AlloyDB bietet überragende PostgreSQL-Leistung, Oracle-Kompatibilitätsfunktionen und eine Spalten-Engine zur Beschleunigung analytischer Abfragen (HTAP), ohne transaktionale Workloads zu beeinträchtigen.
Ingestion von Zeitreihendaten (z. B. IoT, Protokolle) mit hohem Durchsatz (Millionen von OPS), die Lesezugriffe mit geringer Latenz und automatischen Datenablauf erfordert.
Cloud Bigtable mit einem Zeilenschlüsseldesign von `(entity_id)#(reverse_timestamp)` und einer Garbage Collection Policy.
Warum: Bigtable ist für Key/Value-Workloads mit massivem Maßstab und geringer Latenz konzipiert. Ein umgekehrter Zeitstempel im Zeilenschlüssel platziert aktuelle Daten für effiziente Scans zusammen. Garbage Collection verwaltet TTL.
Mobile oder Webanwendung, die ein flexibles Schema, Echtzeit-Datensynchronisation mit Clients und Offline-Unterstützung erfordert.
Firestore im Native Mode.
Warum: Firestore wurde speziell für dieses Serverless-App-Backend-Muster entwickelt und bietet Echtzeit-Listener und Offline-Persistenz über seine Client-SDKs sofort einsatzbereit.
Groß angelegte Ähnlichkeitssuche (10 Mio.+ Vektoren) für KI/ML-Anwendungen (z. B. RAG, Empfehlungen), die eine Latenz von unter 100 ms erfordert.
AlloyDB für PostgreSQL mit pgvector-Erweiterung und einem ScaNN-Index.
Warum: AlloyDB integriert Googles hochleistungsfähigen ScaNN-Algorithmus für die Approximate Nearest Neighbor (ANN)-Suche und übertrifft Standard-Vektorsuchimplementierungen in großem Maßstab.
Entwurf eines Cloud Spanner-Schemas für eine schreibintensive Workload, um Hotspots auf einem einzelnen Server zu vermeiden.
Primärschlüssel so entwerfen, dass sie keine monoton steigenden Werte (z. B. sequentielle IDs, Zeitstempel) als ersten Schlüsselteil verwenden. Stattdessen UUIDs, Hash-Werte oder bit-umgekehrte Sequenzen verwenden.
Warum: Spanner verteilt Daten lexikographisch nach Primärschlüssel. Sequentielle Schlüssel leiten alle Schreibvorgänge an einen einzelnen Split, wodurch ein Hotspot entsteht. Zufällig verteilte Schlüssel verteilen Schreibvorgänge auf alle Splits.
Ein Spanner-Schema weist eine starke Eltern-Kind-Beziehung auf (z. B. Kunden und Bestellungen) und Abfragen rufen häufig ein Elternteil mit all seinen Kindern ab.
Verschachtelte Tabellen verwenden, wobei die Kindertabelle mit `INTERLEAVE IN PARENT` definiert wird.
Warum: Das Verschachteln platziert Kindzeilen physisch zusammen mit ihren Elternzeilen im Speicher. Dies macht Eltern-Kind-Joins extrem effizient, da es zu einem hochoptimierten Bereichsscan auf einem einzelnen Split wird.
Verfolgung von Echtzeitstandorten für eine massive Fahrzeugflotte (50.000+ Schreibvorgänge/Sek.) mit Abfragen zur Suche von Fahrzeugen innerhalb eines geografischen Gebiets.
Cloud Bigtable mit einem Zeilenschlüssel, dem ein GeoHash des Fahrzeugstandorts vorangestellt ist.
Warum: Bigtable bewältigt den extremen Schreibdurchsatz. Die GeoHash-Kodierung wandelt 2D-Koordinaten in eine 1D-Zeichenfolge um, wobei Präfixe die geografische Nähe darstellen und effiziente geografische Bereichsscans ermöglichen.
Speicherung und Analyse von Petabyte-großen Daten (z. B. Genomdaten, Protokolle) mit komplexen analytischen SQL-Abfragen.
Rohdaten in Cloud Storage speichern und diese direkt von BigQuery aus über externe Tabellen abfragen oder in den nativen BigQuery-Speicher laden.
Warum: BigQuery ist ein Serverless Data Warehouse, das für Petabyte-Analysen entwickelt wurde. Seine Trennung von Speicher und Berechnung bietet eine unübertroffene Abfrageleistung und Kosteneffizienz für OLAP-Workloads.
Ein hochverfügbarer In-Memory-Cache für komplexe Datenstrukturen (Hashes, Sets) mit Pub/Sub-Funktionen zur Cache-Invalidierung.
Memorystore für Redis Standard Tier mit Lesereplikaten.
Warum: Standard Tier bietet ein 99,9 % SLA mit automatischem Failover. Redis unterstützt komplexe Datentypen und Pub/Sub, im Gegensatz zu Memcached. Lesereplikate können den Lese-Durchsatz skalieren.
Entwurf einer Multi-Tenant SaaS-Anwendung auf Spanner, die eine starke Datenisolation und Leistungsgarantien pro Tenant erfordert.
Verwenden Sie tenant_id als erste Komponente des Primärschlüssels für alle Tabellen. Für eine stärkere Isolation verwenden Sie ein Database-per-Tenant-Modell innerhalb einer einzelnen Spanner-Instanz.
Warum: Ein tenant_id-Präfix platziert alle Daten eines einzelnen Tenants natürlich zusammen, optimiert Abfragen und ermöglicht Spanner, Daten nach Tenant aufzuteilen. Database-per-Tenant bietet die stärkste logische Isolation.
Eine Cloud SQL-Datenbank weist langsame Abfrageleistung und hohe CPU-Auslastung auf.
Verwenden Sie Query Insights, um die ressourcenintensivsten Abfragen zu identifizieren, deren Ausführungspläne zu analysieren und fehlende Indizes oder ineffiziente Muster zu erkennen.
Warum: Query Insights ist das primäre, integrierte Tool zur Diagnose der Abfrageleistung in Cloud SQL. Es visualisiert die Abfragelast, identifiziert Warteereignisse und hilft, die Ursache ohne Tools von Drittanbietern zu finden.
Eine Organisation benötigt ein einziges Dashboard und einen Satz von Alarmrichtlinien für Dutzende von Datenbankinstanzen, die über mehrere GCP-Projekte verteilt sind.
Erstellen Sie einen Cloud Monitoring Workspace in einem zentralen Projekt und konfigurieren Sie dessen "Metrikbereich" so, dass er alle Projekte mit Datenbankinstanzen umfasst.
Warum: Metrikbereiche ermöglichen es einem einzelnen Monitoring Workspace, Metriken aus mehreren Projekten zu aggregieren und anzuzeigen, wodurch eine einheitliche Ansicht ohne Datenreplikation oder komplexe Konfiguration bereitgestellt wird.
Cloud SQL-Instanzen in Entwicklungs-, Staging- und Produktionsumgebungen konsistent und mit Versionskontrolle bereitstellen und verwalten.
Verwenden Sie Terraform mit dem Google Cloud-Anbieter. Definieren Sie ein Cloud SQL-Modul und verwenden Sie separate `.tfvars`-Dateien für jede Umgebung.
Warum: Terraform bietet Infrastructure as Code (IaC), was wiederholbare, auditierbare und versionskontrollierte Bereitstellungen ermöglicht. Dies vermeidet manuelle Konfigurationsfehler und gewährleistet Konsistenz über Umgebungen hinweg.
Ein Auftragnehmer benötigt temporären, erhöhten Datenbankzugriff, der nach 4 Stunden automatisch widerrufen werden muss.
Erteilen Sie die erforderliche IAM-Rolle mit einer IAM Condition, die einen zeitbasierten Ausdruck (`request.time < timestamp(...)`) verwendet.
Warum: IAM Conditions bieten eine native, sichere Möglichkeit, zeitlich begrenzten Zugriff zu gewähren, ohne manuelle Bereinigung, die fehleranfällig ist. Der Zugriff wird nach Ablauf des Zeitstempels automatisch verweigert.
Eine Sicherheitsrichtlinie erfordert, dass die Verschlüsselung aller Datenbankdatenträger kundenverwaltete Schlüssel (CMEK) mit kontrollierter Rotation verwendet.
Konfigurieren Sie die Cloud SQL- oder AlloyDB-Instanz so, dass sie einen Schlüssel von Cloud KMS verwendet. Konfigurieren Sie die automatische Rotation des KMS-Schlüssels.
Warum: CMEK bietet Kontrolle und Auditierbarkeit über die für die ruhende Verschlüsselung verwendeten Schlüssel. Cloud KMS verwaltet den Schlüssel-Lebenszyklus, einschließlich der automatisierten Rotation, nahtlos.
Die Compliance erfordert die Erfassung aller auf einer Cloud SQL for PostgreSQL-Instanz ausgeführten SQL-Abfragen, wobei die Protokolle 7 Jahre lang aufbewahrt werden.
Aktivieren Sie die `pgaudit`-Erweiterung auf der Instanz. Konfigurieren Sie Cloud Audit Logs für den Datenzugriff. Erstellen Sie eine Log-Senke von Cloud Logging zu BigQuery für die langfristige Aufbewahrung und Analyse.
Warum: pgaudit bietet detaillierte Audits auf SQL-Ebene. Das Sinken von Logs nach BigQuery ist das Standard, kostengünstige Muster für die langfristige, durchsuchbare Log-Aufbewahrung über die Standardeinstellungen von Cloud Logging hinaus.
Datenanalysten müssen rechenintensive analytische Abfragen auf produktiven Cloud SQL-Daten ausführen, ohne die transaktionale Workload zu beeinträchtigen.
Erstellen Sie ein Lesereplikat und leiten Sie alle analytischen Abfragen dorthin. Für komplexere Analysen verwenden Sie BigQuery Federated Queries gegen das Lesereplikat.
Warum: Ein Lesereplikat isoliert den analytischen Lese-Traffic vollständig von der primären Instanz und schützt die OLTP-Leistung. Federation ermöglicht die Nutzung der leistungsstarken BigQuery-Engine ohne eine separate ETL-Pipeline.
Ein Bigtable-Cluster zeigt eine ungleichmäßige CPU-Auslastung, wobei einige Knoten stark ausgelastet sind, während andere untätig sind, was auf einen Leistungsengpass hindeutet.
Verwenden Sie das Key Visualizer Tool in der Cloud Console, um die Zugriffsmuster zu analysieren und die spezifischen Zeilenschlüsselbereiche zu identifizieren, die zu häufig aufgerufen werden (Hotspotting).
Warum: Key Visualizer ist das speziell entwickelte Diagnosetool für Bigtable-Leistungsprobleme. Es bietet eine Heatmap des Schlüsselzugriffs und erleichtert die Identifizierung von Hotspots, die durch ein Schema-Redesign behoben werden müssen.
Müssen Änderungen von einer Cloud SQL OLTP-Datenbank in ein BigQuery-Data Warehouse nahezu in Echtzeit replizieren.
Verwenden Sie Datastream, um einen Change Data Capture (CDC)-Stream von der Quell-Cloud SQL-Instanz direkt nach BigQuery zu konfigurieren.
Warum: Datastream ist ein verwalteter CDC-Dienst mit geringer Latenz, der Datenbankprotokolle liest, wodurch die Auswirkungen auf die Quelle minimiert werden. Er verarbeitet Schemaänderungen und liefert Änderungen zuverlässig an BigQuery.
Eine Cloud Run-Anwendung erschöpft Datenbankverbindungen aufgrund schneller Skalierung während Verkehrsspitzen.
Stellen Sie den Cloud SQL Auth Proxy als Sidecar-Container bereit und konfigurieren Sie ihn für Connection Pooling (oder verwenden Sie ihn mit einem dedizierten Pooler wie PgBouncer).
Warum: Serverless-Plattformen können auf Tausende von Instanzen skaliert werden und Datenbankverbindungslimits überfordern. Ein Connection Pooler multiplexiert diese zahlreichen, kurzlebigen Anwendungsverbindungen auf einen kleinen, stabilen Satz von Datenbankverbindungen.
Migration einer großen (5 TB) lokalen MySQL-Datenbank zu Cloud SQL for MySQL mit einer maximalen Ausfallzeit von 30 Minuten.
Verwenden Sie den Database Migration Service (DMS), um einen kontinuierlichen Replikationsjob zu konfigurieren. DMS führt eine initiale Ladung durch und streamt dann Änderungen bis zur Umstellung.
Warum: DMS ist die verwaltete Lösung für Migrationen mit minimaler Ausfallzeit. Kontinuierliche Replikation bedeutet, dass die einzige Ausfallzeit die Zeit ist, die benötigt wird, um Schreibvorgänge zu stoppen, auf die endgültige Synchronisierung zu warten und die Anwendung auf die neue Datenbank zu verweisen.
Migration einer Oracle-Datenbank zu AlloyDB für PostgreSQL, einschließlich komplexer PL/SQL-gespeicherter Prozeduren.
Verwenden Sie DMS für die Datenmigration. Verwenden Sie Schema-Konvertierungstools (wie Ora2Pg oder DMS Schema Conversion), um Schemata und PL/SQL nach PL/pgSQL zu konvertieren, gefolgt von manueller Überprüfung und Tests.
Warum: Heterogene Migrationen erfordern sowohl Datenmigration (durch DMS abgedeckt) als auch Schema-/Code-Konvertierung. Automatisierte Tools erledigen ca. 80 % der Konvertierung, aber für Oracle-spezifische Funktionen ist immer manueller Aufwand erforderlich.
Müssen die Datenintegrität und Vollständigkeit nach der Migration einer Datenbank von einem lokalen Rechenzentrum zu Google Cloud überprüfen.
Verwenden Sie das Open-Source Data Validation Tool (DVT). Konfigurieren Sie es so, dass Zeilenanzahlen, Aggregationen auf Spaltenebene (min, max, sum) und Hashes auf Zeilenebene zwischen Quelle und Ziel verglichen werden.
Warum: DVT bietet ein umfassendes, skalierbares und anpassbares Framework zur Datenvalidierung, das über einfache Zeilenanzahlen hinausgeht und subtile Datenbeschädigungen oder Transformationsprobleme erkennt.
Migration einer geshardeten MySQL-Anwendung zu einer einzigen, global konsistenten Datenbank.
Verwenden Sie mehrere parallele Dataflow-Jobs, um jeden Shard gleichzeitig in eine einzige Cloud Spanner-Datenbank zu migrieren. Entwerfen Sie das Schema neu, um die Notwendigkeit des Shardings auf Anwendungsebene zu eliminieren.
Warum: Spanner wurde entwickelt, um komplexe Sharded-Architekturen zu ersetzen. Ein paralleler Migrationsansatz mit Dataflow ist der zeiteffizienteste Weg, große, geshardete Datensätze in Spanner zu konsolidieren.
Migration einer SQL Server-Datenbank, die Windows-Authentifizierung (Active Directory) verwendet, zu Cloud SQL für PostgreSQL.
Integrieren Sie Cloud SQL mit Cloud Identity mithilfe der IAM-Datenbankauthentifizierung. Synchronisieren Sie AD-Gruppen über GCDS mit Google Groups und ordnen Sie Datenbankrollen diesen Gruppen zu.
Warum: Dieser Ansatz repliziert das zentrale, gruppenbasierte Zugriffssteuerungsmodell von AD auf Cloud-native Weise, vermeidet die manuelle Benutzer-/Passwortverwaltung und nutzt bestehende Identitätsstrukturen.
Migration einer Anwendung von Amazon DynamoDB zu Cloud Bigtable.
Bilden Sie den DynamoDB-Verbundprimärschlüssel (Partitionsschlüssel + Sortierschlüssel) auf einen verketteten Bigtable-Zeilenschlüssel ab, getrennt durch ein Trennzeichen (z. B. `partitionKey#sortKey`).
Warum: Dieses Zeilenschlüsseldesign bewahrt die Abfragefunktionen des DynamoDB-Verbundschlüssels und ermöglicht effiziente Suchvorgänge nach Partitionsschlüsselpräfix und Bereichsscans auf dem Sortierschlüsselteil.
Eine Anwendung, die sich mit einer hochverfügbaren Cloud SQL-Instanz verbindet, muss ein zonalen Failover ohne manuelles Eingreifen überstehen.
Verbinden Sie sich mit der Datenbank über den Cloud SQL Auth Proxy mit dem Instanzverbindungsnamen (project:region:instance), nicht über eine statische IP-Adresse.
Warum: Die IP-Adresse der Instanz ändert sich während eines Failovers. Der Auth Proxy und der Instanzverbindungsname bieten einen stabilen Endpunkt, der automatisch auf die IP-Adresse der aktuellen primären Instanz aufgelöst wird.
Eine globale Spanner-Anwendung hat Benutzer in Nordamerika und Asien. Schreibvorgänge stammen hauptsächlich aus Nordamerika, aber asiatische Benutzer benötigen Lesezugriffe mit geringer Latenz.
Verwenden Sie eine Multi-Region-Konfiguration mit der Leader-Region in Nordamerika (`nam*`). Lesezugriffe in Asien werden von lokalen Read-Only-Replikaten bedient.
Warum: Schreibvorgänge in Spanner werden über die Leader-Region geleitet, daher minimiert die Platzierung in der Nähe der Schreibquelle die Schreiblatenz. Lesereplikate in anderen Regionen bieten Lesezugriffe mit geringer Latenz für global verteilte Benutzer.
Eine von AlloyDB unterstützte Anwendung hat ein Lese-Schreib-Verhältnis von 10:1 und muss skaliert werden, um hohen Lese-Traffic zu bewältigen, während eine Verfügbarkeit von 99,99 % aufrechterhalten wird.
Konfigurieren Sie die primäre Instanz mit hoher Verfügbarkeit und fügen Sie mehrere Read Pool-Instanzen hinzu. Leiten Sie den Lese-Traffic an den Read Pool weiter.
Warum: AlloyDB High Availability bietet das 99,99 % SLA. Read Pool-Instanzen sind für horizontale Lese-Skalierung konzipiert und entlasten die primäre Instanz durch die Umleitung des Traffics auf dedizierte, leseoptimierte Knoten.
Eine latenzempfindliche Cloud SQL-Instanz mit SSD-Speicher weist eine unzureichende I/O-Leistung auf.
Erhöhen Sie die bereitgestellte Speichergröße der Instanz.
Warum: In Cloud SQL skalieren sowohl Lese- als auch Schreib-IOPS linear mit der Menge des bereitgestellten persistenten Disk-Speichers. Die Erhöhung der Disk-Größe ist der direkte Weg, um die verfügbaren IOPS zu erhöhen.
Müssen eine riskante Schemaänderung an einer kritischen Cloud SQL-Datenbank mit schneller Rollback-Fähigkeit bereitstellen.
Erstellen Sie ein Lesereplikat der Produktionsinstanz (Blau). Promoten Sie das Replikat zu einer eigenständigen Instanz (Grün), wenden Sie die Schemaänderungen an und validieren Sie diese. Leiten Sie dann den Anwendungsverkehr zur grünen Instanz um. Halten Sie die blaue Instanz für einen Rollback am Laufen.
Warum: Dieses Muster ermöglicht umfassende Tests von Änderungen an einer produktionsgroßen Datenkopie, ohne das Live-System zu beeinträchtigen. Der Traffic kann sofort umgeschaltet werden, und ein Rollback ist so einfach wie das Zurückleiten des Traffics zur blauen Instanz.
Müssen vierteljährlich einen Datenbank-Disaster-Recovery-Plan testen, ohne die Produktionsumgebung zu beeinträchtigen.
Erstellen Sie eine temporäre Testinstanz, indem Sie aus einem aktuellen Produktionsbackup wiederherstellen. Führen Sie die dokumentierten DR-Verfahren gegen diese Testinstanz aus, einschließlich simulierter Failover- und Anwendungswiederverbindungstests.
Warum: Das Testen auf einem wiederhergestellten Backup bietet eine realistische Umgebung, um RTO/RPO und Wiederherstellungsverfahren zu validieren, ohne das Risiko eines Produktionsausfalls zu verursachen.
Ein Cloud Run-Dienst muss sich sicher mit einer Cloud SQL-Instanz verbinden, ohne dass der Traffic über das öffentliche Internet geleitet wird.
Konfigurieren Sie Cloud SQL mit einer privaten IP. Erstellen Sie einen Serverless VPC Access Connector im selben VPC und konfigurieren Sie den Cloud Run-Dienst so, dass der Traffic darüber geleitet wird.
Warum: Dies ist das Standard, sichere Muster für die Verbindung von Serverless Compute mit VPC-nativen Ressourcen. Der Connector überbrückt die Serverless-Umgebung und Ihr VPC und hält den gesamten Traffic im privaten Netzwerk von Google.
Hinzufügen einer neuen, nicht-nullfähigen Spalte zu einer massiven, aktiv beschriebenen Cloud Spanner-Tabelle ohne Ausfallzeiten.
1. Fügen Sie die Spalte als nullfähig hinzu. 2. Aktualisieren Sie den Anwendungscode, um in die neue Spalte zu schreiben. 3. Füllen Sie vorhandene Zeilen in Batches mit Dataflow auf. 4. Ändern Sie die Spalte nach dem Auffüllen auf NOT NULL.
Warum: Dieser mehrstufige Prozess ist das Standardmuster für Online-Schemaänderungen bei großen Tabellen. Er vermeidet das Sperren der Tabelle über einen langen Zeitraum oder das Verursachen eines massiven, leistungsbeeinträchtigenden Auffüllvorgangs in einer einzigen Transaktion.
