You are developing an ecommerce application that stores customer, order, and inventory data as relational tables inside Cloud Spanner. During a recent load test, you discover that Spanner performance

Question

Options

• AThe use of 64-bit numeric types for 32-bit numbers.
• BThe use of the STRING data type for arbitrary-precision values.
• CThe use of Version 1 UUIDs as primary keys that increase monotonically.
• DThe use of LIKE instead of STARTS_WITH keyword for parameterized SQL queries.

• A
  4% (1)
• B
  7% (2)
• C
  79% (22)
• D
  11% (3)

Explanation

Using Version 1 UUIDs (or any monotonically increasing values like timestamps or sequential integers) as primary keys in Cloud Spanner causes hotspotting. Cloud Spanner distributes data across nodes based on key ranges (splits). When primary keys always increase monotonically, all new writes are directed to the same split (the one holding the highest key range), overloading a single node while others sit idle - this destroys linear scalability. Google's best practice is to use random UUIDs (Version 4) or hash-prefixed keys to distribute writes evenly across splits. Option A (64-bit vs 32-bit numeric types) has no material performance impact. Option B (STRING for arbitrary-precision) is a data modeling concern, not a performance hotspot cause. Option D (LIKE vs STARTS_WITH) is a minor query optimization, not the root cause of non-linear scaling.

No community discussion yet for this question.