Google Associate Cloud Engineer
Get started today
Ultimate access to all questions.
You are managing a globally accessible apparel website using Cloud Spanner. Despite the global reach, you've encountered read latency issues on a specific table accessed solely via its primary key. The table's schema is as follows:
CREATE TABLE Users (
user_id INT64 NOT NULL, // Sequential number based on registration
account_creation_date DATE, // System date
firstname STRING(255), // First name
lastname STRING(255), // Last name
birthdate DATE, // User birthdate
profile_picture BYTES(255) // User profile picture
) PRIMARY KEY (user_id)
What action should you take to mitigate these performance issues?
You are managing a globally accessible apparel website using Cloud Spanner. Despite the global reach, you've encountered read latency issues on a specific table accessed solely via its primary key. The table's schema is as follows:
CREATE TABLE Users (
user_id INT64 NOT NULL, // Sequential number based on registration
account_creation_date DATE, // System date
firstname STRING(255), // First name
lastname STRING(255), // Last name
birthdate DATE, // User birthdate
profile_picture BYTES(255) // User profile picture
) PRIMARY KEY (user_id)
What action should you take to mitigate these performance issues?
Real Exam
Explanation:
Correct Answer: C Ensuring the primary key does not have monotonically increasing values can alleviate read latency by preventing hotspotting, where operations concentrate on a few nodes, thus distributing the workload more evenly.
Why Not Others?
- A: Removing the
profile_picturefield, a byte type storing binary data like images, doesn't directly improve read latency. - B: Adding a secondary index on
person_idis ineffective since queries use the primary key, notperson_id. - D: Creating a secondary index via DDL doesn't address the core issue of primary key access patterns causing latency.
For further reading on schema design and primary key selection in Cloud Spanner, consider these resources: