Il criterio di fondo: operazionale o analitico?

La prima domanda da farsi non è “quale database mi piace”, ma che tipo di carico serve. I workload operazionali (OLTP) fanno molte letture/scritture puntuali a bassa latenza, per singola entità o piccola chiave: sono le applicazioni che servono utenti in tempo reale. I workload analitici (OLAP) scansionano grandi volumi per aggregare, e su Google Cloud il posto giusto è BigQuery, non un database transazionale. Confondere i due piani è l’errore classico: usare BigQuery come backend OLTP di un’app, o forzare aggregazioni pesanti su un database operazionale, porta a costi e latenze sbagliati. Fissato l’asse operazionale/analitico, si sceglie in base a modello dati, scala e ambito geografico.

NoSQL ad alta scala: Bigtable e Firestore

Cloud Bigtable è un NoSQL wide-column ad altissimo throughput e latenza in single-digit millisecondi, pensato per volumi enormi: time-series, telemetria IoT, dati finanziari, metriche. Non offre join SQL né transazioni multi-riga complesse: si interroga per row key o per range di chiavi. Proprio il row key design è il cuore dell’esame. Una chiave monotòna crescente (timestamp in testa, ID sequenziale) concentra le scritture su un unico nodo e crea hotspotting, sprecando la scala orizzontale. Le tecniche corrette: anteporre un campo ad alta cardinalità, usare field promotion/salting, invertire componenti, e per le time-series mettere il timestamp dopo l’identificatore dell’entità. Scala aggiungendo nodi; supporta la replica multi-region per alta disponibilità.

Firestore è un database documentale serverless, ideale per app mobile/web: sincronizzazione offline, listener real-time, scaling automatico. Ottimo per profili utente, cataloghi, stato applicativo con schema flessibile; non è la scelta per analitica pesante né per join relazionali complessi.

Relazionale: Cloud SQL, Spanner, AlloyDB, Memorystore

Cloud SQL è il relazionale gestito (MySQL, PostgreSQL, SQL Server) di ambito regionale. È la scelta di default quando serve SQL classico con transazioni ACID, schema relazionale e dimensioni gestibili da una singola istanza (scaling verticale, read replica per le letture). Regge la maggior parte delle applicazioni, ma ha un tetto di scala e non è nativamente globale.

Cloud Spanner è il relazionale distribuito e globale: unisce SQL e consistenza forte a scala orizzontale, con alta disponibilità fino a più region. Si sceglie quando servono contemporaneamente SQL relazionale + scala oltre la singola macchina + distribuzione multi-region (es. sistemi finanziari o inventari globali). Ha un costo di ingresso più alto: non è la risposta a un’app regionale modesta.

AlloyDB è PostgreSQL-compatibile ad alte prestazioni, con un motore colonnare che accelera anche query analitiche sui dati transazionali: da valutare quando Cloud SQL PostgreSQL non basta in performance ma non serve la distribuzione globale di Spanner. Memorystore (Redis/Memcached gestito) non è un database primario ma una cache in-memory per abbattere la latenza e alleggerire il backend.

Cloud Storage: il data lake

Cloud Storage è object storage per dati non strutturati (file, log grezzi, immagini, backup, export) ed è il data lake naturale da cui alimentare BigQuery, Dataflow o Dataproc. La leva di costo sono le storage class: Standard per accesso frequente, Nearline/Coldline/Archive per dati sempre più freddi, con Object Lifecycle Management per la transizione automatica. Non è un database interrogabile a bassa latenza per singola riga: è persistenza economica e durevole.

Trappole tipiche d’esame

  • Time-series/IoT ad altissimo throughput → Cloud Bigtable: wide-column, no join SQL; se lo scenario chiede aggregazioni SQL complesse su tutto lo storico, il candidato giusto è BigQuery, non Bigtable.
  • Scritture concentrate su una chiave crescente → hotspotting: distribuisci il row key (field promotion, salting, timestamp non in testa); non aggiungere nodi sperando che risolva da solo.
  • Relazionale con distribuzione globale e scala orizzontale → Cloud Spanner: Cloud SQL è regionale e a scaling verticale; scegliere Cloud SQL “perché è SQL” quando lo scenario dice global e scala oltre una macchina è la trappola.
  • App mobile con sync offline e real-time → Firestore: non Bigtable (niente listener/documenti) né Cloud SQL.
  • Dati grezzi da conservare a basso costo → Cloud Storage + storage class/lifecycle: non caricarli in un database transazionale “per comodità”.
  • Latenza da abbattere su letture ripetute → Memorystore come cache: è cache, non lo store di verità; il dato persistente resta nel database primario.