Exam Professional Data Engineer topic 1 question 161 discussion

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

C correct answer

Even though I am sure the answer is C, but I am not sure why it will help avoid being charged for every query?

just like psu said. Additionally for a time-series data, it it usually the best practice to combine the identifier + time, not the values.

Option C is correct answer. Narrow table is good for time series data.

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.

"..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.

C is the answer. https://cloud.google.com/bigtable/docs/schema-design-time-series

time series = narrow table

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?

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

Correct: C

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/

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.

BQ is optimized for large-scale, ad-hoc SQL-based analysis. i Think it should be A

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

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