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 is not scaling linearly as expected. Which of the following is the cause?
In Cloud Spanner, the use of Version 1 UUIDs as primary keys that increase monotonically can cause performance issues because they lead to hot spots in the data distribution. Monotonically increasing values as primary keys can cause a concentration of recent writes in a small range, leading to uneven load distribution and poor scaling. To avoid this, primary keys should be more evenly distributed to ensure balanced load across nodes.
C is correct https://cloud.google.com/spanner/docs/schema-and-data-model#choosing_a_primary_key
I vote C
Community choice is C
C - Version 1 is not recommended.
C is correct
In Cloud Spanner, the use of Version 1 UUIDs as primary keys that increase monotonically can cause performance issues because they are not evenly distributed. This can lead to hot regions, where a disproportionate number of requests are sent to a specific node or range of nodes, causing those nodes to become overloaded and leading to decreased performance. To improve performance, you should consider using primary keys that are more evenly distributed, such as hash-based keys or random integers.
A, the use of 64-bit numeric types for 32-bit numbers, is not likely to cause performance issues in Cloud Spanner. B, the use of the STRING data type for arbitrary-precision values, is not likely to cause performance issues in Cloud Spanner. D, the use of LIKE instead of STARTS_WITH keyword for parameterized SQL queries, is not likely to cause performance issues in Cloud Spanner.
https://cloud.google.com/spanner/docs/schema-design#uuid_primary_key Ans C
C is the answer. https://cloud.google.com/spanner/docs/schema-design#primary-key-prevent-hotspots Schema design best practice #1: Do not choose a column whose value monotonically increases or decreases as the first key part for a high write rate table.
C is the best option.
C. The use of Version 1 UUIDs as primary keys that increase monotonically. When designing schemas for Cloud Spanner, it is important to consider how the choice of primary keys can impact performance, especially under heavy load. Cloud Spanner splits data among servers based on the primary key values, so if the keys are monotonically increasing, as is the case with Version 1 UUIDs, new inserts are constantly added to the end of the table. This can create hotspots, where a single node receives a disproportionate amount of read and write requests, leading to performance bottlenecks and preventing linear scaling.
The most likely cause of the performance issue is C. The use of Version 1 UUIDs as primary keys that increase monotonically. Here's why: Version 1 UUIDs and Monotonicity: Version 1 UUIDs are generated based on timestamps and MAC addresses. When used as primary keys, they can lead to performance issues in Cloud Spanner due to their non-monotonic nature. As new UUIDs are generated, they are not guaranteed to be in a sequential order, which can cause fragmentation in the underlying storage and lead to slower queries.
Let's analyze why the other options are less likely: A. The use of 64-bit numeric types for 32-bit numbers: While using larger data types than necessary can impact storage space, it's unlikely to significantly affect performance in a way that would cause non-linear scaling. B. The use of the STRING data type for arbitrary-precision values: Using the STRING data type for numeric values can impact performance, but it's not the primary cause of non-linear scaling. Cloud Spanner is optimized for numeric data types. D. The use of LIKE instead of STARTS_WITH keyword for parameterized SQL queries: While using LIKE can be less efficient than STARTS_WITH for certain queries, it's unlikely to cause a significant performance bottleneck that would prevent linear scaling.