Bigtable for time-series data in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

Choosing the best row key design for time-series data in Bigtable

You want to store sensor readings collected every second in Bigtable. Which row key design will best prevent hotspotting and allow efficient range scans for recent data?

A Use a row key with the sensor ID followed by the reversed timestamp (e.g., sensor123#99999999999999 - timestamp).

B Use a row key with the timestamp in ascending order followed by the sensor ID (e.g., 20240601120000#sensor123).

C Use a row key with the sensor ID followed by the timestamp in ascending order (e.g., sensor123#20240601120000).

D Use a row key with a random UUID followed by the timestamp (e.g., uuid#20240601120000).

💡 Hint

Think about how Bigtable stores rows lexicographically and how to avoid all writes going to the same region.

Using the sensor ID followed by a reversed timestamp distributes writes across Bigtable nodes and allows efficient scans for recent data by scanning rows with decreasing timestamps.

❓ service_behavior

intermediate

Bigtable read latency for time-series queries

You query Bigtable for sensor data over the last hour using a row key range scan. What behavior should you expect regarding read latency?

A Read latency will be constant regardless of the time range size because Bigtable indexes all data.

B Read latency increases linearly with the number of rows scanned in the time range.

C Read latency decreases as the time range increases because Bigtable caches more data.

D Read latency is unpredictable and depends only on network speed.

💡 Hint

Consider how Bigtable stores data and how scanning more rows affects performance.

Bigtable stores data sorted by row key. Scanning a larger time range means reading more rows, so latency increases roughly linearly with the number of rows scanned.

❓ security

advanced

Securing Bigtable access for time-series ingestion

You have multiple IoT devices sending time-series data to Bigtable. Which approach best secures write access while minimizing operational overhead?

A Use a proxy service that authenticates devices and writes to Bigtable using a single service account with limited permissions.

B Use Cloud IAM to grant each device a unique service account with only write permissions to the specific Bigtable instance.

C Allow all devices to write anonymously to Bigtable by disabling authentication temporarily during ingestion.

D Create a single service account with full Bigtable admin permissions and share its key with all devices.

💡 Hint

Think about security best practices and operational simplicity when many devices are involved.

Using a proxy service centralizes authentication and authorization, reducing the risk of key leakage and simplifying permission management. Devices authenticate to the proxy, which writes to Bigtable with a controlled service account.

✅ Best Practice

advanced

Optimizing Bigtable schema for time-series data compression

Which schema design choice helps Bigtable compress time-series data most effectively?

A Store sensor readings in a single column family with timestamps as part of the row key.

B Store each sensor reading as a separate column with a unique timestamp as the column qualifier.

C Store sensor readings in a single column with timestamps encoded in the cell value.

D Store sensor readings in a single column family with timestamps as column qualifiers sorted in ascending order.

💡 Hint

Consider how Bigtable compresses data within column families and the effect of sorted column qualifiers.

Bigtable compresses data within column families and benefits from sorted column qualifiers. Using timestamps as sorted column qualifiers in a single column family allows better compression and efficient scans.

🧠 Conceptual

expert

Impact of hot-spotting on Bigtable write throughput for time-series data

You notice Bigtable write throughput drops significantly during peak sensor data ingestion. Which cause best explains this behavior?

A Write throughput drops because Bigtable limits writes per column family regardless of row key distribution.

B Bigtable automatically balances writes evenly, so throughput drops are caused by network congestion only.

C All writes are targeting a small range of row keys due to monotonically increasing timestamps causing hotspotting on a single tablet server.

D The Bigtable instance is running out of storage space, causing automatic throttling of all writes.

💡 Hint

Think about how Bigtable partitions data and how row key design affects write distribution.

Monotonically increasing row keys cause all writes to go to the same tablet server, creating a hotspot that limits write throughput. Proper row key design avoids this by distributing writes.