What's changed: Created Professional Cloud Developer Chapter 2 (Domain 1 "Design" part 2: storing/accessing data = Cloud SQL/AlloyDB/Spanner/Firestore/Bigtable/Cloud Storage/BigQuery, schema/row-key, eventual/strong consistency, signed URLs, BigQuery writes; availability/resilience/cost = region/zone distribution and latency, zonal/regional failover, resource requirements, serverless scale-to-zero, idempotency/exponential backoff).
2.1Storing and accessing data
Understand choosing storage by data volume and performance/consistency requirements (AlloyDB, Spanner, Bigtable, Firestore, Cloud SQL, Cloud Storage, BigQuery), schema design for structured/unstructured data, eventual vs strong consistency, Cloud Storage signed URLs, and writing to BigQuery for analytics and AI/ML.
Data is the heart of an app. Developers choose the right store for the data shape, volume, consistency, and access patterns, and access it securely.
2.1.1Choosing storage and schema
For structured RDBs: typical business = Cloud SQL, high-performance PostgreSQL-compatible = AlloyDB, global strong consistency = Spanner. Semi-structured/documents = Firestore, huge-scale low-latency time series/IoT = Bigtable. Unstructured objects = Cloud Storage, large-scale analytics = BigQuery. For schema, RDBs need normalization/indexes; Bigtable needs row-key design (avoid hotspots). Map "global strong = Spanner," "huge-scale low-latency = Bigtable," "analytics = BigQuery."
2.1.2Consistency and access
Replication offers eventual consistency (fast but may briefly show stale values) and strong consistency (always latest but costlier)—choose by requirements (Spanner is strongly consistent; Bigtable is strongly consistent per single row, etc.). To grant temporary, limited access to Cloud Storage objects, issue a signed URL (time-limited sharing without making them public). For analytics/AI-ML, write data to BigQuery. Map "time-limited scoped access = signed URL" and "choose consistency by requirements."
Common: requirement → service. E.g., "global strongly consistent RDB" = Spanner; "huge-scale low-latency time series" = Bigtable (row-key design); "document type" = Firestore; "analytics" = BigQuery; "time-limited object access" = signed URL; "high-performance PostgreSQL-compatible" = AlloyDB.
Watch the mix-ups: (1) Do not confuse Spanner (strong RDB)/Bigtable (low-latency NoSQL)/BigQuery (analytics). (2) Signed URLs are time-limited, distinct from making a bucket public. (3) Eventual consistency may briefly show stale values—choose by requirements.
2.1.3Section summary
- Choose storage by data shape/volume/consistency (Cloud SQL/AlloyDB/Spanner/Firestore/Bigtable/Cloud Storage/BigQuery)
- Consistency = eventual/strong by requirements; Bigtable needs row-key design
- Time-limited object access = signed URLs; write to BigQuery for analytics/ML
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You need a globally distributed, strongly consistent relational DB. Which is best?
Q2. For huge-scale, low-latency time series/IoT data (row-key design matters), which is best?
Q3. To grant time-limited, scoped access to a Cloud Storage object without making it public, what do you use?
Q4. For scalable document data in mobile/web apps, which is best?
Q5. Which correctly contrasts eventual and strong consistency?
Q6. Where is it best to write data for analytics and AI/ML?