Google ACE: Speicher, Datenbanken und Datendienste — Lernleitfaden

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Teil des Google Associate Cloud Engineer — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Dieser Abschnitt dient als praxisorientiertes, auf den Betrieb fokussiertes Nachschlagewerk für Google Cloud-Speicher, Datenbanken und analytische Datendienste. Er legt den Schwerpunkt auf Konfigurationsmuster, Zugriffskontrolle, Haltbarkeitsmechanismen, Leistungs- und Kostenmerkmale sowie sichere Wiederherstellungsverfahren. Das Ziel ist es, Ihnen zu helfen, zu entscheiden, welcher Dienst für eine bestimmte Workload verwendet werden soll, die betrieblichen Kompromisse zu verstehen und gängige Ausfallszenarien vorherzusehen.

Cloud Storage: Design, Zugriff, Lebenszyklus und Schutz

Cloud Storage ist ein langlebiger, hochverfügbarer Objektspeicher für unstrukturierte Daten und Backups.

• Buckets und Objekte: Buckets sind globale Namespaces an einem Standort (Region oder Dual-/Multi-Region), die unveränderliche Objektversionen enthalten. Wählen Sie den Bucket-Standort, um den Egress-Traffic zu minimieren und die Anforderungen an den Datenspeicherort zu erfüllen.
• Speicherklassen: Verwenden Sie Standard (häufiger Zugriff), Nearline (ca. 30 Tage min.), Coldline (ca. 90 Tage min.) und Archive (ca. 365 Tage min.) basierend auf der Zugriffshäufigkeit. Für DR-Backups ist Coldline eine gängige Standardeinstellung. Sie können Klassen pro Objekt innerhalb eines Buckets mischen.
• Lebenszyklusregeln: Automatisieren Sie Übergänge und Löschungen anhand der Bedingungen Age, CreatedBefore, MatchesStorageClass und NoncurrentVersion. Beispiel für einen Übergang nach 90 Tagen und eine Löschung nach 365 Tagen:
  1. lifecycle.json:

undefined

2. Anwenden:

undefined

• Aufbewahrung und Legal Holds: Aufbewahrungsrichtlinien verhindern das Löschen oder Ändern von Objekten vor Ablauf des Zeitraums; das Sperren der Richtlinie ist unumkehrbar. Legal Holds gelten pro Objekt und müssen vor dem Löschen aufgehoben werden.

Zugriffskontrolle und Freigabe:

• Einheitlich vs. feingranular: Bevorzugen Sie den einheitlichen Zugriff auf Bucket-Ebene (UBLA), um Berechtigungen ausschließlich mit IAM zu verwalten. Feingranularer Zugriff (Objekt-ACLs) ist veraltet und erschwert die Überprüfbarkeit und Weitergabe von Berechtigungen. Die Aktivierung von UBLA deaktiviert ACLs und kann sich sofort auf bestehende Integrationen auswirken, die auf ACLs angewiesen waren.
• Signierte URLs: Für kurzlebigen Zugriff ohne Google-Identität verwenden Sie signierte URLs. Vermeiden Sie Service-Account-Schlüsseldateien, indem Sie mit IAM signieren:

undefined

Stellen Sie sicher, dass das Service-Konto die Rolle „Service Account Token Creator“ für sich selbst oder über eine Signer-Rolle besitzt.

• Verschlüsselung: Serverseitige Verschlüsselung ist Standard; aktivieren Sie CMEK auf Bucket- oder Objektebene, wenn Sie Kontrolle über Schlüssel und Audit-Protokolle benötigen. Überwachen Sie die Verfügbarkeit und Rotation von KMS-Schlüsseln; die Nichtverfügbarkeit von CMEK blockiert Uploads und Entschlüsselungen.
• Versionierung: Aktivieren Sie die Objektversionierung, um nach Überschreibungen/Löschungen nicht aktuelle Versionen beizubehalten. Kombinieren Sie dies mit Lebenszyklusregeln, um nicht aktuelle Versionen ablaufen zu lassen und das Speicherwachstum zu kontrollieren. Beachten Sie die clientseitige Logik zur Auflistung, wenn viele Versionen existieren.

Ausfallszenarien und Gegenmaßnahmen:

• Versehentliches Löschen oder Überschreiben: Verwenden Sie Versionierung und Aufbewahrungsrichtlinien. Für strikte Compliance sperren Sie die Aufbewahrungsrichtlinie.
• Falsch konfigurierter öffentlicher Zugriff: Erzwingen Sie Public Access Prevention und UBLA. Führen Sie regelmäßige Audits mit Cloud Asset Inventory und dem Policy Analyzer durch.
• Übermäßige Kosten: Lebenszyklusregeln, Klassen auf Objektebene und „Requester Pays“ reduzieren Überraschungen. Überwachen Sie dies mit Metriken und Budgets von Cloud Monitoring.

Nützliche Befehle:

• Bucket mit UBLA und Aufbewahrungsrichtlinie erstellen:

undefined

undefined

Block- und Dateispeicher für Compute-Workloads

Wählen Sie den Speicher basierend auf Zugriffsmuster, Leistungsanforderungen und Haltbarkeitsanforderungen für Compute Engine und GKE.

• Persistent Disk (PD): Langlebiger Blockspeicher, zonal oder regional. Typen: Standard (HDD) für sequenziellen Durchsatz; Balanced (pd-balanced) und SSD (pd-ssd) für niedrige Latenz und hohe IOPS. Regionale PDs replizieren synchron über Zonen hinweg und ermöglichen eine schnellere Wiederherstellung. PDs können gesnapshottet, online in der Größe verändert und schreibgeschützt an mehrere VMs angehängt werden (Single-Writer für Lese-/Schreibzugriff).
  • Abwägungen: Höhere IOPS-Kosten bei SSD; HDD ist kostengünstig, hat aber eine hohe Latenz bei zufälligen I/O-Operationen. Regionale PDs kosten mehr, reduzieren aber die RTO.
• Local SSD: Über NVMe oder SCSI angebundener, flüchtiger Speicher mit sehr hohen IOPS und niedriger Latenz. Daten gehen beim Stoppen der VM oder bei der Wartung des Hosts verloren; verwenden Sie ihn nur für flüchtige Caches oder replizierte Daten. Sichern oder replizieren Sie die Daten an anderer Stelle, um Datenverlust zu vermeiden.
• Filestore: Verwaltetes NFS für POSIX-konforme Semantik für gemeinsam genutzte Dateien. Die Basic-Tiers sind zonal; Enterprise und höhere Tiers bieten regionale Hochverfügbarkeit mit synchroner Replikation und höheren IOPS. Ideal für GCVE, HPC-Scratch-Speicher, Medien-Rendering und Anwendungen, die gemeinsames File-Locking benötigen.
  • Abwägungen: NFS führt clientseitiges Caching und Lock-Semantik ein; Durchsatz und Latenz unterscheiden sich je nach Tier; nicht geeignet für kleine, zufällige I/O-Operationen mit Latenzen im einstelligen Mikrosekundenbereich wie bei Local SSD.

Überlegungen zu Ausfällen:

• Host-Wartung: Datenverlust bei Local SSD; Schutz durch Anwendungsreplikation.
• Zonale Ausfälle: Unterbrechungen bei zonalen PDs und Basic Filestore; verwenden Sie regionale PDs oder Filestore Enterprise für Hochverfügbarkeit.
• Snapshot-Konsistenz: Für anwendungskonsistente PD-Snapshots mit dem Einfrieren des Dateisystems oder dem nativen Quiesce der Datenbank koordinieren, um Crash-Recovery-Fenster zu vermeiden.

Verwaltete Datenbanken und Datendienste

Cloud SQL (verwaltetes MySQL, PostgreSQL, SQL Server):

• Konfiguration: Wählen Sie Maschinentyp, Speichertyp, Verbindungen (private IP bevorzugt), autorisierte Netzwerke bei Verwendung einer öffentlichen IP, Wartungsfenster und Insights für die Leistungsdiagnose. Verwenden Sie Connection-Pooling (z. B. Cloud SQL Auth Proxy, PGbouncer), um die Verbindungs- und CPU-Limits einzuhalten.
• Hochverfügbarkeit: Regionale HA-Instanzen stellen eine Standby-Instanz in einer anderen Zone mit synchroner Speicherreplikation bereit; das Failover erfolgt automatisch. Rechnen Sie während des Failovers mit einem kurzen Zeitfenster, in dem Schreibvorgänge nicht verfügbar sind.
• Replikate: Lesereplikate zur Skalierung von Lesevorgängen und zur Auslagerung von BI; externe Replikation für Migrationen. Überwachen Sie den Replikations-Lag und entwerfen Sie idempotente Reader.
• Backups und PITR: Aktivieren Sie automatisierte Backups und Binär-/WAL-Logging für die Point-in-Time-Recovery. Testen Sie Wiederherstellungen regelmäßig.

undefined

• Fehlermodi: Lang andauernde Transaktionen blockieren Vacuum/Checkpointing; Verbindungsspitzen verursachen Thrashing; automatisches Speicherwachstum kann bei unzureichendem Kontingent ins Stocken geraten. Richten Sie Benachrichtigungen für CPU, Arbeitsspeicher, Verbindungen, Replikations-Lag und Festplattennutzung ein.

Cloud Spanner:

• Skalierung und Regionalität: Regionale oder multiregionale Instanzen mit synchroner Replikation und starker globaler Konsistenz. Skalieren Sie Knoten für Durchsatz und Speicher; die Platzierung der Leader-Region beeinflusst die Schreiblatenz.
• Schema und Schlüssel: Entwerfen Sie Primärschlüssel, um Hotspots zu vermeiden; verwenden Sie zusammengesetzte Schlüssel mit einem gehashten oder zufälligen Präfix für Zeitreihen, um Schreibvorgänge zu verteilen. Verwenden Sie sekundäre Indizes für Abfragemuster und erwägen Sie, häufig gefilterte Spalten zusammen zu speichern. Halten Sie Transaktionen klein und begrenzt, um Sperrkonflikte zu minimieren.
• Transaktionen: Stark konsistente, verteilte Transaktionen mit externer Konsistenz über TrueTime. Schreiblatenz durch das Quorum begrenzt; Konflikte führen zu abgebrochenen Transaktionen – wiederholen Sie den Vorgang mit Backoff.

Firestore und Bigtable:

• Firestore (Nativer Modus): Dokumentenspeicher mit Sammlungen, Echtzeit-Listenern, Transaktionen über bis zu 500 Dokumente pro Transaktion und starker Konsistenz für Dokumentenlesevorgänge und die meisten Abfragen. Am besten geeignet für Daten von Mobil-/Web-Apps, hierarchisches JSON und ereignisgesteuerte Anwendungen.
• Bigtable: Wide-Column-Datenbank für Petabyte-Skalierung und Latenzzeiten unter 10 ms. Nur Transaktionen für einzelne Zeilen; entwerfen Sie Zeilenschlüssel, um Hotspotting zu vermeiden. Ideal für Zeitreihen, IoT, Personalisierung und Zähler im großen Maßstab. Nicht für Ad-hoc-Joins oder komplexe Aggregationen geeignet.

Memorystore:

• Redis und Memcached: In-Memory-Caches für Latenzzeiten im Mikrosekunden- bis Millisekundenbereich. Die Basic-Stufe hat keine HA; die Standard-Stufe bietet regionale HA mit automatischem Failover für Redis. Behandeln Sie sie als ephemer; nicht als primäres Datensystem (System of Record) verwenden.

BigQuery:

• Datasets und Tabellen: Organisieren Sie nach Dataset; steuern Sie den Zugriff auf Projekt-, Dataset-, Tabellen-, Spalten- und Zeilenebene. Verwenden Sie partitionierte und geclusterte Tabellen, um die gescannten Bytes und die Kosten zu kontrollieren.
• Lade- und Abfragejobs: Laden Sie Daten aus Cloud Storage, Cloud SQL-Exporten oder durch Streaming-Inserts. Verwenden Sie Probeläufe (Dry Runs), um die Kosten abzuschätzen:

undefined

• Zugriffskontrolle: Vergeben Sie die Rolle BigQuery Data Viewer auf Dataset-Ebene für schreibgeschützte Nutzer; verwenden Sie autorisierte Ansichten oder Sicherheit auf Zeilen-/Spaltenebene für das Prinzip der geringsten Rechte (Least Privilege).

Kompromisse bei Datenverschiebung, Migration, Validierung und Betrieb

Migration und Übertragung:

• Database Migration Service (DMS): Für homogene Migrationen zu Cloud SQL mit minimaler Ausfallzeit durch Replikation. Validierung der Umstellung (Cutover) mit Latenz-Metriken (Lag) und Prüfsummenvergleichen.
• Cloud Storage-Übertragungen: Storage Transfer Service für wiederkehrende oder ereignisgesteuerte Übertragungen; gsutil -m rsync für einmalige synchronisierte Kopien mit Prüfsummen; Transfer Appliance für große Offline-Verschiebungen.
• Import/Export: Cloud SQL exportiert nach Cloud Storage; der Re-Import unterstützt das PITR-Bootstrap und die Datenverifizierung. BigQuery unterstützt Batch-Ladevorgänge aus Cloud Storage und Exporte nach Avro/Parquet für die nachgelagerte Nutzung.
• Validierung: Verwenden Sie Objekt-Prüfsummen (CRC32C), Zeilenzählungen, Stichprobenabfragen und Invarianten auf Anwendungsebene. Für BigQuery: Vergleichen Sie GROUP BY-Zählungen oder Hashes zwischen Quelle und Ziel.

Kompromisse bei Leistung, Verfügbarkeit, Kapazität und Kosten:

• Cloud Storage: Optimieren Sie den Egress-Traffic durch die gemeinsame Platzierung (Co-Location) von Rechenressourcen; wählen Sie Klassen nach Zugriffshäufigkeit; verwenden Sie Dual-/Multi-Region für zonenübergreifende Ausfallsicherheit und höhere Verfügbarkeit bei höheren Speicherkosten.
• PD/Filestore: SSD für I/O mit geringer Latenz; HDD für Durchsatz; regionale Replikation für HA; richtige Dimensionierung der IOPS zur Vermeidung von Drosselung (Throttling).
• Cloud SQL: Vertikale Skalierung ist einfach, aber begrenzt; Lesereplikate entlasten den Lesetraffic; HA erhöht die Verfügbarkeit, aber nicht die Lesekapazität; die Speicherklasse beeinflusst Latenz und Kosten.
• Spanner: Skaliert horizontal mit starker Konsistenz; die höheren Kosten werden durch globale RPO/RTO und vereinfachtes Sharding ausgeglichen. Schreibvorgänge reagieren empfindlich auf das Schlüsseldesign und die Latenz der Leader-Region.
• Firestore/Bigtable/Memorystore: Wählen Sie nach Latenz, Datenmodell und Konsistenz. In-Memory-Caches reduzieren die Datenbanklast, erhöhen aber die Komplexität der Cache-Invalidierung.
• BigQuery: On-Demand-Kosten sind proportional zu den gescannten Bytes; Partitionierung/Clustering und Predicate Pushdown reduzieren die Ausgaben. Flat-Rate-Reservierungen tauschen Vorhersehbarkeit gegen eine Verpflichtung (Commitment) ein.

Fehlerbehebung und sichere Wiederherstellung:

• Cloud Storage: Verwenden Sie Objektversionierung und Aufbewahrungsrichtlinien zur Wiederherstellung; prüfen Sie Cloud Logging Data Access Logs zur Überwachung von Lese-/Schreibereignissen; stellen Sie sicher, dass CMEK-Schlüssel während der Wiederherstellung aktiviert sind.
• PD/Filestore: Wiederherstellung aus Snapshots oder Backups; führen Sie fsck und Datenbank-Wiederherstellungsmodi aus; stellen Sie die Konsistenz durch Stilllegen auf Anwendungsebene (App-Level Quiesce) vor der Snapshot-Erstellung sicher.
• Cloud SQL: Für PITR auf einer neuen Instanz wiederherstellen, um Datenverlust auf der primären Instanz zu vermeiden; mit schreibgeschützten Tests verifizieren; Firewall und privates DNS für sichere Umstellungsmuster (Cutover) beibehalten.
• Spanner/Bigtable: Untersuchen Sie Hotspotting durch unausgeglichenen Schlüsselzugriff (Key Access Skew); verwenden Sie Monitoring zur Verfolgung von Latenz und Drosselung; implementieren Sie Backoff und Wiederholungsversuche für abgebrochene Transaktionen oder ratenlimitierte Operationen.
• BigQuery: Diagnostizieren Sie langsame Abfragen über die Ausführungsdetails; fügen Sie Partitionen und Clustering hinzu; beschränken Sie SELECT *; materialisieren Sie Zwischenergebnisse, wenn angebracht. Stellen Sie gelöschte Tabellen innerhalb des Zeitreisefensters (Time Travel Window) wieder her, indem Sie einen Snapshot wiederherstellen oder von einem Snapshot-Zeitpunkt kopieren.

Praktisches Problemszenario

Contoso Retail konsolidiert Sicherungs- und Analysedaten, verschärft gleichzeitig die Zugriffskontrollen und aktiviert die Point-in-Time-Recovery (PITR) für seine Transaktionssysteme. Die Anforderungen sind: Speicherung von Anwendungs-Backups mit automatisiertem Tiering, Bereitstellung von kurzlebigen Dateifreigaben für Dritte, Aktivierung von PITR für einen kleinen relationalen Workload und Schätzung der Kosten für Analyseabfragen vor deren Ausführung.

Vorgehensweise:

1. Erstellen eines regionalen Cloud Storage Buckets mit UBLA, Aufbewahrungsrichtlinie und Lebenszyklus (Lifecycle).
   • Befehl:

undefined

undefined

undefined

• Begründung: UBLA zentralisiert die Autorisierung in IAM und verbessert die Auditierbarkeit. Eine einjährige Aufbewahrungsfrist verhindert versehentliches Löschen. Der Lebenszyklus verschiebt Backups nach 90 Tagen nach Coldline und löscht sie bei Ablauf, um die Kosten zu kontrollieren.

2. Gewähren von reinem Schreibzugriff für Backup-Jobs über ein dediziertes Service Account.
   • Befehl:

undefined

• Begründung: storage.objectCreator verhindert die Manipulation von Metadaten und das Auslesen sensibler Backups und folgt damit dem Prinzip der geringsten Rechte (Least Privilege).

3. Teilen eines sensiblen Backups mit einem Anbieter für vier Stunden mithilfe einer signierten URL, ohne Schlüssel zu verteilen.
   • Befehl:

undefined

• Begründung: Zeitlich begrenzter, identitätsloser Zugriff vermeidet die Erstellung externer Identitäten oder langlebiger Geheimnisse. Die Identitätsübernahme (Impersonation) nutzt zentralisiertes, KMS-gestütztes Signieren und eliminiert das Risiko von durchgesickerten Schlüsseln.

4. Aktivieren von Cloud SQL Backups und PITR für die Bestelldatenbank.
   • Befehl:

undefined

• Begründung: Automatisierte Backups plus Binär-/WAL-Protokollierung ermöglichen Wiederherstellungspunkte zu jeder Sekunde innerhalb des Aufbewahrungsfensters und schützen so vor logischer Korruption und Bedienungsfehlern.

5. Testen der Wiederherstellung durch Wiederherstellen auf einer neuen Instanz und Validieren der Daten vor der Umstellung (Cutover).
   • Befehl:

undefined

undefined

• Begründung: Die Wiederherstellung auf einer separaten Instanz vermeidet die Beeinträchtigung der Produktion und ermöglicht die Validierung durch Prüfsummen und Stichprobenabfragen vor einer Umstellung auf DNS- oder Anwendungsebene.

6. Schätzen der BigQuery-Abfragekosten mit einem Probelauf (Dry Run) und Optimierung durch Partitionierung.
   • Befehl:

undefined

• Begründung: Probeläufe zeigen die zu scannenden Bytes an; die Sicherstellung, dass sale_date eine Partitionsspalte mit einem begrenzten Prädikat ist, reduziert die gescannten Bytes und kontrolliert die On-Demand-Kosten.

7. Überwachen und Auditieren von Zugriffen.

   • Schritte:
     • Aktivieren von Data Access Logs für Cloud Storage und BigQuery.
     • Konfigurieren von Cloud Monitoring-Benachrichtigungen für Cloud SQL-Verbindungen, Festplattennutzung und fehlgeschlagene Backups.
   • Begründung: Data Access Logs bieten Einblick in Lese-/Schreibvorgänge auf Objektebene für die Compliance. Proaktive Benachrichtigungen verkürzen die MTTR und stellen sicher, dass Backups und PITR wirksam bleiben.

8. Dokumentieren von Fehlermodi und Runbooks.

   • Schritte:
     • Erfassen von Verfahren für die Wiederherstellung von Objektversionen, den Widerruf signierter URLs, Cloud SQL PITR und die Wiederherstellung von BigQuery-Tabellen mithilfe von Time Travel.
   • Begründung: Klare, getestete Runbooks reduzieren das Betriebsrisiko bei Vorfällen und standardisieren sichere Wiederherstellungsverfahren teamübergreifend.

← VPC-Netzwerke · Alle Domänen · Bereitstellung →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Google durchsuchen →