不知道在Postgres中为主键使用什么数据类型？让我们对 UUID 和 ULID 进行测量，并决定哪个更好。
大家好！在本文中，我想分享我对经常用作标识符的数据类型的知识和看法。今天，我们将同时讨论两个话题。这些是按键和数据类型对数据库端键的搜索速度的度量。
我将使用 PostgreSQL 数据库和演示 Java 服务来比较查询速度。
UUID 和 ULID
为什么我们需要某种难以理解的 ID 类型？我不会谈论分布式系统、服务连接、敏感数据等。如果有人对此感兴趣，他们可以在谷歌上搜索 - 目前我们对性能感兴趣。顾名思义，我们将讨论两种类型的密钥：UUID 和 ULID。
UUID早已为大家所熟知，但ULID对某些人来说可能并不熟悉。ULID 的主要优点是它是单调递增的，并且是一种可排序类型。当然，这些并不是所有的区别。就个人而言，我也喜欢它中没有特殊字符的事实。
一个小题外话，我很久以前就注意到，许多团队使用数据类型将 UUID 存储在 PostgreSQL 数据库中，我不喜欢这样，因为这个数据库有 UUID 的相应数据类型。稍后，我们将看到哪种类型在数据库端更可取。因此，我们不仅要看后端两种数据类型的比较，还要看在数据库端以不同格式存储 UUID 时的区别。varchar(36)
比较
因此，让我们开始比较事物。
- UUID 长度为 36 个字符，占用 128 位内存。
- ULID 长度为 26 个字符，还占用 128 位内存。
在我的示例中，我在数据库中创建了两个表，其中包含三个字段：
SQL算法
1
CREATE TABLE test.speed_ulid
2
(
3
id varchar(26) PRIMARY KEY,
4
name varchar(50),
5
created timestamp
6
);
7
CREATE TABLE test.speed_uuid
8
(
9
id varchar(36) PRIMARY KEY,
10
name varchar(50),
11
created timestamp
12
);
对于第一次比较，我以格式存储了 UUID，这是经常做的那样。在数据库中，我在每个表中记录了 1,000,000 个。varchar(36)
测试用例将包括 100 个请求，使用以前从数据库中提取的标识符;也就是说，在调用测试方法时，我们将访问数据库 100 次，并通过 key 检索实体。在测量之前，将创建连接并预热。我们将进行两次测试运行，然后进行 10 次有效迭代。为方便起见，我将在文章末尾提供 Java 代码的链接。
对不起，测量是在标准MacBook Pro笔记本电脑上进行的，而不是在专用服务器上进行的，但我认为除了在数据库和后端之间的网络流量上花费的时间增加之外，结果不会有显着差异。
以下是一些背景信息：
- # 中央处理器 i9-9980HK
- # CPU 数量：16
- # 内存：32GB
- # JMH 版本：1.37
- # 虚拟机版本：JDK 11.0.12、Java HotSpot（TM） 64 位服务器虚拟机、11.0.12+8-LTS-237
- # 数据库：PostgreSQL 13.4，build 1914,64 位
将用于按键获取实体的查询：
SQL算法
1
SELECT * FROM test.speed_ulid where id = ?
2
SELECT * FROM test.speed_uuid where id = ?
测量结果
让我们看一下测量结果。让我提醒您，每个表有 1,000,000 行。
这两种类型的标识符都以 varchar 的形式存储在数据库中
我运行了几次这个测试，结果大致相同：要么 ULID 快一点，要么 UUID。按百分比计算，差异几乎为零。
好吧，您可以不同意这些类型之间没有区别。我想说的是，在数据库端不可能使用其他数据类型。
UUID 作为 uuid，ULID 作为数据库中的 varchar
在下一个测试中，我将数据类型从 test.speed_uuid 表中的 更改为 。varchar(36)uuid
在这种情况下，差异是显而易见的：4.5% 的人支持 UUID。
如您所见，在服务端使用同名类型的数据库端是有意义的。这种格式的索引在 PostgreSQL 中得到了很好的优化，并显示出良好的结果。uuid
好吧，现在我们绝对可以分道扬镳了。或不？
如果查看索引搜索查询计划，在使用 varchar 的情况下可以看到以下内容。((id)::text = '01HEE5PD6HPWMBNF7ZZRF8CD9R'::text)
一般来说，比较两个文本变量是一个相当缓慢的操作，所以也许没有必要以这种格式存储 ID。或者有没有其他方法可以加快关键比较？首先，让我们为具有 ULID 的表创建另一个 “” 类型的索引。hash
SQL算法
1
create index speed_ulid_id_index
2
on test.speed_ulid using hash (id);
让我们看一下查询的执行计划：
我们将看到数据库使用哈希索引，而不是在这种情况下的 btree。让我们运行我们的测试，看看会发生什么。
varchar + index（hash） 用于 ULID，uuid 用于 UUID
这种组合相对于其作弊指数增加了 2.3%。uuid
我不确定在一个字段上保留两个索引是否合理。因此，值得考虑的是，您是否可以做更多的事情。在这里，值得回顾一下过去，并记住过去或其他一些字符串标识符的存储方式。没错：要么是文本，要么是字节数组。uuid
因此，让我们尝试此选项：我删除了 ULID 的所有索引，将其转换为 ，然后重新创建了主键。bytea
bytea 表示 ULID，uuid 表示 UUID
结果，我们得到了与上一次运行大致相同的结果，但有一个额外的索引，但我个人更喜欢这个选项。
数据库中有 2,000,000 行的测量结果：
数据库中有 3,000,000 行的测量结果：
我认为继续测量是没有意义的。模式仍然存在：保存为 ULID 的性能略优于保存在 DB 中的 UUID。byteauuid
如果我们从第一次测量中获取数据，很明显，在小操作的帮助下，如果您使用 .varchar
所以，如果你已经读到这里，我认为这篇文章对你来说很有趣，你已经为自己得出了一些结论。
值得注意的是，测量是在后端部分和数据库的理想条件下进行的。我们没有运行任何并行进程来向数据库写入内容、更改记录或在后端执行复杂的计算。
结论
让我们回顾一下材料。你学到了什么有用的？
- 不要忽略 PostgreSQL 端的数据类型。也许有一天 ULID 的扩展会出现在这个数据库中，但就目前而言，我们拥有了我们所拥有的。
uuid - 有时，需要手动创建所需类型的附加索引，但需要考虑开销。
- 如果您不害怕不必要的工作 - 即为类型编写自己的转换器 - 那么您应该尝试在数据库端没有标识符的相应类型。
bytea
主键应该使用什么类型的数据，应该以什么格式存储？对于这些问题，我没有明确的答案：这完全取决于许多因素。还值得注意的是，ID 数据类型的适当选择，而不仅仅是 ID，在某些时候可以在您的项目中发挥重要作用。
我希望这篇文章对你有用。祝你好运！
- GitHub 上的项目
