Topic 2 Question 66
2 つ選択Which row keys are likely to cause a disproportionate number of reads and/or writes on a particular node in a Bigtable cluster (select 2 answers)?
A sequential numeric ID
A timestamp followed by a stock symbol
A non-sequential numeric ID
A stock symbol followed by a timestamp
解説
...using a timestamp as the first element of a row key can cause a variety of problems. In brief, when a row key for a time series includes a timestamp, all of your writes will target a single node; fill that node; and then move onto the next node in the cluster, resulting in hotspotting. Suppose your system assigns a numeric ID to each of your application's users. You might be tempted to use the user's numeric ID as the row key for your table. However, since new users are more likely to be active users, this approach is likely to push most of your traffic to a small number of nodes. [https:// cloud.google.com/bigtable/docs/schema-design] Reference: https://cloud.google.com/bigtable/docs/schema-design-time-series#ensure_that_your_row_key_avoids_hotspotting
コメント(3)
Correct : AB
👍 5[Removed]2020/03/21Answer: A, B Description: bigtable says no timestamp at the starting and no sequential ids
👍 5[Removed]2020/03/29I would choose AB
- Row keys that start with a timestamp. This will cause sequential writes to be pushed onto a single node, creating a hotspot. If you put a timestamp in a row key, you need to precede it with a high-cardinality value like a user ID to avoid hotspotting. 2.Sequential numeric IDs. Suppose your system assigns a numeric ID to each of your application's users. You might be tempted to use the user's numeric ID as the row key for your table. However, because new users are more likely to be active users, this approach is likely to push most of your traffic to a small number of nodes. https://cloud.google.com/bigtable/docs/schema-design
👍 2Venson2021/06/17
シャッフルモード