← PDE·Google Cloud

PDE Storing the Data Practice Question

A data engineer is designing a Cloud Bigtable schema for high-volume time-series data. Which TWO practices should they follow to avoid performance issues?

⚠ Common exam trap

The trap is assuming that timestamp-first row keys are good for time-series data, but they cause hotspots; candidates may also overuse column families.

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

✓

Use a hashed prefix in the row key to distribute writes

Option C is correct because Cloud Bigtable sorts rows lexicographically by row key, so monotonically increasing keys (like raw timestamps) concentrate writes on a single tablet, creating a hotspot; adding a hashed prefix distributes writes across multiple tablets and improves throughput. Option D is correct because grouping related columns into a small number of column families keeps data that is accessed together physically co-located, which improves read efficiency and avoids excessive per-row overhead. Option A is incorrect because placing the timestamp first produces sequential, monotonically increasing keys that cause write hotspots rather than distributing load. Option B is incorrect because Bigtable recommends keeping the number of column families small (typically fewer than 10), since each family adds memory and compaction overhead. Option E is incorrect because cramming all columns into one family prevents efficient access patterns and mixes unrelated data, hurting read performance and locality.

Answer analysis

Option-by-option breakdown

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

✗
Place the timestamp as the first component of the row key
Why it's wrong here
Leading the row key with a timestamp sends sequential writes to one tablet, creating a hotspot. It tempts because time-ordered keys aid range scans, but Bigtable needs a high-cardinality prefix such as a reversed timestamp or hashed identifier to distribute load.
✗
Create as many column families as possible
Why it's wrong here
Each column family adds memory and compaction overhead, so creating many degrades performance. It tempts because families group related columns logically, but Bigtable recommends keeping the count small, typically fewer than about ten per table.
✓
Use a hashed prefix in the row key to distribute writes
Why this is correct
Hashing the row key prefix scatters sequential writes across many tablets instead of concentrating them on one, preventing hot-spotting. This satisfies the high-volume time-series constraint where monotonically increasing keys would otherwise bottleneck a single tablet.
✓
Group related columns into column families
Why this is correct
Grouping related columns into column families keeps each family's data stored together, reducing the number of families scanned per query and improving read efficiency. This satisfies the high-volume time-series constraint by limiting unnecessary data retrieval.
✗
Store all columns in a single column family
Why it's wrong here
Grouping every column into one family forces all data to be read and compacted together, wasting I/O. It tempts because it avoids family proliferation, but Bigtable expects columns with similar access and retention patterns to be separated into distinct families.

Go deeper

PDE Storing the Data Practice Question

Why each option matters

Option-by-option breakdown

Related to this question