在Cloud Spanner中存储UUID [英] Storing a UUID in Cloud Spanner

问题描述

我想使用UUID作为Cloud Spanner中的主键.读写UUID的最佳方法是什么?是否有UUID类型或客户端库支持?

I would like to use a UUID as a primary key in Cloud Spanner. What is the best way to read and write UUIDs? Is there a UUID type, or client library support?

推荐答案

最简单的解决方案是将其作为STRING存储在标准 RFC 4122 格式.例如:

The simplest solution is just to store it as a STRING in the standard RFC 4122 format. E.g.:

" d1a0ce61-b9dd-4169-96a8-d0d7789b61d9 "

这将需要37个字节来存储(36个字节加上一个长度字节).如果您确实想保存每个可能的字节，则可以将UUID存储为两个INT64.但是，您需要编写自己的库来对值进行序列化/反序列化，并且它们在SQL查询中看起来不会很漂亮.在大多数情况下，每行节省约21个字节可能不值得.

This will take 37 bytes to store (36 bytes plus a length byte). If you really want to save every possible byte, you could store your UUID as two INT64's. However, you would need to write your own libraries for serializing/deserializing the values, and they wouldn't appear very pretty in your SQL queries. In most cases, the extra ~21 bytes of savings per row is probably not worth it.

请注意，某些UUID生成算法会根据时间戳顺序生成UUID.如果机器生成的UUID值单调增加，则可能导致Cloud Spanner出现热点(类似于使用时间戳作为主键开始的反模式)，因此最好避免这些变体(例如，不建议使用UUID版本1).

Note that some UUID generation algorithms generate the UUID sequentially based on a timestamp. If the UUID values generated by a machine are monotonically increasing, then this can lead to hot-spotting in Cloud Spanner (this is analogous to the anti-pattern of using timestamps as the beginning of a primary key), so it is best to avoid these variants (e.g. UUID version 1 is not recommended).

这篇关于在Cloud Spanner中存储UUID的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！