You have a network of 1000 sensors. The sensors generate time series data: one metric per sensor per second, along with a timestamp. You already have 1 TB of data, and expect the data to grow by 1…

Question

Options

• AStore your data in BigQuery. Concatenate the sensor ID and timestamp, and use it as the primary key.
• BStore your data in Bigtable. Concatenate the sensor ID and timestamp and use it as the row key. Perform an export to BigQuery every day.
• CStore your data in Bigtable. Concatenate the sensor ID and metric, and use it as the row key. Perform an export to BigQuery every day.
• DStore your data in BigQuery. Use the metric as a primary key.

• A
  13% (4)
• B
  59% (19)
• C
  22% (7)
• D
  6% (2)

Explanation

Option B is correct because Bigtable is purpose-built for high-throughput, low-latency key-value lookups on time series data - concatenating sensorID + timestamp as the row key enables direct O(1) row lookups that consistently achieve single-digit millisecond latency, which BigQuery simply cannot match. Exporting to BigQuery once daily satisfies the complex analytics requirement without over-engineering the primary store.

Why the distractors fail:

• A & D (BigQuery only): BigQuery is an analytical warehouse optimized for batch scans, not point lookups - its query latency is measured in seconds, never single-digit milliseconds, making it incompatible with access pattern #1.
• C (sensorID + metric as row key): Omitting the timestamp from the row key means there's no efficient way to retrieve the value at a specific timestamp - you'd have to scan rows rather than do a direct lookup, killing latency.

Memory tip: Match the tool to the latency SLA - if you see "millisecond latency + time series," think Bigtable; if you see "complex analytics/joins," think BigQuery. When both appear in the same question, the answer is almost always "Bigtable as primary store + BigQuery export."

No community discussion yet for this question.