Bigtable for time-series data in GCP - Step-by-Step Execution

Process Flow - Bigtable for time-series data

Data Ingestion

↓

Row Key Design

↓

Write to Bigtable

↓

Data Storage

↓

Query Time Range

↓

Read from Bigtable

↓

Analyze or Visualize

Data flows from ingestion through a row key design optimized for time-series, stored in Bigtable, then queried by time range for analysis.

Execution Sample

GCP

RowKey = deviceID#timestamp
Write data with RowKey
Query rows by timestamp range
Read and process results

Shows how time-series data is stored and queried in Bigtable using a composite row key.

Process Table

Step	Action	Row Key Example	Data Stored	Query Condition	Result
1	Ingest data point	device123#20240601120000	temperature=22.5		Data ready to write
2	Write data to Bigtable	device123#20240601120000	temperature=22.5		Data stored in row
3	Ingest next data point	device123#20240601120500	temperature=22.7		Data ready to write
4	Write data to Bigtable	device123#20240601120500	temperature=22.7		Data stored in row
5	Query data			RowKey >= device123#20240601120000 AND RowKey <= device123#20240601121000	Returns rows with timestamps 12:00 and 12:05
6	Process query result				Data points extracted for analysis
7	Query outside range			RowKey >= device123#20240601130000 AND RowKey <= device123#20240601131000	No rows returned
8	End				No more data in range, query ends

💡 Query ends when no more rows match the time range condition

Status Tracker

Variable	Start	After Step 1	After Step 3	After Step 5	Final
RowKey		device123#20240601120000	device123#20240601120500	device123#20240601120000 to device123#20240601121000
Data Stored		temperature=22.5	temperature=22.7	Both data points retrieved
Query Condition				RowKey >= device123#20240601120000 AND RowKey <= device123#20240601121000
Query Result				Rows with timestamps 12:00 and 12:05	No rows for later range

Key Moments - 3 Insights

Why is the timestamp part of the row key important?

Including the timestamp in the row key allows efficient range queries by time, as shown in execution_table step 5 where the query uses row key ranges to find data.

What happens if the query time range has no matching rows?

As in step 7 and 8, the query returns no rows and ends, showing Bigtable returns empty results gracefully when no data matches.

Why combine device ID and timestamp in the row key?

Combining device ID and timestamp groups data by device and orders it by time, enabling fast lookups and scans for each device's time-series data, as seen in the row key examples.

Visual Quiz - 3 Questions

Look at the execution_table at step 5, what time range does the query cover?

A From 12:00 to 12:10

B From 12:00 to 12:05

C From 12:05 to 12:10

D From 13:00 to 13:10

💡 Hint

Check the 'Query Condition' column in step 5 for the exact row key range

According to variable_tracker, what is the value of 'Data Stored' after step 3?

A temperature=22.5

B temperature=22.7

C No data stored yet

D Both data points stored

💡 Hint

Look at the 'Data Stored' row under 'After Step 3' column

If the timestamp was not part of the row key, how would the query in step 5 change?

A It would still query by row key range efficiently

B It would query by device ID only

C It would need a full table scan to find data by time

D It would return no data

💡 Hint

Consider how row key design affects query efficiency as explained in key_moments

Concept Snapshot

Bigtable stores time-series data using a composite row key like deviceID#timestamp.
This design enables fast writes and efficient range queries by time.
Queries specify row key ranges to retrieve data points in time order.
If no data matches the time range, queries return empty results.
Good row key design is key for performance in time-series workloads.

Full Transcript

This visual execution shows how time-series data is stored and queried in Google Cloud Bigtable. Data points are ingested with a row key combining device ID and timestamp. Each data point is written as a row with this key. Queries specify a range of row keys to retrieve data points within a time range. The execution table traces data ingestion, storage, querying, and results. Variable tracking shows how row keys and data evolve. Key moments clarify why timestamp in the row key is critical for efficient queries and what happens when no data matches a query. The quiz tests understanding of query ranges, stored data, and row key design impact. The snapshot summarizes best practices for using Bigtable with time-series data.