PDE Storing the Data Practice Question
A company is designing a Cloud Bigtable row key for a time-series dataset of device readings. They want to avoid hotspotting (uneven load across tablets). Which TWO row key design patterns are effective? (Choose 2)
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
✓
Reverse the timestamp string
Option C is correct because reversing the timestamp string (e.g., turning a lexicographically increasing timestamp into a decreasing one) prevents new writes from always landing on the last tablet, spreading sequential writes across the keyspace. Option D is correct because prepending a hash of the device ID to the timestamp distributes writes across many distinct key prefixes, so consecutive readings from different devices do not concentrate on a single tablet. Options A and B are incorrect because a monotonically increasing counter and a timestamp as the leading key component both produce sequential, ever-increasing keys that funnel all new writes to the last tablet, causing hotspotting. Option E is incorrect because a secondary index on the timestamp column is not a row key design pattern and Bigtable does not support secondary indexes natively; it would not address hotspotting.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use a monotonically increasing counter as row key
Why it's wrong here
A monotonically increasing counter sends every new write to the last tablet, concentrating load exactly as timestamps do. Counters are tempting for guaranteeing uniqueness and ordering, and would suit sequential ID generation, but they defeat the write distribution this time-series workload requires.
- ✗
Use timestamp directly as the first part of the row key
Why it's wrong here
Timestamps increase monotonically, so sequential writes land on one tablet and create the hotspotting the design must avoid. Timestamp-first keys are tempting because they give natural chronological ordering for range scans, and would suit read-heavy single-device queries rather than distributed writes.
- ✓
Reverse the timestamp string
Why this is correct
Reversing the timestamp string makes the least significant digits the row key prefix, spreading sequential writes across many row ranges rather than concentrating them on one tablet. This satisfies the anti-hotspotting constraint for time-series ingestion.
- ✓
Prepend a hash of the device ID to the timestamp
Why this is correct
Prepending a hash of the device ID scatters writes across many row ranges instead of concentrating sequential timestamps on one tablet. This satisfies the anti-hotspotting constraint by distributing load evenly across tablets as devices write concurrently.
- ✗
Use a secondary index on the timestamp column
Why it's wrong here
Cloud Bigtable has no secondary indexes; only the row key determines tablet distribution, so a timestamp index cannot spread load. Secondary indexes are tempting because they work in relational and other NoSQL systems, but Bigtable requires salting or hashing within the row key itself.
Go deeper
Related to this question
About these practice questions
One of 747 original PDE practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PDE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PDE exam.