← PDE·Google Cloud

PDE Storing the Data Practice Question

A logistics company writes shipment telemetry to a Cloud Bigtable table using a row key of shipment_id, where shipment_id values are monotonically increasing and roughly sequential over time. Write throughput has become uneven, with a small number of tablet servers overloaded while others sit idle. The engineer must improve write distribution without changing the schema of the column families. What should the engineer do?

⚠ Common exam trap

The trap here is assuming Bigtable's automatic tablet rebalancing will fix a hotspot, when rebalancing cannot compensate for a row key that always targets the same key range.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Prepend a hashed or reversed component to the row key so writes spread across the key space instead of concentrating at the high end.

Bigtable distributes rows by row key ranges, so a monotonically increasing key sends every new write to the tablet owning the highest range, overloading one node while others idle. Adding a hash bucket prefix or reversing the key scatters writes across many ranges and tablets, restoring even load without altering column families. Automatic rebalancing, extra column families, and replication clusters all leave the underlying key concentration in place, so the hotspot persists.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Create a Cloud Bigtable replication cluster in a second zone and write half the traffic to each cluster.
Why it's wrong here
Replication improves availability and read locality, and writes to either cluster are eventually replicated, but each cluster independently applies the same row key ordering. The hotspot behavior follows the key, so both clusters would still concentrate sequential writes on their highest-range tablet. Replication does not solve uneven write distribution caused by key design.
✗
Increase the number of column families in the table to spread the write load across more storage structures.
Why it's wrong here
Column families are logical groupings of columns, not distribution units. Adding column families does not change how rows are assigned to tablets, which is determined by the row key. The hotspot is a key-range problem, so adding column families leaves the sequential key concentration untouched and may even increase storage overhead.
✗
Enable automatic region rebalancing so Bigtable redistributes the hot rows across the cluster.
Why it's wrong here
Bigtable already automatically splits and rebalances tablets, but it cannot fix a key design that concentrates all new writes on the single tablet owning the highest sequential key range. Rebalancing moves existing tablets between nodes; it does not spread a monotonically increasing key stream. The hotspot would persist because the newest keys always land on one tablet until it splits.
✓
Prepend a hashed or reversed component to the row key so writes spread across the key space instead of concentrating at the high end.
Why this is correct
Sequential, monotonically increasing keys concentrate writes on the tablet holding the highest key range, creating a hotspot. Prepending a hash bucket or reversing the key distributes incoming writes across many tablets, letting all tablet servers share load. This preserves the column family schema and keeps keys unique, which is the standard fix for write hotspots caused by sequential row keys.

Go deeper

PDE Storing the Data Practice Question

Why each option matters

Option-by-option breakdown

Related to this question