Bigtable Time-Series Schema Design for Cost and Scalability

PDE By islever Editorial Last updated

Selecting storage systems. Monitoring and troubleshooting processes.

Short answer

C Create a narrow table in Bigtable with a row key that combines the Computer Engine computer identifier with the sample time at each second.

Question

You need to choose a database to store time series CPU and memory usage for millions of computers. You need to store this data in one-second interval
samples. Analysts will be performing real-time, ad hoc analytics against the database. You want to avoid being charged for every query executed and ensure that
the schema design will allow for future growth of the dataset. Which database and data model should you choose?
  1. Create a table in BigQuery, and append the new samples for CPU and memory to the table
  2. Create a wide table in BigQuery, create a column for the sample value at each second, and update the row with the interval for each second
  3. Create a narrow table in Bigtable with a row key that combines the Computer Engine computer identifier with the sample time at each second Correct Answer
  4. Create a wide table in Bigtable with a row key that combines the computer identifier with the sample time at each minute, and combine the values for each second as column data.

Key Takeaways

The trap is confusing 'wide tables' (often used in relational DBs or specific Bigtable optimizations like time-bucketing) with general flexibility. For IoT/time-series with evolving metrics, Bigtable's tall/narrow design is superior for schema evolution.

This question tests the selection of Cloud Bigtable over BigQuery for time-series data to avoid per-query costs. The correct approach is using a tall, narrow schema design to ensure flexibility for future metric additions.

Common mistake: Choosing Option D (Wide Table/Time-Buckets) because it seems more efficient for storage. However, wide tables make it difficult to add new metrics (KPIs) later without significant schema changes, violating the 'future growth' requirement.

Expert Analysis

The scenario requires storing high-volume time-series data (CPU/memory at one-second intervals) for millions of machines with real-time ad-hoc analytics and a cost model that avoids per-query charges.

Cost Model Analysis: BigQuery is a serverless data warehouse billed primarily on bytes processed per query (though caching exists, it doesn't guarantee zero charge for varied ad-hoc queries). Cloud Bigtable is billed based on provisioned nodes and storage capacity, not per query. This eliminates Options A and B immediately.

Schema Design Analysis: The core decision is between Option C (tall/narrow) and Option D (wide/time-bucketing).

  • Option D suggests combining values for each second into column data within a row keyed by minute. While Bigtable supports 'time-bucketing' (grouping multiple timestamps into columns to improve compression), the prompt explicitly states samples are at one-second intervals. Creating a wide table where every second is a column would result in extremely sparse rows (only one active column per minute if aggregating, or massive width if not). More critically, comments highlight that adding new KPIs (future growth) to a wide schema is difficult because you'd need to add 60+ columns per metric.
  • Option C proposes a tall and narrow table. In Bigtable best practices for time series, a tall/narrow design uses a composite row key (e.g., computer_id + timestamp) and stores each sample as a separate row or column family entry. This allows infinite scalability of metrics (adding CPU, Memory, Disk just adds new column families without altering the row structure) and handles high write throughput efficiently. It aligns with the requirement for future schema growth.

Therefore, C is the correct answer. It satisfies the NoSQL nature of Bigtable, the cost model (no per-query fees), and the flexibility required for future metric additions.

Official Reference

https://cloud.google.com/bigtable/docs/schema-design-time-series

This link opens the official vendor documentation in a new tab.

Exam Strategy

When evaluating database choices, always check the pricing model first. If the requirement is to avoid per-query costs for high-frequency reads/writes, eliminate serverless SQL warehouses (like BigQuery) in favor of NoSQL stores (like Bigtable). Next, evaluate schema flexibility: 'future growth' in metrics usually points toward a flexible, tall/narrow NoSQL design rather than a rigid, wide relational-style schema.

Frequently Asked Questions

Why is BigQuery not suitable for this use case?

BigQuery bills based on bytes processed per query. For millions of computers generating one-second interval data with real-time ad-hoc analytics, the volume of queries would lead to unpredictable and potentially high costs. Bigtable offers a flat rate based on capacity.

What is the difference between tall/narrow and wide tables in Bigtable?

A tall/narrow table has many rows with few columns (e.g., one sample per row). A wide table has fewer rows but many columns. Tall/narrow is better for frequent writes and adding new metrics, while wide tables can be optimized for specific read patterns but are less flexible for schema changes.

More PDE FAQ →

Community Votes

C
75%
D
25%

75% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 31 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 30 of 31

  1. psu 👍 35
    Answer C A tall and narrow table has a small number of events per row, which could be just one event, whereas a short and wide table has a large number of events per row. As explained in a moment, tall and narrow tables are best suited for time-series data. For time series, you should generally use tall and narrow tables. This is for two reasons: Storing one event per row makes it easier to run queries against your data. Storing many events per row makes it more likely that the total row size will exceed the recommended maximum (see Rows can be big but are not infinite). https://cloud.google.com/bigtable/docs/schema-design-time-series#patterns_for_row_key_design
  2. madhu1171 👍 19
    C correct answer
  3. Sumanth09 👍 8
    Should be A question did not talk about latency without query cost -- BigQuery Cache flexible schema - BigQuery (nested and repeated)
  4. rickywck 👍 6
    should be C: https://cloud.google.com/bigtable/docs/schema-design-time-series
  5. safiyu 👍 5
    C is the correct answer. If you consider wide table, then 60 columns for cpu usage and 60 columns for memory usage. in future, if you need to add a new kpi to the table, then the schema changes. you will have to add 60 more columns for the new feature. this is not so future proof.. so D is out of the picture.
Show 25 more comments
  1. WillemHendr 👍 4 Answered D
    "..and ensure that the schema design will allow for future growth of the dataset": https://cloud.google.com/bigtable/docs/schema-design-time-series#time-buckets "Data stored in this way is compressed more efficiently than data in tall, narrow tables." I read the "future growth" as a sign to be effective in storage, and go for the Time-Buckets.
  2. arnabbis4u 👍 4
    C look Fine.. Only doubt I have is it says they don't want to pay for every query execution. That requires the Bigquery caching feature. Confused. Anyone wants to comment on this?
  3. FARR 👍 4
    bigquery pricing is query based and query-caching is helpful when queries exactly the same whereas bigtable prcing is mostly infra-based hence, answer should be C
  4. dg63 👍 4
    I believe A. Use case requires support for Adhoc queries, and avoiding duplicate query costs.
  5. arnabbis4u 👍 4
    I think A.
  6. squishy_fishy 👍 3
    Answer is C. Bigtable is best suited to the following scenarios: time-series data (e.g. CPU and memory usage over time for multiple servers), financial data (e.g. transaction histories, stock prices, and currency exchange rates), and IoT (Internet of Things) use cases. https://www.xplenty.com/blog/bigtable-vs-bigquery/
  7. _8008_ 👍 3
    What about "avoid being charged for every query executed"? Nothing on this topic in here https://cloud.google.com/bigtable/docs/schema-design-time-series can anyone comment?
  8. Callumr 👍 3
    A - BigQuery caching will reduce query costs, and low latency of big table is not needed
  9. Prakzz 👍 3
    both C and D row key will cause hotspotting
  10. VM_GCP 👍 2
    BigQuery cannot be the answer as [1] This will not save the price by caching as query will not always be same https://cloud.google.com/bigquery/docs/cached-results#limitations [2] And the BigTable is always the correct solution for this use case as given in https://cloud.google.com/bigtable/docs/overview#what-its-good-for BigTable has native time series support and is preferred for large analytical and operational work Answer can be C or D. But problem is both the options will cause hot spotting. So not sure which to select
  11. lollo1234 👍 2
    How do you store both CPU and memory usage though? Two sets of 60 columns per row? I am wondering if that goes along with "the schema design will allow for future growth"...what if by future growth they mean monitoring N more metrics. That would imply N*60 columns, right?
  12. medeis_jar 👍 2 Answered C
    Narrow and tall table for a single event and good for time-series data Short and Wide table for data over a month, multiple events
  13. DeepakS227 👍 2
    BQ is optimized for large-scale, ad-hoc SQL-based analysis. i Think it should be A
  14. Remi2021 👍 2 Answered C
    time series = narrow table
  15. VM_GCP 👍 2
    I will go for C
  16. JG123 👍 2
    Correct: C
  17. carbonscave 👍 1 Answered D
    Why D is correct Bigtable Pricing Model: Cloud Bigtable is Google's fully managed NoSQL wide-column store, purpose-built for massive-scale, high-throughput time-series data. Most importantly for this prompt, Bigtable bills you a flat hourly rate for provisioned nodes and storage capacity. You are not charged per query. This perfectly satisfies the requirement to "avoid being charged for every query executed". Time Bucketing (The Wide Schema Pattern): When capturing data every second for millions of devices, creating a new row for every single second generates massive metadata overhead and balloons the size of the database. Google's architectural best practice for Bigtable time-series schemas is "time bucketing." By creating a row key at the minute level (e.g., device123#20231030-10:15) and storing the 60-second intervals as individual columns within that single row, you drastically reduce the number of rows, improve data compression, and optimize the database for massive future growth.
  18. barnac1es 👍 1 Answered C
    Scalability: Bigtable can handle large-scale data efficiently, making it suitable for storing time series data for millions of computers. Low Latency: Bigtable provides low-latency access to data, which is crucial for real-time analytics. Flexible Schema: The narrow table design allows you to efficiently store and query time series data without specifying all possible columns in advance, providing flexibility for future growth. Column Families: Bigtable supports column families, allowing you to organize data logically. Row Key Design: Combining the computer identifier with the sample time at each second in the row key allows for efficient retrieval of data for specific computers and time intervals. Analytics: While Bigtable does not support SQL directly, it allows for efficient data retrieval and can be integrated with other tools for analytics.
  19. koupayio 👍 1
    First C & D won't cause hotspoting as computer_identifier is first part of row key I prefer D because "ensure that the schema design will allow for future growth of the dataset." C is too tall and narrow I cannot see schema design grow in the future
  20. Aman47 👍 1
    No, it won't, because preceding timestamp with identifier values helps in a tradeoff between randomised row keys and manifesting grouping of similar entities.
  21. crslake 👍 1
    D, Better overall, harder to implement (but that is not stated as a constraint) https://cloud.google.com/bigtable/docs/schema-design-time-series#time-buckets
  22. nadavw 👍 1
    there is a limit of 60 columns per row according to question. in addition in D the cost will be a lower which is a requirement. so D seems more suitable.
  23. AzureDP900 👍 1
    C. Create a narrow table in Bigtable with a row key that combines the Computer Engine computer identifier with the sample time at each second
  24. SamuelTsch 👍 1 Answered C
    just like psu said. Additionally for a time-series data, it it usually the best practice to combine the identifier + time, not the values.
  25. shangning007 👍 1 Answered C
    Even though I am sure the answer is C, but I am not sure why it will help avoid being charged for every query?

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

How to establish consistent BigQuery spend?

S-grade

Triggering Airflow DAGs Reactively in Private Cloud Composer

S-grade

Bigtable Row Key Design for Time-Series Data

S-grade

Monitoring Cloud Bigtable for Cluster Scaling Decisions

S-grade

← Back to PDE Study Guide