Exam Professional Cloud Database Engineer topic 1 question 57 discussion

D. A SQL database architecture rules out Bigtable. Minimizing costs rules out Oracle RAC. That leaves B and D. B would work with each Cloud SQL instance being dedicated to a few stores which would not impact other Cloud SQL instances already running. The downside is the scaling up/down. To change the vCPU on a Cloud SQL instance requires it to be re-started and that’s disruption. Spanner also doesn’t autoscale by itself, but there’s a tool available for Spanner called Autoscaler which can automate scaling up/down. So on balance, D is the best answer. https://cloud.google.com/spanner/docs/autoscaling-overview

CloudSQL auto scale up/down causes disruption. in case of cloudspanner it is automatic. Plus Global solution by spanner is big plus. but again technical downside of multi regional spanner is, only one region will be a leader, because of which app from non-leader region may observe bit higher write latency.

To me, it is "B" here. A couple of reasons; the statement "minimizes costs and user disruption during each regional rollout" explicitly emphasises that the disruption relates to the rollout not the scale-up or scale-down, and considering it's only a few stores per db, I would presume it would take like a few minutes tops. Lastly, the cost is a bit of a give away as well since Cloud SQL is like twice as cheap (I did some rough estimates recently using europe-west2 as my benchmark).

The correct answer is ==> B. Use sharded Cloud SQL instances with one or more stores per database instance.

B Guys, either B or D. The keyword is :Minimize cost" Although D is the best solution, B is less costly

1. CloudSQL max out at 64TB, so unable to told 100TB of data. https://cloud.google.com/sql/docs/quotas#metrics_collection_limit 2. Scale is done manually on SQL Cloud.

CloudSQL max out at 64TB, so unable to told 200 * 500 GB of data. A: No. Oracle RAC cannot scale up or down B: No. Cloud SQL cannot scale up or down manually and the sharded Cloud SQL sound weird, and doesn't meet the "minimize costs and user disruption during each REGIONAL rollout". Also can't break storage limits 64TB. C: No. BigTable handles rational db poorly https://cloud.google.com/sql/docs/quotas#:~:text=Cloud%20SQL%20storage%20limits,core%3A%20Up%20to%203%20TB.

CloudSQL max out at 64TB, so unable to told 200 * 500 GB of data. D: choose Spanner

A - No- oracle RAC cannot scale up or down C- No, Big Table is for nonSQL B or D B - Cloud SQL cannot scale up or down manually and the sharded Cloud SQL sound weird, and doesn't meet the "minimize costs and user disruption during each REGIONAL rollout" For my, D is the best option as it

Cloud SQL sharding looks like a good option since we need to minimize costs and we don't need global scaling https://cloud.google.com/community/tutorials/horizontally-scale-mysql-database-backend-with-google-cloud-sql-and-proxysql

B: Use sharded ***** Cloud SQL instances with one or more stores per database instance. Sharding makes horizontal scaling possible by partitioning the database into smaller, more manageable parts (shards), then deploying the parts across a cluster of machines. Data queries are routed to the corresponding server automatically, usually with rules embedded in application logic or a query router.