Exam Professional Data Engineer topic 1 question 119 discussion

Answer: A Description: Timestamp at starting of rowkey causes bottleneck issues

Stock symbol will be similar for most of the records, so it's better to start with random number.. Answer should be B

B is correct, By introducing a random number or a hash at the beginning of the row key, you distribute the writes and reads more evenly across the Bigtable cluster, thereby improving performance under heavy load. WHY NOT A? This might still cause hotspots if certain stocks are more popular than others. It could lead to uneven load distribution, which wouldn't solve the performance degradation problem.

Answer is A.

Answer A: Trick to remember: Row-key adjustment always be like in decending order. #<<Least value>>#<<Lesser value>> For example: 1. #<<Earth>>#<<continents>>#<<countries>>#<<cities>> and so on.. 2. #<<Stock>>#<<users>>#timestamp.. in 99% cases timestamp will be in the end, as its smallest division...

A is the answer. https://cloud.google.com/bigtable/docs/schema-design#row-keys It's important to create a row key that makes it possible to retrieve a well-defined range of rows. Otherwise, your query requires a table scan, which is much slower than retrieving specific rows. https://cloud.google.com/bigtable/docs/schema-design#row-keys-avoid Some types of row keys can make it difficult to query your data, and some result in poor performance. This section describes some types of row keys that you should avoid using in Bigtable. - Row keys that start with a timestamp. This pattern causes sequential writes to be pushed onto a single node, creating a hotspot. If you put a timestamp in a row key, precede it with a high-cardinality value like a user ID to avoid hotspots.

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

Correct: A

A and B would both work, since both would distribute the work. This question is not framed properly.

Vote for A

Option A. Below document explains Having EXCHANGE and SYMBOL in the leading positions in the row key will naturally distribute activity. https://cloud.google.com/bigtable/docs/schema-design-time-series

I think A

Catch here is current Rowley starts with timestamp which should not be in the starting or end position so symbolmshould be prefixed before timestamp

A is correct..A Good ROW KEY has to be an ID followed by timestamp. Stock symbol in this case works as an ID

A. You can find an example in Google's introductory guide. https://cloud.google.com/bigtable/docs/schema-design-time-series?hl=ja#financial_market_data

I think A would be best practice. Adding random numbers as start of rowkey doesn't help with troubleshooting

B should be the answer as adding random numbers in the beginning of the rowkey will distributes data across multiple nodes