Managed vs unmanaged e modello dei dati

Il primo criterio di scelta è il livello di gestione. Con un servizio fully managed (Cloud SQL, AlloyDB, Spanner, Bigtable, Firestore, Memorystore) Google gestisce patching, backup, replica e HA; con un approccio unmanaged si installa il database su Compute Engine, ottenendo controllo totale ma anche tutta la responsabilità operativa. Il caso limite è Bare Metal Solution: hardware dedicato adiacente a Google Cloud per workload Oracle che richiedono licenze e feature non replicabili sui servizi managed.

Il secondo criterio è la forma dei dati. Dati strutturati con schema fisso e relazioni forti vanno su database relazionali; dati semi-strutturati a documento (JSON annidato) su Firestore; dati sparsi wide-column ad alta velocità su Bigtable; dati non strutturati (immagini, video) in Cloud Storage con i metadati in un DB. I vector embedding per la gen AI hanno un discorso a parte (vedi sotto).

I relazionali: Cloud SQL, AlloyDB, Spanner

Cloud SQL è il managed per MySQL, PostgreSQL e SQL Server. È REGIONALE: l’HA si ottiene con una standby replica in un’altra zona della stessa region e failover automatico; le read replica (anche cross-region) scalano solo le letture e non promuovono automaticamente lo scrittore. Il PITR si basa su binary log/WAL. È la scelta di default per un’app OLTP tradizionale in lift-and-shift.

AlloyDB è PostgreSQL-compatibile, con un engine colonnare in-memory che accelera l’analitica (HTAP) e read pool per lo scale-out di lettura. Da scegliere quando serve PostgreSQL ma con throughput e query analitiche superiori a Cloud SQL, restando comunque regionale.

Spanner è relazionale ma GLOBALMENTE distribuito, con scala orizzontale e strong/external consistency; la config multi-region offre SLA fino al 99,999%. È la risposta quando i requisiti sono scala globale e consistenza forte insieme, non un semplice upgrade di Cloud SQL.

NoSQL, cache e analitica

Bigtable è NoSQL wide-column, latenza in singoli millisecondi e throughput enorme; espone la HBase API. NON è relazionale e non fa join SQL: ideale per time-series, IoT, dati AdTech/finanziari ad altissima frequenza di scrittura.

Firestore è documentale, con sincronizzazione real-time verso client mobile/web e scaling automatico; perfetto per app collaborative e profili utente.

Memorystore (Redis/Memcached) è una CACHE in-memory: velocissima ma NON durevole come sistema primario. Si mette davanti a un database per session store, leaderboard e caching, mai come unica fonte di verità.

BigQuery è il data warehouse analitico serverless per OLAP e reporting su grandi volumi, non un motore OLTP.

Costi e casi d’uso gen AI/vector

Sul piano costi contano i modelli di pricing: Cloud SQL/AlloyDB si pagano per istanza/vCPU e storage; Spanner per nodi/processing unit; Bigtable per nodi e storage; Firestore e BigQuery hanno componenti a consumo (operazioni o dati scansionati). Sovradimensionare Spanner per un carico regionale è un tipico errore di costo.

Per la gen AI e la ricerca semantica servono i vector embedding: si abilitano con pgvector su AlloyDB (AlloyDB AI) e Cloud SQL for PostgreSQL, oppure con il supporto vector di Spanner e di BigQuery. Regola pratica: se hai già dati relazionali PostgreSQL, aggiungere pgvector evita di introdurre un database vettoriale separato.

Trappole tipiche d’esame

  • Scala globale + strong consistency → Spanner: Cloud SQL è regionale; se lo scenario cita utenti su più continenti con consistenza forte e scala orizzontale, la risposta è Spanner, non una read replica cross-region di Cloud SQL.
  • HA vs read replica → distinguerle: una read replica scala le letture ma NON è failover automatico dello scrittore; l’HA di Cloud SQL richiede la standby con failover.
  • “NoSQL a bassa latenza con join SQL” → trabocchetto: Bigtable non fa join né query SQL; se lo scenario pretende join relazionali, non è Bigtable.
  • Cache scambiata per DB primario → Memorystore: non è durevole; usarlo come unica fonte di verità è la risposta da scartare.
  • Oracle da migrare → Bare Metal Solution o DMS eterogeneo: per mantenere Oracle si usa Bare Metal Solution; per migrare Oracle→PostgreSQL con CDC continuo si usa Database Migration Service.
  • Vector per gen AI → pgvector sui dati esistenti: con dati già in PostgreSQL (Cloud SQL/AlloyDB) abilitare pgvector è preferibile a introdurre un nuovo store vettoriale.