Exam Associate Cloud Engineer topic 1 question 98 discussion

Create a secondary index using the following Data Definition. If we watch the next video, he talks about a change to monotonically when we insert rows. Finally when we talk about read and we have a perdormance issues, we must create a index. https://www.youtube.com/watch?v=r6uj0HMNQNQ

• Hotspotting Issue: Cloud Spanner, like many distributed databases, can experience issues with what is known as "hotspotting." This happens when a large portion of read or write operations are concentrated on a specific part of the database. In this case, the sequential nature of the person_id as a primary key can lead to hotspotting because new records are continually added at the "end" of the key space, creating a hot node which can cause performance bottlenecks. • Monotonically Increasing Values: Monotonically increasing values as primary keys can exacerbate the hotspotting effect because each new entry is placed after the last, creating a write hotspot on the last node that handles the upper bound of the key range. Over time, this can lead to unbalanced read/write loads across the nodes.

Why B: To improve read performance, we should add a secondary index on the primary key. Since we know that this table is accessed only by the primary key, this would optimize read operations. Why not C: Monotonically increasing values might create a hotspot, but this would primarily affect write operations. In fact, lookups would be easier with sequential values compared to a UUID. Additionally, it is not mentioned that users are only reading the last inserted data, which would create a read hotspot. Why not D: This approach could work, but since the table is accessed only by the primary key, there's no need to add additional fields to the index. Why not A: The profile_picture field should not significantly affect read performance.

D is correct for me

The correct answer is C

D makes no sense. It's C

C seems more correct

How is this a GCP question?

PK already has index by default, so not B. D - index by 3 fields. but users use person_id for acces, so D is wrong. So C - because monotonically increasing fields is not good candidate for PK(because index degradetion)

Based on the supplied video by others; https://www.youtube.com/watch?v=r6uj0HMNQNQ, we can see at time 1:47 that due to the slitting of the rows, a sequential primary key will create hotspots. Therefor we need a non-sequential key; e.g. hash-based key

B. is correct...Add a secondary index on the person_id column. Adding a secondary index on the person_id column would help resolve the read latency-related performance issues on this table. Since the table is accessed using only the primary key, creating a secondary index on the person_id column would allow Cloud Spanner to retrieve the data using the index, rather than scanning the entire table. This can significantly reduce the read latency for queries that access this table. Removing the profile_picture field or changing the primary key to not have monotonically increasing values may not necessarily resolve the performance issues related to read latency. Creating a secondary index is a more targeted solution to address the specific issue at hand. Option D is incomplete and does not provide enough information to assess its correctness.

Create a secondary index using the following Data Definition. If we watch the next video, he talks about a change to monotonically when we insert rows. Finally when we talk about read and we have a perdormance issues, we must create a index. https://www.youtube.com/watch?v=r6uj0HMNQNQ

I think it is C

It's definetely C, D doesn't make sense here

Choose a primary key to prevent hotspots As mentioned in Schema and data model, you should be careful when choosing a primary key to not accidentally create hotspots in your database. One cause of hotspots is having a column whose value monotonically increases as the first key part, because this results in all inserts occurring at the end of your key space. This pattern is undesirable because Spanner divides data among servers by key ranges, which means all your inserts will be directed at a single server that will end up doing all the work.

C https://cloud.google.com/spanner/docs/schema-design#primary-key-prevent-hotspots

C is the right answer. Why? "This table is accessed only by their users using a primary key." So adding additional indexes on firstname and lastname won't help.