Question

Difficulty: Very hardManaging Storage and Database Solutions

An enterprise IoT telemetry system writes high-frequency streaming data into a single-cluster Cloud Bigtable instance configured with SSD storage. During scheduled analytical batch operations, heavy read queries degrade cluster write performance, leading to high write latencies and timeout errors for incoming telemetry streams. Operational requirements dictate isolating the analytical read workload from the real-time write workload while maintaining seamless workload routing without exporting data out of Cloud Bigtable or changing the application's underlying database model. Which action should you take?

  1. Add a second cluster to the Cloud Bigtable instance, then configure separate App Profiles with single-cluster routing so that the real-time ingestion traffic routes to the primary cluster and the analytical queries route to the secondary cluster.Answer
  2. B
    Configure an automated daily export pipeline using Cloud Dataflow to transfer telemetry data from Cloud Bigtable into a Cloud SQL for PostgreSQL instance, and re-point the analytical queries to run against Cloud SQL.
  3. C
    Modify the Cloud Bigtable table storage class settings from SSD to Archive storage using lifecycle policies to reduce read latency penalties on analytical batch queries.
  4. D
    Provision a pool of Spot Compute Engine instances with public IP endpoints to handle and cache analytical reads directly from Bigtable nodes.

Answer

Add a second cluster to the Cloud Bigtable instance, then configure separate App Profiles with single-cluster routing so that the real-time ingestion traffic routes to the primary cluster and the analytical queries route to the secondary cluster.
The correct option addresses query contention at the database architecture level by adding a second cluster to the existing Cloud Bigtable instance. By configuring separate App Profiles with single-cluster routing, real-time ingestion is pinned to the primary cluster while analytical batch queries target the replicated secondary cluster, ensuring workload isolation and high write availability without exporting data out of Bigtable.

Step-by-Step Solution

1
Analyze workload isolation requirements in Cloud Bigtable.
Identified resource contention between streaming real-time writes and batch analytical reads on a single cluster.
Cloud Bigtable cluster nodes handle both read and write requests; heavy reads starve CPU resources needed for real-time writes.
2
Evaluate Cloud Bigtable multi-cluster replication and App Profile routing capabilities.
Determined that multi-cluster replication synchronizes data between clusters within the same instance.
Adding a second cluster enables workload separation via application-level isolation.
3
Configure dedicated App Profiles for isolated workload routing.
Assigned streaming ingestion clients to an App Profile targeting Cluster 1 and analytical batch queries to an App Profile targeting Cluster 2.
Single-cluster routing per App Profile ensures query isolation while Cloud Bigtable handles eventual consistency and data synchronization asynchronously across clusters.

Key Concept

Cloud Bigtable Multi-Cluster Workload Isolation and App Profiles
Estimated Time:3m 0s
Rate this question