Storing time-series data for low latency lookups and analytics?
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 GB every day. You need to access this data in two ways. The first access pattern requires retrieving the metric from one specific sensor stored at a specific timestamp, with a median single-digit millisecond latency. The second access pattern requires running complex analytic queries on the data, including joins, once a day. How should you store this data?
Community Votes
100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
This tests selecting the right database for specific access patterns; the trap is choosing BigQuery for low-latency lookups or designing a poor Bigtable row key that causes hotspotting.
Use Bigtable for high-throughput, low-latency time-series data and export to BigQuery for analytics. The community confirms this hybrid approach effectively meets the strict latency and complex query requirements.
Choosing Option A because BigQuery handles analytics, but ignoring the single-digit millisecond latency requirement for point lookups.
Community Discussion (6 comments)
- Bigtable excels at incredibly fast lookups by row key, often reaching single-digit millisecond latencies. - Constructing the row key with sensor ID and timestamp enables efficient retrieval of specific sensor readings at exact timestamps. - Bigtable's wide-column design effectively stores time series data, allowing for flexible addition of new metrics without schema changes. - Bigtable scales horizontally to accommodate massive datasets (petabytes or more), easily handling the expected data growth.
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Bigtable is designed for high throughput and low latency point reads, easily achieving single-digit millisecond latency. Constructing the row key by concatenating the Sensor ID and timestamp ensures efficient retrieval of specific data points and prevents hotspotting. The daily export to BigQuery satisfies the requirement for complex analytical queries involving joins, leveraging BigQuery's OLAP strengths.Why the Other Options Are Wrong
Options A and D use BigQuery, which is an OLAP data warehouse not optimized for the low-latency point lookups required (it typically takes seconds to return results). Option C suggests a poor row key design (Sensor ID + metric), which would cause hotspotting because all time-series data for a single sensor would be written to the same node, and it fails to allow efficient retrieval by timestamp.Community Comment Notes
The community strongly supports Option B, with top-rated comments highlighting Bigtable's speed and scalability. Users specifically note that the wide-column design is ideal for time-series data and that the proposed row key structure is the standard best practice for this type of workload.Official Reference
Exam Strategy
Identify the specific latency requirements. If you see "single-digit millisecond latency" for lookups, immediately look for a NoSQL option like Bigtable rather than a data warehouse like BigQuery.