在Postgres数据库中ULID和UUID的性能比较

大家好！在这篇文章中，我想分享一下我对通常作为标识符使用的数据类型的知识和看法。今天我们将同时涉及两个主题。这些是关键字搜索速度的测量和数据库端关键字的数据类型。

我将使用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 count: 16
• # RAM: 32GB
• # JMH version: 1.37
• # VM version: JDK 11.0.12, Java HotSpot(TM) 64-Bit Server VM, 11.0.12+8-LTS-237
• # DB: PostgreSQL 13.4, build 1914, 64-bit

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

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占优势，为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) 用于ULID，uuid 用于UUID

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

我不确定在一个字段上保留两个索引是否能够有所证明。因此值得考虑是否还有其他事项可操作。在这种情况下，值得回顾过去，并记住uuid或其他一些字符串标识符是如何存储的。没错：要么是文本，要么是字节数组。

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

bytea for ULID, uuid for UUID

结果，我们得到了与前次测试中额外添加索引的结果大致相同，但我个人更喜欢这个选项。

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

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

我认为继续测量下去是没有意义的。规律依然存在：作为bytea保存的ULID在数据库中稍微优于作为uuid保存的UUID。

如果我们从第一轮测量中取得数据，显而易见的是，通过一些小的操纵，您可以通过varchar提高约9%的性能。

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

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

结论

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

1. 在 PostgreSQL 中不要忽视 uuid 数据类型。也许将来这个数据库会出现 ULID 的扩展，但现在我们所拥有的就是这些。
2. 有时候值得手动创建所需类型的额外索引，但需要考虑开销。
3. 如果你不怕做一些额外的工作，比如为类型编写自己的转换器，那么在数据库端没有对应类型的情况下，你应该尝试使用 bytea。

用于主键的数据类型以及存储格式应该选择什么样的呢？对于这些问题我没有明确的答案：一切都取决于很多因素。值得注意的是，对于 ID 及其他数据类型的明智选择，在某些时候可能会成为你项目中重要的一环。

希望本文对你有所帮助。祝好运！

• GitHub 上的项目