更多编程技术文章，请查阅IOKKS - 专业编程技术分享平台

我将使用PostgreSQL数据库和演示Java服务来比较查询速度。

UUID和ULID

为什么我们需要一些难以理解的ID类型？我不会谈论分布式系统、服务的连接性、敏感数据等等。如果有人对此感兴趣，可以自行搜索 - 目前我们感兴趣的是性能。正如其名称所示，我们将讨论两种类型的键：UUID和ULID。

UUID早已为人所知，但ULID对一些人来说可能不太熟悉。ULID的主要优势在于它是单调递增的，是一种可排序的类型。当然，这些并不是所有的区别。就我个人而言，我也喜欢它没有特殊字符这一事实。

一个小插曲，我很久以前就注意到许多团队在PostgreSQL数据库中使用varchar(36)数据类型来存储UUID，我不喜欢这样，因为这个数据库有相应的UUID数据类型。稍后，我们将看到在数据库端存储UUID的不同格式时，哪种类型更可取。因此，我们将不仅比较后端的两种数据类型，还将比较在不同格式下存储UUID时的差异。

比较

让我们开始比较这些事情。

• UUID有36个字符长，占用128位内存。
• ULID有26个字符长，同样占用128位内存。

对于我的示例，我在数据库中创建了两个表，每个表有三个字段：

CREATE TABLE test.speed_ulid
(
    id      varchar(26) PRIMARY KEY,
    name    varchar(50),
    created timestamp
);
CREATE TABLE test.speed_uuid
(
    id       varchar(36) PRIMARY KEY,
    name    varchar(50),
    created timestamp
);

对于第一次比较，我以通常的方式将UUID存储为varchar(36)格式。在数据库中，我在每个表中记录了1,000,000条数据。

测试用例将包括100个请求，使用先前从数据库中提取的标识符；也就是说，在调用测试方法时，我们将100次访问数据库并通过键检索实体。在测量之前，将创建并预热连接。我们将进行两次测试运行，然后进行10次有效迭代。为了您的方便，我将在文章末尾提供Java代码的链接。

抱歉，但是这些测量是在标准的MacBook Pro笔记本电脑上进行的，而不是在专用服务器上进行的，但我相信除了在数据库和后端之间的网络流量增加之外，结果不会有显著的差异。

以下是一些背景信息：

• # CPU I9-9980HK
• # CPU核数：16
• # RAM：32GB
• # JMH版本：1.37
• # VM版本：JDK 11.0.12, Java HotSpot(TM) 64位服务器VM, 11.0.12+8-LTS-237
• # DB： PostgreSQL 13.4, build 1914, 64位

将用于通过键获取实体的查询：

SELECT * FROM test.speed_ulid where id = ?
SELECT * FROM test.speed_uuid where id = ?

测量结果

让我们来看看测量结果。请记住，每个表都有1,000,000行数据。

两种类型的标识符都以varchar形式存储在数据库中

我进行了几次测试，结果大致相同：ULID要么稍快，要么UUID稍快。从百分比来看，差异几乎为零。

好吧，你可能会不同意这两种类型之间没有差异。我会说，在数据库端使用其他数据类型是不可能的。

UUID作为数据库中的uuid，ULID作为varchar

对于下一个测试，我将test.speed_uuid 表中的数据类型从varchar(36)更改为uuid。

在这种情况下，差异是明显的：UUID比ULID快4.5%。

正如你所看到的，如果在服务端有相同名称的类型，那么在数据库端使用uuid数据类型是有意义的。这种格式的索引在PostgreSQL中经过了很好的优化，并显示出良好的结果。

好吧，现在我们可以明确地分道扬镳了。还是吗？

如果你查看索引搜索查询计划，你会看到在使用varchar时是这样的((id)::text = '01HEE5PD6HPWMBNF7ZZRF8CD9R'::text)。

总的来说，比较两个文本变量是一个相当慢的操作，所以也许没有必要以这种格式存储ID。或者是否有其他方法可以加快键的比较速度？首先，让我们为具有ULID的表创建另一个“hash”类型的索引。

create index speed_ulid_id_index
    on test.speed_ulid using hash (id);

让我们看看我们查询的执行计划：

我们将看到数据库在这种情况下使用了哈希索引，而不是btree。让我们运行我们的测试，看看会发生什么。

varchar + index(hash) for ULID, uuid for UUID

这种组合相对于uuid及其欺骗性索引增加了2.3%。

我不确定在一个字段上保留两个索引是否有道理。因此，值得考虑是否还有其他事情可以做。在这里，值得回顾一下过去，记得以前是如何存储uuid或其他字符串标识符的。没错：要么文本，要么字节数组。

所以让我们尝试这个选项：我删除了ULID的所有索引，将其转换为bytea，并重新创建了主键。

bytea for ULID, uuid for UUID

结果，我们得到了与上一次运行中额外索引的结果大致相同，但我个人更喜欢这个选项。

在数据库中有2,000,000行数据时的测量结果：

在数据库中有3,000,000行数据时的测量结果：

我认为没有继续进行更多的测量的必要。模式保持不变：以bytea格式保存的ULID在数据库中略优于以uuid格式保存的UUID。

如果我们从第一次测量中获取数据，显然，通过一些小的操作，你可以将性能提高约9%，如果使用varchar。

因此，如果你读到这里，我认为这篇文章对你来说是有趣的，你已经为自己得出了一些结论。

值得注意的是，测量是在后端部分和数据库端都处于理想状态下进行的。我们没有任何并行进程在数据库中写入数据，更改记录，或在后端进行复杂的计算。

结论

让我们回顾一下材料。你学到了什么有用的东西？

1. 不要忽视PostgreSQL端的uuid数据类型。也许有一天在这个数据库中会出现ULID的扩展，但目前我们只能使用现有的。
2. 有时手动创建所需类型的额外索引是值得的，但需要考虑开销。
3. 如果你不怕做一些不必要的工作 - 即编写自己的类型转换器 - 那么如果在数据库端没有相应的类型，你应该尝试bytea。

对于主键应该使用什么类型的数据，以及应该以什么格式存储，我没有明确的答案：这一切都取决于许多因素。值得注意的是，对于ID的数据类型的明智选择，在某个时刻可能会在你的项目中发挥重要作用。