一直以来的互联网谣言: UUID是不适合用作数据库主键的.
为什么? 因为UUID是全随机的, 对于数据库的索引不友好, 插入时可能导致大量的索引树的分支合并.
UUID
根据RFC4122的描述, UUID被设计用于去中心化的ID生成
格式
128bit, 16个字节, 示例: f81d4fae-7dec-11d0-a765-00a0c91e6bf6
按照8-4-4-4-12的格式进行分配, 每个位置用其16进制编码表示
具体结构如下:
+-------------------------------+
| 128 bits |
+-------------------------------+
| time_low (32 bits) | 0 - 31
+-------------------------------+
| time_mid (16 bits) | 32 - 47
+-------------------------------+
| time_hi_and_version (16 bits) | 48 - 63
+-------------------------------+
| clock_seq_hi_and_reserved (8 bits) | 64 - 71
+-------------------------------+
| clock_seq_low (8 bits) | 72 - 79
+-------------------------------+
| node (48 bits) | 80 - 127
+-------------------------------+
- time_low: 32位(8个十六进制数字)
- time_mid: 16位(4个十六进制数字)
- time_hi_and_version: 16位(4个十六进制数字,其中前4位表示版本号)
- clock_seq_and_reserved: 16位(4个十六进制数字,其中前2位用于标识变体)
- node: 48位(12个十六进制数字,通常是MAC地址或随机生成的值)
实现
在提案中, 同样提及了三种方式生成UUID
-
基于时间的UUID(Version 1) :
-
这种UUID是基于当前的时间戳生成的,时间戳是从1582年10月15日(公历改革的日期)开始的100纳秒间隔计数。
-
它包含一个节点标识符(通常是设备的MAC地址)以及一个时钟序列,以避免因时钟回拨而导致的重复UUID。
-
生成过程如下:
- 获取当前时间的100纳秒间隔计数。
- 获取当前的节点ID。
- 生成一个时钟序列,如果时钟回拨或节点ID改变,则更新时钟序列。
- 将这些值格式化为UUID的各个部分。
-
-
基于名称的UUID(Version 3和Version 5) :
-
这种UUID是通过对名称(如URL、域名等)进行哈希计算生成的。
-
Version 3使用MD5哈希算法,而Version 5使用SHA-1哈希算法。
-
生成过程如下:
- 为名称分配一个命名空间ID(UUID)。
- 将名称转换为标准的八位字节序列,并将命名空间ID以网络字节顺序放置。
- 计算命名空间ID与名称的哈希值。
- 根据哈希值的特定部分设置UUID的各个字段,包括版本号和时钟序列。
-
-
随机或伪随机UUID(Version 4) :
-
这种UUID是基于随机或伪随机数生成的。
-
生成过程如下:
- 设置UUID的变体字段(clock_seq_hi_and_reserved)和版本字段(time_hi_and_version)。
- 将UUID的其他位设置为随机或伪随机生成的值。
- 生成的UUID包括了当前的变体和版本信息。
-
完全随机的V4
其中, V3或者V5使用场景不是很多, V4的使用是最广泛的. 因为其实现方式, 决定了他的随机性是很强的, 几乎不存在空间上的内聚性.
存在时序性的V1
实际上V1已经表现出了时序性, 也就是在时间上的递增性.
但是为什么UUIDV1没有被广泛使用呢?
-
隐私问题:
- UUIDv1包含了节点标识符,通常是设备的MAC地址。这意味着生成的UUID可以泄露生成UUID的设备的信息,导致隐私问题。例如,攻击者可以通过UUID推测出特定设备的身份或位置。
-
时钟回拨问题:
- UUIDv1依赖系统时间来生成UUID,如果系统的时钟被意外地设置回过去,可能会导致生成重复的UUID。这是一个潜在的冲突风险,尤其是在分布式系统中,多个节点可能会同时生成UUID。
-
跨设备的唯一性问题:
- 随着设备移动或更换网络,MAC地址可能会发生变化。这使得UUIDv1在某些情况下可能无法保证跨设备的一致性和唯一性。
-
生成效率:
- UUIDv1生成过程需要访问系统时间和节点ID,可能会比其他方法(如UUIDv4)略显复杂且效率低。
-
替代方案的可用性:
- UUIDv4(基于随机或伪随机数生成的UUID)提供了更大的随机性和隐私保护,不需要依赖于时间或设备的标识符,因而更受欢迎。UUIDv4也避免了UUIDv1存在的许多缺点。
UUID V6 V7
为了解决UUID的一些问题, UUIDV6, UUIDV7 都尝试了进行改进, 参考文档
UUID V6
UUIDv6 相比于 UUIDv1 进行了以下改进:
-
时间顺序排序:
- UUIDv6 对时间戳的字节顺序进行了重新排列,使其变得可排序。UUIDv1 的时间戳是按照高位、中位和低位的顺序存储,这导致在数据库中插入时新生成的UUID可能分散在索引的随机位置,影响了数据库性能。UUIDv6 将时间戳的字节顺序调整为从高到低存储,确保相邻生成的UUID在数据库中也保持相近。
-
简化实现:
- UUIDv6 的设计使得现有的 UUIDv1 实现可以相对简单地调整为支持 UUIDv6,避免了完全重新设计的复杂性。
-
消除隐私问题:
- UUIDv1 使用 MAC 地址作为节点部分,这可能引发隐私和安全问题。虽然UUIDv6在节点部分仍然可以使用伪随机值,但在实现上可以选择避免使用MAC地址,从而降低安全风险。
-
改进的时钟序列处理:
- UUIDv6 保留了UUIDv1中的时钟序列,但在生成时提供了更好的保证,确保即使在同一时间戳下生成多个UUID,仍然能保持单调性和唯一性。
-
不再依赖于特定的时间戳格式:
- UUIDv1 使用了不太常见的100纳秒公历纪元时间戳,UUIDv6 的时间戳设计更为灵活,可以根据需要采用不同的时间戳格式。
UUIDV7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unix_ts_ms (48 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ver (4 bits) | rand_a (12 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| var (2 bits) | rand_b (62 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- 基于 Unix Epoch 时间戳:
UUIDv7 使用 Unix Epoch 时间戳(自 1970 年 1 月 1 日以来的毫秒数)作为时间源。这种时间戳更为常见和易于理解,而 UUIDv1 使用的是不常见的 Gregorian 时间戳(以 100 纳秒为单位的计时),这使得其在处理和表示上更加复杂。 - 排序性:
UUIDv7 设计为时间有序,可以直接按字节比较进行排序。由于它的时间戳是以毫秒为单位的,因此在数据库索引中的插入顺序更为合理,可以提高插入性能,而 UUIDv1 和 UUIDv6 的时间戳分散在不同的字段中,导致在数据库中插入时索引局部性较差。 - 改进的熵特性:
UUIDv7 提供了更好的熵特性,使用了额外的随机数位(rand_a 和 rand_b)来增加唯一性。这使得 UUIDv7 在高并发情况下生成的 UUID 更加独特,降低了碰撞的可能性。 - 简化的结构:
UUIDv7 的结构比 UUIDv1 和 UUIDv6 更加简单,专注于提供易于实现的时间戳和随机数据的组合。UUIDv7 包含一个48位的 Unix 时间戳,后面跟着一部分版本和随机数据,整体结构更加清晰。 - 去除了 MAC 地址:
UUIDv1 包含了设备的 MAC 地址,这在隐私和安全性上带来了风险。UUIDv7 不再使用 MAC 地址,改为完全依赖随机数生成器和时间戳,从而提高了安全性。
可以看到UUIDV7的结构已经具有了相当的时间内聚性, 即在一段时间内, UUID的大小总是在某个范围内, 这其实已经满足了我们对于主键的要求. 而且一共74bit的随机位也保证了非常好的随机性.
在增加上主键的唯一性保证, 其实已经基本满足了我们对于主键的要求.
标签:UUID,UUIDv1,UUIDV7,生成,时间,做主,UUIDv6,bits From: https://www.cnblogs.com/pDJJq/p/18393122/uuidv7-i-just-want-to-use-uuid-as-the-main-key-1v