Google PCD: Dati delle applicazioni, stato e pattern di storage — Guida allo studio

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

Fa parte della Google Professional Cloud Developer — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Archivi operativi NoSQL: Firestore e Bigtable

Scegliere il modello NoSQL che corrisponde ai pattern di query e al profilo di throughput.

Firestore (documentale)
- Modello dei dati: le collezioni contengono documenti; i documenti possono avere sottocollezioni. Modellare in base ai pattern di query; evitare scritture con “fan-out” profondo su singoli documenti “caldi” (hot).
- Accesso e transazioni: le letture e le query sui documenti sono “strongly consistent” in modalità Nativa. Usare scritture batch per un’atomicità “at-most-once” su più documenti e transazioni per operazioni di lettura-modifica-scrittura con controlli sulla contesa.
- Indici: gli indici su campo singolo sono automatici. Gli indici composti su più campi devono essere definiti quando si usano filtri multipli di intervallo/disuguaglianza o ordinamenti. La denormalizzazione è comune per rendere le query “index-only” (basate solo su indici).
- Sincronizzazione dei client: i listener in tempo reale trasmettono le modifiche in streaming; le cache offline si riconciliano con una semantica “last-write-wins”. Proteggersi da un “fan-out” illimitato dei listener; preferire cursori di query e filtri.
- Limiti e modalità di fallimento: la velocità di scrittura su un singolo documento è serializzata; aggiornamenti sostenuti ad alto QPS su un unico documento creano contesa. Usare contatori partizionati (sharded counters) con N sottodocumenti e aggregare in fase di lettura.
Cloud Bigtable (a colonne larghe)
- La progettazione della chiave di riga (row-key) è fondamentale. Bigtable partiziona le righe lessicograficamente; i segmenti iniziali della chiave determinano l’hotspotting. Evitare chiavi sequenziali come timestamp all’inizio o ID utente non partizionati.
- Pattern:
  - Timestamp inverso all’interno della chiave per letture di serie temporali: key = device#hash(device_id)#reverse_ts.
  - Usare un hash o un bucket per il primo componente per distribuire le scritture: bucket = crc32(user_id) % 128.
- Archiviare celle piccole con molte colonne; evitare righe grandi che si estendono su più tablet. Sfruttare più famiglie di colonne per il controllo degli accessi e la separazione delle policy di Garbage Collection (GC).
- Throughput ed erogazione:
  - Usare più cluster per la replica e la prossimità di lettura regionale; le scritture tra cluster diventano “eventually consistent”.
  - Ottimizzare i profili dell’applicazione e il routing; mantenere pool di thread e pool di canali generosi lato client.
- GC e TTL: la Garbage Collection basata su versione e tempo rimuove le vecchie celle in modo asincrono; i dati persistono fino alla compattazione, quindi non fare affidamento sulla cancellazione immediata per scadenze normative.

Pattern di Caching e Object Storage

Memorystore (Redis/Memcached)
- Strategie di caching:
  - Read-through: l’applicazione recupera i dati dalla cache; in caso di miss, li carica dalla sorgente e popola la cache.
  - Write-through: le scritture avvengono in modo sincrono sia sulla cache che sulla sorgente.
  - Write-behind: le scritture vengono bufferizzate nella cache e scaricate (flush) in modo asincrono; usare con cautela a causa del rischio di perdita di dati.
- Scadenza e invalidazione:
  - Applicare TTL coerenti con la tolleranza all’obsolescenza dei dati. Invalidare le chiavi al variare della fonte di verità (source-of-truth); per le cache aggregate, usare chiavi versionate per evitare “stampede”.
  - Usare un mutex o un pattern “single-flight” per prevenire i “cache stampede” su chiavi popolari.
- Sessioni: archiviare dati di sessione effimeri con un TTL; crittografare i valori o archiviare solo token opachi se i dati sono sensibili.
- Rate limiting con Redis:
  - Finestra fissa (Fixed-window): INCR con EXPIRE su una chiave per identità.
  - Finestra scorrevole (Sliding-window) o “token-bucket” per limiti più fluidi; considerare script Lua per l’atomicità.
- Disponibilità: il livello Basic non ha failover; il livello Standard fornisce alta disponibilità (HA) a livello regionale. Trattare la cache come volatile; mai come archivio autorevole.
Esempio: rate limit semplice a finestra fissa
- Comandi:
  - INCR rate:login:USER123:20260903T1000
  - EXPIRE rate:login:USER123:20260903T1000 60
Cloud Storage
- Oggetti e coerenza: coerenza forte e globale (strong global consistency) per letture, scritture, sovrascritture, cancellazioni ed elenchi. Gli oggetti sono immutabili; gli aggiornamenti creano nuove generazioni.
- URL firmati (Signed URLs): delegare upload/download di grandi dimensioni direttamente tra i client e i bucket senza passare attraverso la propria applicazione. Impostare scadenze brevi; limitare metodo, percorso e header di contenuto.
- Upload ripristinabili (Resumable uploads): usare per file >5 MB e reti inaffidabili; gestire errori 5xx/429 con “truncated exponential backoff” e token di ripristino.
- Ciclo di vita (Lifecycle): definire regole per passare a diverse classi di archiviazione, eliminare vecchie versioni e applicare la conservazione (retention). Combinare con il versioning degli oggetti per maggiore sicurezza durante i rollout.
- Notifiche: integrare le notifiche di Pub/Sub per avviare elaborazioni a valle al momento della finalizzazione/cancellazione di un oggetto e includere precondizioni (ifGenerationMatch) per proteggersi da race condition.
Esempio: caricare file locali
- gsutil cp ./data/*.parquet gs://my-bucket/ingest/

Migrazione, Coerenza, Partizionamento e Protezione dei Dati

Migrazione del database
- Scegliere tra online e offline: online con Database Migration Service per tempi di inattività minimi; offline per semplicità quando le finestre di manutenzione sono accettabili.
- Approccio schema-first: riconciliare tipi e vincoli; per Spanner, considerare strumenti per mappare schemi e dati MySQL/PostgreSQL, quindi ottimizzare chiavi e indici per la distribuzione.
- Dual-run e cutover: durante la migrazione online, eseguire dual-write o replicare i changelog. Convalidare il conteggio delle righe, i checksum e il comportamento delle query critiche prima del cutover finale.
Migrazioni dello schema e rollback
- Utilizzare migrazioni automatizzate e versionate (ad esempio, con uno strumento di migrazione) come parte della CI/CD. Progettare modifiche additive e retrocompatibili: aggiungere colonne e indici, eseguire il backfill, distribuire codice che legge/scrive su entrambi, quindi rimuovere gli artefatti deprecati.
- Pianificare il rollback con trasformazioni dei dati: se il deploy del codice fallisce, essere pronti a disabilitare le nuove scritture e fare affidamento sui feature flag; evitare migrazioni distruttive che bloccano il rollback.
Workflow transazionali e a consistenza finale
- Utilizzare transazioni ACID quando gli invarianti devono essere mantenuti in modo sincrono (trasferimenti di fondi, decrementi di inventario).
- Preferire la consistenza finale per funzionalità prevalentemente in lettura e rivolte all’utente in cui la latenza è dominante (feed, ricerca, contatori). Implementare chiavi di idempotenza, pattern outbox/Saga e nuovi tentativi con backoff.
- Combinare: eseguire il commit dello stato autoritativo in uno store transazionale; pubblicare eventi per proiezioni a consistenza finale.
Partizionamento dei dati e gestione delle connessioni
- Partizionare per tenant, area geografica o tipo di carico di lavoro per isolare gli hotspot. Per Bigtable e Spanner, codificare le chiavi di partizione nelle chiavi primarie; per Cloud SQL, utilizzare lo sharding a livello di schema per tenant (schema-per-tenant) o di tabella con router.
- Gestire le connessioni:
  - Cloud SQL: usare il pooling e riutilizzare le connessioni; limitare la concorrenza; scaglionare i cold start.
  - Spanner: riutilizzare le sessioni; riscaldare i pool all’avvio; limitare i nuovi tentativi.
  - Memorystore: riutilizzare le connessioni TCP; evitare connessioni per ogni richiesta.
Protezione dei dati, archiviazione, verifica del ripristino e comportamento di eliminazione
- Backup e archiviazione:
  - Cloud SQL: backup automatici + PITR; testare i ripristini.
  - Spanner: backup gestiti; testare il ripristino in un ambiente non di produzione.
  - Firestore: esportazioni pianificate su Cloud Storage; verificare le importazioni.
  - Bigtable: backup e snapshot; testare la clonazione e il ripristino.
  - Cloud Storage: policy di conservazione, blocchi degli oggetti e accesso uniforme a livello di bucket per la governance; archiviare in classi di archiviazione più fredde tramite il ciclo di vita.
- Verifica del ripristino: ripristinare periodicamente in ambienti isolati ed eseguire query di convalida e smoke test dell’applicazione. Monitorare RTO/RPO rispetto alle policy.
- Comportamento di eliminazione:
  - La Garbage Collection (GC) e il ciclo di vita di Bigtable sono asincroni: non garantire la cancellazione immediata.
  - Il versioning di Cloud Storage conserva le generazioni finché il ciclo di vita non le rimuove.
  - Il TTL di Firestore e le eliminazioni basate su esportazione sono asincroni.
  - Per SLA di eliminazione definitiva (hard-deletion), progettare processi che marcano per l’eliminazione, accodano e verificano la rimozione, con log di audit.

Scenario Pratico

Aurora Outfitters sta migrando una piattaforma di e-commerce monolitica su Google Cloud. Devono: 1) eseguire un lift-and-shift di MySQL per ridurre i rischi, 2) gestire l’upload di file multimediali dei prodotti da 500 MB senza sovraccaricare l’app, 3) scalare il throughput in lettura per i cataloghi dei prodotti e 4) applicare rate limit per utente durante i picchi di vendite.

Approccio:

Migrare MySQL su Cloud SQL con IP privato e alta disponibilità (HA) a livello regionale
- Motivazione: l’IP privato elimina l’esposizione pubblica e le allowlist di IP, semplificando la connettività sicura da GKE e Compute Engine. L’HA regionale protegge dai guasti a livello di zona; sono previste brevi interruzioni della connessione durante il failover, quindi l’app implementerà transazioni ritentabili e logica di riconnessione.
Abilitare backup automatici e PITR, e convalidare il ripristino
- Motivazione: i backup automatici e i log delle transazioni consentono il point-in-time recovery da errori dell’utente o dell’applicazione. Un ripristino pianificato settimanale su un’istanza non di produzione verifica che i backup siano utilizzabili e misura l’RTO.
Aggiungere una replica di lettura per le letture del catalogo
- Motivazione: spostare le query del catalogo su una replica di lettura riduce la contesa sull’istanza primaria. L’app legge dal primario quando è necessario il write-after-read (carrello/checkout) e dalla replica per la navigazione del catalogo, tenendo conto dei compromessi legati al ritardo della replica (replica lag).
Introdurre il connection pooling lato applicazione e limitare la concorrenza
- Motivazione: PgBouncer/HikariCP limita e riutilizza le connessioni, evitando tempeste di connessioni durante l’autoscaling e i failover dell’HA. I pool sono dimensionati in base ai core della CPU, non al numero massimo di pod, per prevenire il sovraccarico.
Delegare l’upload dei file multimediali a Cloud Storage con URL firmati e upload ripristinabili
- Motivazione: l’app emette URL firmati di breve durata affinché i client possano eseguire l’upload direttamente. Gli upload ripristinabili gestiscono le reti inaffidabili; il servizio media ascolta le notifiche di finalizzazione di Pub/Sub per avviare l’elaborazione. Gli header di precondizione (ifGenerationMatch) proteggono dalle race condition in sovrascrittura.
Implementare Memorystore for Redis per il caching delle pagine, le sessioni e il rate limiting
- Motivazione: le cache read-through riducono il carico sul database per le pagine dei prodotti, con TTL allineati alla frequenza di aggiornamento. I dati di sessione sono mantenuti effimeri in Redis con TTL brevi; lo stato dell’applicazione rimane in Cloud SQL. Una strategia a token con finestra fissa utilizza INCR/EXPIRE per i limiti di richieste per utente. La cache è trattata come non autoritativa; l’app tollera la perdita della cache e la ripopola in caso di cache miss.
Preparare un percorso graduale verso Cloud Bigtable per le funzionalità di navigazione del catalogo ad alto throughput
- Motivazione: con la crescita del traffico, le viste del catalogo denormalizzate e ottimizzate per la lettura vengono spostate su Bigtable. Le chiavi di riga (row key) sono progettate come bucket#category#reverse_ts per distribuire le scritture e supportare elenchi ordinati nel tempo senza creare hotspot.
Stabilire procedure di migrazione dello schema e di rollback
- Motivazione: le migrazioni sono additive: aggiungere colonne/indici, eseguire il backfill con job idempotenti, distribuire codice che legge/scrive su entrambi, quindi rimuovere i vecchi campi in un secondo momento. I feature flag proteggono i nuovi percorsi; il rollback disabilita le scritture sui nuovi campi senza DDL distruttivo.
Impostare policy di ciclo di vita e protezione dei dati
- Motivazione: i bucket di Cloud Storage utilizzano regole del ciclo di vita per spostare le anteprime in classi di archiviazione più fredde e per eliminare gli upload temporanei obsoleti. I backup di Cloud SQL e quelli di Spanner/Bigtable (man mano che vengono adottati) sono ripristinati regolarmente per verifica. I log di audit catturano i flussi di lavoro di eliminazione; la GC di Bigtable è riconosciuta come asincrona nei documenti di conformità.
Implementare nuovi tentativi lato client e server con backoff esponenziale troncato
- Motivazione: Cloud Storage può restituire errori 429/5xx durante i picchi di traffico; il backoff distribuisce il carico e riduce il tasso di errore. Le operazioni su database e cache utilizzano chiavi di idempotenza per garantire la sicurezza dei nuovi tentativi, in particolare durante failover e brevi interruzioni di rete.

Questo piano offre una riduzione immediata del rischio tramite Cloud SQL con connettività privata e HA, mantiene l’app reattiva ed efficiente in termini di costi con il caching e gli upload tramite URL firmati, e costruisce un percorso chiaro per scalare il throughput in lettura e la resilienza dei dati con la crescita del traffico.

← Progettazione di API · Tutti i domini · Identità →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →