How do I get low-double-digit milliseconds write latencies on Cloud Spanner?

Question

I am using Cloud Spanner with my application which is latency sensitive. The write latencies are taking a bit more time than expected. What could I do to reduce these latencies?

I was expecting low double digit write latencies.

Answer 1

1. Ensure that you have selected the region closest to your application. For multi-region configurations, ensure that the default leader is set to the closest region. (reference)
2. Check that you do not have unnecessary secondary indices. Be aware that using the commit timestamp column as the first part of the secondary index can create hotspots and reduce write performance.
3. For bulk writes to the database, please go through this doc for getting the best write throughput. If you are bulk inserting into a non-empty table, try to use a smaller mutation size per transaction.
4. To reduce latency, use batch DML to send multiple DML statements to Spanner within a single client-server round trip. Additionally, grouping similar INSERT, UPDATE, or DELETE statements together within batches can result in faster and more efficient data updates. Spanner automatically optimizes the way it processes contiguous, batched DML statements that differ only in parameter values, and which do not contain complex data dependencies. (reference)
5. Use a WHERE clause to reduce the scope of locks. To modify data as efficiently as possible, use a WHERE clause that enables Spanner to read only the necessary rows. You can achieve this goal with a filter on the primary key, or on the key of a secondary index. The WHERE clause limits the scope of the shared locks and enables Spanner to process the update more efficiently. (reference)
6. Use partitioned DML for periodic clean up and garbage collection or backfilling new columns with default values. Partitioned DML enables large-scale, database-wide operations with minimal impact on concurrent transaction processing by partitioning the key space and running the statement over partitions in separate, smaller-scoped transactions.

For further troubleshooting, please do refer to this section in the latency guide.