Cloud Storage: bucket, storage class e lifecycle

Cloud Storage è l’object storage di GCP: i dati sono oggetti dentro bucket, ciascuno con un nome globalmente unico e una location (region, dual-region o multi-region). Non è un filesystem: non esiste una gerarchia reale, solo prefissi che simulano cartelle.

La scelta della storage class dipende dalla frequenza di accesso:

  • Standard: dati “hot”, accesso frequente, nessuna minimum storage duration.
  • Nearline: accesso circa una volta al mese, durata minima 30 giorni.
  • Coldline: accesso circa una volta a trimestre, durata minima 90 giorni.
  • Archive: archiviazione a lungo termine, accesso circa una volta l’anno, durata minima 365 giorni.

Le classi più fredde costano meno in storage ma più in retrieval e impongono una minimum storage duration: cancellare o spostare un oggetto prima della scadenza genera comunque addebito. Le lifecycle policy (regole in JSON su età dell’oggetto, numero di versioni, ecc.) automatizzano la transizione tra classi o la cancellazione. Con la CLI unificata usi gcloud storage buckets create, gcloud storage cp, gcloud storage rsync e gcloud storage buckets update per abilitare l’object versioning. Per i permessi preferisci i predefined role come roles/storage.objectViewer o roles/storage.objectAdmin invece del basic role editor, che concede troppo.

Il database relazionale: Cloud SQL vs Spanner

Cloud SQL è il managed database per MySQL, PostgreSQL e SQL Server. È regionale: l’istanza vive in una region, con HA opzionale (standby in un’altra zona della stessa region e failover automatico). Le read replica scalano le letture. È la scelta default per un database relazionale tradizionale (fino a decine di TB) senza esigenze di scala globale.

Cloud Spanner è relazionale ma distribuito orizzontalmente, con consistenza forte (external consistency), transazioni ACID e scalabilità praticamente illimitata. Configurazione regional o multi-region (SLA fino a 99,999%). Si sceglie quando servono scala globale, throughput elevatissimo e semantica relazionale insieme: ha un costo base alto, quindi è overkill per carichi piccoli.

NoSQL, documenti e caching

Firestore è un database documentale serverless che scala automaticamente, ideale per app web/mobile con schema flessibile e sincronizzazione real-time. Non richiede provisioning di capacità.

Bigtable è NoSQL wide-column ad altissimo throughput e latenza single-digit millisecond, pensato per volumi grandi (fino a petabyte): time-series, IoT, dati finanziari, workload analitici e operazionali. È compatibile con l’API HBase. Non è adatto a dataset piccoli né a query relazionali o ad-hoc.

Memorystore è la cache in-memory gestita, con engine Redis o Memcached. Si mette davanti a un database per ridurre latenza e carico sulle letture ripetute, oppure per gestire sessioni; non è un archivio durevole primario.

Trasferimento dati

Per portare dati verso Cloud Storage usa Storage Transfer Service (da on-prem, da bucket S3 o altri cloud, oppure bucket-to-bucket, con schedulazione). Per volumi enormi in modalità offline esiste Transfer Appliance. Per sincronizzazioni semplici tra sorgente e bucket basta gcloud storage rsync.

Trappole tipiche d’esame

  • Accesso circa una volta l’anno, minimizzare il costo di storage → Archive: è la classe più economica in storage; il retrieval costa di più, ma è coerente con accessi rarissimi.
  • Backup a cui si accede di rado ma che deve restare disponibile subito → Nearline/Coldline, non Archive: guardi la durata minima e la frequenza d’accesso, non solo il prezzo per GB.
  • Database relazionale con scala globale e consistenza forte → Cloud Spanner, non Cloud SQL: Cloud SQL è regionale; per lo scale-out globale ACID serve Spanner.
  • Relazionale regionale con alta disponibilità → Cloud SQL in configurazione HA (standby multi-zona), non read replica: la read replica scala le letture, non fornisce failover automatico.
  • Time-series o IoT ad alto throughput → Bigtable, non Firestore: Firestore è documentale per app; il throughput massiccio wide-column è Bigtable.
  • Ridurre latenza su letture ripetute → Memorystore (cache), non aggiungere read replica: la cache in-memory è la risposta al pattern “read caching”, non un’altra replica del DB.