Google PCD: Applicatiedata, state en opslagpatronen — Studiegids

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Onderdeel van de Google Professional Cloud Developer — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Moderne applicaties op Google Cloud combineren routinematig meerdere datastores om een balans te vinden tussen latency, consistentie, schaalbaarheid, kosten en operationele complexiteit. Het selecteren van geschikte services en patronen — en het begrijpen van hun faalscenario’s — is essentieel voor een veerkrachtig ontwerp. Dit gedeelte geeft een samenvatting van praktische richtlijnen voor Cloud SQL, Cloud Spanner, Firestore, Bigtable, Memorystore en Cloud Storage, en behandelt migraties, partitionering en databescherming.

Relationele Data op Cloud SQL

Cloud SQL biedt beheerde MySQL, PostgreSQL en SQL Server met de vertrouwde semantiek van een RDBMS.

Private connectiviteit
- Gebruik een private IP om databaseverkeer binnen je VPC te houden. Dit elimineert de noodzaak voor publieke ingress-regels en IP-allowlists en vermijdt de complexiteit van NAT egress.
- Zorg ervoor dat routes en firewallregels verkeer van VPC naar de instance toestaan. Naamresolutie voor het private IP-adres wordt automatisch afgehandeld wanneer private IP is ingeschakeld.
- Voor serverless (Cloud Run, App Engine, Cloud Functions) geef je de voorkeur aan Cloud SQL connectors, die IAM-authenticatie en TLS afhandelen, zelfs met een private IP.
Hoge beschikbaarheid en replica’s
- Regionale HA plaatst de primary en standby in verschillende zones met synchrone schijfreplicatie. Verwacht een korte verbindingsonderbreking bij een failover; applicaties moeten tijdelijke fouten opnieuw proberen (retry) en opnieuw verbinding maken.
- Read replica’s zijn asynchroon en nemen read-verkeer over. Gebruik cross-region replica’s voor DR en ‘read proximity’, met het besef dat replica’s ’eventually consistent’ zijn.
- Promoveer een read replica voor herstel of geplande rolwissels. Test de promotieprocedures regelmatig.
Back-ups en point-in-time recovery
- Schakel geautomatiseerde back-ups en transactie-/PITR-logs in. Plan back-ups tijdens daluren om IO-conflicten te verminderen.
- Bewaar meerdere kopieën en valideer periodiek restores naar een aparte instance. Een back-up die je niet kunt herstellen is operationeel gezien gelijk aan geen back-up.
Connection pools en limieten
- Cloud SQL dwingt een maximum aantal verbindingen af; een overmaat aan kortstondige verbindingen veroorzaakt CPU-thrashing en latency. Gebruik pooling aan de applicatiekant (bijv. HikariCP, PgBouncer, ProxySQL).
- Baseer de grootte van de pools op het aantal CPU-cores en de concurrency van de workload, niet alleen op het geheugen van de instance. Begin klein en schaal op basis van empirische data.
- Voor ephemeral/serverless compute onderhoudt de taalspecifieke Cloud SQL connector een pool per revisie; beperk desondanks de concurrency om ‘connection storms’ na cold starts te voorkomen.
Datapartitionering en prestaties
- Shard grote multi-tenant schema’s per klant of regio om conflicten te verminderen. Houd ‘hot tenants’ waar mogelijk geïsoleerd.
- Maak ‘covering indexes’ zorgvuldig aan; te veel indexen vertragen writes en verhogen de opslag. Verifieer de kardinaliteit en de selectiviteit van predicaten.
- Gebruik ‘optimistic locking’ of SELECT FOR UPDATE voor ‘hot rows’; tune autovacuum (PostgreSQL) of InnoDB-instellingen (MySQL) voor aanhoudende write-workloads.

Veelvoorkomende faalscenario’s en oplossingen:

Thundering herds na het herstarten van VM’s/nodes: beperk de poolgrootte en gebruik ’exponential backoff’.
Replica lag voor ‘read-your-writes’: pin reads aan de primary wanneer sessieconsistentie vereist is.
HA failover ‘flaps’ door ’noisy neighbors’ of onderhoud: implementeer retries voor verbindingen en transacties met idempotentie.

Planet-scale Relationeel op Cloud Spanner

Cloud Spanner levert horizontale schaalbaarheid met opties voor globale consistentie.

Consistentie en transacties
- Strong reads en read-write transacties bieden strikte externe consistentie met behulp van TrueTime; commits wachten kort om lineariseerbaarheid te garanderen.
- Stale en ‘bounded-staleness’ reads verlagen de latency en verbeteren de beschikbaarheid voor read-heavy workloads wanneer de versheid van data iets minder strikt mag zijn.
- Read-only transacties omvatten meerdere reads op een specifiek tijdstip zonder locks; gebruik dit voor consistente snapshots voor analytics.
Regionaliteit, beschikbaarheid en latency
- Regionale instances bieden hoge beschikbaarheid binnen een regio. Multi-regionale configuraties (bijvoorbeeld nam-asia-eur1) leveren zeer hoge beschikbaarheid en low-latency lokale reads over continenten heen, met globaal consistente writes.
- Kies instance-configuraties die aansluiten bij de geografie van je gebruikers; write-latencies nemen toe met de omvang van het intercontinentale quorum.
Schaalbaarheid en schema-ontwerp
- Spanner verdeelt data in ‘splits’ op basis van primary key-ranges, die over nodes worden gedistribueerd. Hotspotting treedt op wanneer sleutels monotoon toenemen. Vermijd sleutels zoals auto-increment ID’s of altijd oplopende timestamps als eerste deel van de sleutel.
- Gebruik samengestelde primary keys die writes verdelen (bijvoorbeeld, customer_hash, customer_id, reverse_timestamp).
- Interleaved tables plaatsen child-rijen fysiek bij de parent-rijen voor lokaliteit en efficiënte joins. Gebruik dit wanneer de kardinaliteit en toegangspatronen van de child sterk correleren met de parent. Vul aan met secundaire indexen; overweeg STORING-clausules om table lookups te verminderen.
- Monitor CPU, opslag en high-priority versus best-effort operaties; schaal het aantal nodes op om headroom te behouden onder P95-latencies.
Operationele patronen
- Clients gebruiken session pools; tune het min/max aantal sessies om ‘creation storms’ te voorkomen. Retries moeten beperkt en idempotent zijn; bij een ABORTED-status, probeer read-write transacties opnieuw met ‘backoff’.
- Back-ups zijn lichtgewicht en consistent; valideer restores naar aparte instances. Change streams en CDC-integraties kunnen downstream systemen voeden.

Afwegingen:

Sterke globale writes voegen een ‘commit-wait’ toe; gebruik ‘stale reads’ voor UX-kritieke paden die voornamelijk uit reads bestaan.
Interleaving verbetert de lokaliteit maar kan de write-druk concentreren; test met verkeer dat representatief is voor productie.

Operationele NoSQL-opslag: Firestore en Bigtable

Kies het NoSQL-model dat past bij de querypatronen en het doorvoerprofiel.

Firestore (document)
- Datamodel: collecties bevatten documenten; documenten kunnen subcollecties hebben. Modelleer rond querypatronen; vermijd diepe ‘fan-out’-schrijfacties naar afzonderlijke “hot” documenten.
- Toegang en transacties: het lezen van documenten en query’s zijn sterk consistent in de Native-modus. Gebruik ‘batched writes’ voor ‘at-most-once’ atomiciteit over meerdere documenten, en transacties voor ‘read-modify-write’ met ‘contention checks’.
- Indexen: indexen voor één veld zijn automatisch. Samengestelde indexen voor meerdere velden moeten worden gedefinieerd bij gebruik van meerdere ‘range’/‘inequality’-filters of sorteervolgordes. Denormalisatie wordt vaak toegepast om query’s ‘index-only’ te maken.
- Clientsynchronisatie: real-time listeners streamen wijzigingen; offline caches synchroniseren met ’last-write-wins’-semantiek. Bescherm tegen onbegrensde ’listener fan-out’; geef de voorkeur aan query-cursors en filters.
- Limieten en faalscenario’s: de schrijfsnelheid naar één document wordt geserialiseerd; aanhoudende updates met hoge QPS naar één document creëren ‘contention’. Gebruik ‘sharded counters’ met N subdocumenten en aggregeer bij het lezen.
Cloud Bigtable (wide-column)
- Het ontwerp van de ‘row key’ is van het grootste belang. Bigtable partitioneert rijen lexicografisch; de voorste segmenten van de sleutel bepalen ‘hotspotting’. Vermijd sequentiële sleutels zoals timestamps vooraan of ‘unsharded’ gebruikers-ID’s.
- Patronen:
  - Omgekeerde timestamp in de sleutel voor het lezen van tijdreeksen: key = device#hash(device_id)#reverse_ts.
  - Hash of ‘bucket’ de eerste component om schrijfacties te spreiden: bucket = crc32(user_id) % 128.
- Sla kleine cellen met veel kolommen op; vermijd grote rijen die meerdere ’tablets’ omspannen. Maak gebruik van meerdere ‘column families’ voor toegangscontrole en scheiding van GC-beleid.
- Doorvoer en ‘serving’:
  - Gebruik meerdere clusters voor replicatie en regionale nabijheid voor leesacties; schrijfacties tussen clusters worden ’eventually consistent’.
  - Optimaliseer app-profielen en routing; onderhoud ruime ‘client-side thread pools’ en ‘channel pools’.
- GC en TTL: versie- en tijdgebaseerde GC verwijdert oude cellen asynchroon; data blijft bestaan tot ‘compaction’, dus vertrouw niet op onmiddellijke verwijdering voor wettelijke deadlines.

Patronen voor Caching en Object Storage

Memorystore (Redis/Memcached)
- Cachingstrategieën:
  - Read-through: de applicatie haalt data uit de cache; bij een ‘miss’ wordt de data uit de bron geladen en de cache gevuld.
  - Write-through: schrijfacties gaan synchroon naar de cache en de bron.
  - Write-behind: buffer schrijfacties in de cache en ‘flush’ asynchroon; wees voorzichtig vanwege het risico op dataverlies.
- Verval en invalidatie:
  - Pas TTL’s toe die overeenkomen met de tolerantie voor verouderde data. Invalideer sleutels bij wijzigingen in de ‘source of truth’; gebruik voor geaggregeerde caches versiesleutels om ‘stampedes’ te voorkomen.
  - Gebruik een ‘mutex’ of ‘single-flight’ om ‘cache stampedes’ op populaire sleutels te voorkomen.
- Sessies: sla kortstondige sessiedata op met een TTL; versleutel waarden of sla alleen ‘opaque tokens’ op als de data gevoelig is.
- Rate limiting met Redis:
  - Fixed-window: INCR met EXPIRE op een sleutel per identiteit.
  - Sliding-window of token-bucket voor vloeiendere limieten; overweeg Lua-scripts voor atomiciteit.
- Beschikbaarheid: de Basic-tier heeft geen failover; de Standard-tier biedt regionale HA. Behandel de cache als vluchtig; nooit als de gezaghebbende opslag.
Voorbeeld: eenvoudige ‘fixed-window rate limit’
- Commando’s:
  - INCR rate:login:USER123:20260903T1000
  - EXPIRE rate:login:USER123:20260903T1000 60
Cloud Storage
- Objecten en consistentie: sterke wereldwijde consistentie voor lees-, schrijf-, overschrijf-, verwijder- en lijstoperaties. Objecten zijn onveranderlijk (‘immutable’); updates creëren nieuwe generaties.
- Signed URL’s: verplaats grote uploads/downloads rechtstreeks tussen clients en buckets zonder proxy via uw app. Stel korte vervaltijden in; beperk de methode, het pad en de content-headers.
- Hervatbare uploads: gebruik voor bestanden >5 MB en onbetrouwbare netwerken; handel 5xx/429-fouten af met ’truncated exponential backoff’ en ‘resume tokens’.
- Lifecycle: definieer regels om opslagklassen te wijzigen, oude versies te verwijderen en retentie af te dwingen. Combineer met ‘object versioning’ voor veiligheid tijdens rollouts.
- Notificaties: integreer Pub/Sub-notificaties om ‘downstream’-verwerking te activeren bij het finaliseren/verwijderen van objecten, en voeg voorwaarden toe (ifGenerationMatch) ter bescherming tegen ‘race conditions’.
Voorbeeld: lokale bestanden uploaden
- gsutil cp ./data/*.parquet gs://my-bucket/ingest/

Migratie, Consistentie, Partitionering en Gegevensbescherming

Databasemigratie
- Kies online versus offline: online met Database Migration Service voor minimale downtime; offline voor eenvoud wanneer onderhoudsvensters acceptabel zijn.
- Schema-first: stem typen en beperkingen af; overweeg voor Spanner tools om MySQL/PostgreSQL-schema’s en -data te mappen, en stem vervolgens sleutels en indexen af voor distributie.
- Dual-run en cutover: schrijf tijdens een online migratie dubbel (dual-write) of repliceer changelogs. Valideer het aantal rijen, checksums en het gedrag van kritieke query’s vóór de definitieve cutover.
Schemamigraties en rollback
- Gebruik geversioneerde, geautomatiseerde migraties (bijvoorbeeld met een migratietool) als onderdeel van CI/CD. Ontwerp additieve, backward-compatible wijzigingen: voeg kolommen en indexen toe, voer een backfill uit, deploy code die beide versies leest/schrijft, en verwijder daarna de verouderde artefacten.
- Plan een rollback met datatransformaties: als de code-implementatie mislukt, wees dan voorbereid om nieuwe schrijfacties uit te schakelen en te vertrouwen op feature flags; vermijd destructieve migraties die een rollback blokkeren.
Transactionele versus eventually consistent workflows
- Gebruik ACID-transacties wanneer invarianten synchroon moeten gelden (bijv. geldoverboekingen, voorraadafname).
- Geef de voorkeur aan eventual consistency voor read-mostly, gebruikersgerichte features waar latentie de overhand heeft (feeds, zoekresultaten, tellers). Implementeer idempotency keys, outbox/Saga-patronen en retries met backoff.
- Combineer: commit de gezaghebbende staat in een transactionele store; publiceer events voor eventually consistent projecties.
Datapartitionering en verbindingsbeheer
- Partitioneer op tenant, geografie of workloadtype om hotspots te isoleren. Voor Bigtable en Spanner, codeer partitiesleutels in de primaire sleutels; voor Cloud SQL, gebruik schema-per-tenant of table sharding met routers.
- Beheer verbindingen:
  - Cloud SQL: pool en hergebruik verbindingen; beperk de concurrency; spreid cold starts.
  - Spanner: hergebruik sessies; warm pools op bij het opstarten; begrens retries.
  - Memorystore: hergebruik TCP-verbindingen; vermijd het opzetten van een verbinding per request.
Gegevensbescherming, archivering, herstelverificatie en verwijderingsgedrag
- Back-ups en archivering:
  - Cloud SQL: geautomatiseerde back-ups + PITR; test herstelacties.
  - Spanner: beheerde back-ups; test het herstellen naar een niet-productieomgeving.
  - Firestore: geplande exports naar Cloud Storage; verifieer imports.
  - Bigtable: back-ups en snapshots; test klonen-en-herstellen.
  - Cloud Storage: retentiebeleid, object holds en uniforme toegang op bucketniveau voor governance; archiveer naar koudere klassen via lifecycle-regels.
- Herstelverificatie: herstel periodiek naar geïsoleerde omgevingen en voer validatiequery’s en smoke tests voor de applicatie uit. Volg RTO/RPO ten opzichte van het beleid.
- Verwijderingsgedrag:
  - Bigtable GC en lifecycle zijn asynchroon—beloof geen onmiddellijke verwijdering.
  - Cloud Storage versioning behoudt generaties totdat lifecycle-regels ze verwijderen.
  - Firestore TTL en op export gebaseerde verwijderingen zijn asynchroon.
  - Ontwerp voor hard-deletion SLA’s processen die data markeren voor verwijdering, in een wachtrij plaatsen en de verwijdering verifiëren, compleet met auditlogs.

Praktijkscenario

Aurora Outfitters migreert een monolithisch e-commerceplatform naar Google Cloud. Ze moeten: 1) MySQL met een lift-and-shift verplaatsen om risico’s te verminderen, 2) 500 MB aan uploads van productmedia verwerken zonder de app te overbelasten, 3) de leesdoorvoer voor productcatalogi schalen, en 4) rate limits per gebruiker afdwingen tijdens verkooppieken.

Aanpak:

Migreer MySQL naar Cloud SQL met een privé-IP en regionale HA
- Reden: Een privé-IP elimineert publieke blootstelling en IP-allowlists, wat veilige connectiviteit vanaf GKE en Compute Engine vereenvoudigt. Regionale HA beschermt tegen zonale storingen; verwacht korte onderbrekingen van de verbinding bij een failover, dus de app zal herhaalbare transacties en logica om opnieuw te verbinden implementeren.
Schakel geautomatiseerde back-ups en PITR in, en valideer het herstel
- Reden: Geautomatiseerde back-ups en transactielogs maken point-in-time recovery mogelijk na gebruikers- of applicatiefouten. Een wekelijks gepland herstel naar een niet-productie-instance verifieert dat de back-ups bruikbaar zijn en meet de RTO.
Voeg een read replica toe voor het lezen van de catalogus
- Reden: Het verplaatsen van catalogusquery’s naar een read replica vermindert de contentie op de primary. De app leest van de primary wanneer write-after-read nodig is (winkelwagen/afrekenen), en van de replica voor het bladeren door de catalogus, waarbij rekening wordt gehouden met de afwegingen rondom replica lag.
Introduceer connection pooling aan de applicatiekant en beperk de concurrency
- Reden: PgBouncer/HikariCP beperkt en hergebruikt verbindingen, wat verbindingsstormen tijdens autoscaling en HA-failovers voorkomt. Pools worden gedimensioneerd op basis van CPU-cores, niet op het maximale aantal pods, om overbelasting te voorkomen.
Offload media-uploads naar Cloud Storage met signed URL’s en resumable uploads
- Reden: De app geeft kortstondige signed URL’s uit waarmee clients rechtstreeks kunnen uploaden. Resumable uploads zijn geschikt voor onbetrouwbare netwerken; de mediaservice luistert naar Pub/Sub finalize-notificaties om de verwerking te activeren. Precondition-headers (ifGenerationMatch) beschermen tegen overwrite races.
Implementeer Memorystore for Redis voor paginacaching, sessies en rate limiting
- Reden: Read-through caches verminderen de databasebelasting voor productpagina’s, met TTL’s die zijn afgestemd op de updatefrequentie. Sessiegegevens worden efemeer bewaard in Redis met korte TTL’s; de applicatiestatus blijft in Cloud SQL. Een fixed-window tokenstrategie gebruikt INCR/EXPIRE voor request-limieten per gebruiker. De cache wordt behandeld als niet-gezaghebbend; de app tolereert cacheverlies en vult deze opnieuw aan bij misses.
Bereid een gefaseerd pad voor naar Cloud Bigtable voor catalogusfuncties met hoge doorvoer
- Reden: Naarmate het verkeer groeit, worden gedenormaliseerde, voor lezen geoptimaliseerde catalogusweergaven verplaatst naar Bigtable. Rijsleutels worden ontworpen als bucket#category#reverse_ts om schrijfacties te distribueren en op tijd geordende lijsten te ondersteunen zonder hotspotting.
Stel procedures voor schemamigratie en rollback vast
- Reden: Migraties zijn additief: voeg kolommen/indexen toe, voer een backfill uit met idempotente jobs, deploy code die beide versies leest/schrijft, en verwijder later de oude velden. Feature flags bewaken nieuwe paden; een rollback schakelt schrijfacties naar nieuwe velden uit zonder destructieve DDL.
Stel beleid voor datalevenscyclus en -bescherming in
- Reden: Cloud Storage-buckets gebruiken lifecycle-regels om thumbnails over te zetten naar koudere opslag en verouderde tijdelijke uploads te verwijderen. Cloud SQL-back-ups en Spanner/Bigtable-back-ups (naarmate deze worden ingevoerd) worden regelmatig hersteld voor verificatie. Auditlogs leggen verwijderingsworkflows vast; Bigtable GC wordt in compliancedocumenten erkend als asynchroon.
Implementeer client- en server-retries met truncated exponential backoff
- Reden: Cloud Storage kan tijdens pieken 429/5xx retourneren; backoff vlakt de belasting af en vermindert het aantal fouten. Database- en cache-operaties gebruiken idempotency keys om veilige retries te garanderen, met name tijdens een failover en bij netwerkproblemen.

Dit plan levert onmiddellijke risicovermindering via Cloud SQL met privéconnectiviteit en HA, houdt de app responsief en kostenefficiënt met caching en uploads via signed URL’s, en bouwt een duidelijk pad om de leesdoorvoer en dataresilience te schalen naarmate het verkeer groeit.

← API-ontwerp · Alle domeinen · Identiteit →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →