如何在PostgreSQL正确的 使用UUID 作为主键
UUID 经常用作数据库表主键。它们易于生成,易于在分布式系统之间共享并保证唯一性。
考虑到 UUID 的大小,这是否是一个正确的选择值得怀疑,但通常这不是由我们决定的。
本文的重点不是“UUID 是否是主键的正确格式”,而是如何有效地使用 UUID 作为 PostgreSQL 的主键。
Postgres 数据的UUID类型
UUID 可以被视为一个字符串,并且可能很容易将它们存储为字符串。 Postgres 具有用于存储字符串的灵活数据类型: text
,并且通常用作存储 UUID 值的主键。
它是正确的数据类型吗?当然不是。
Postgres 有一个专用于 UUID 的数据类型: uuid
。 UUID 是 128 位数据类型,因此存储单个值需要 16 个字节。 text
数据类型有 1 或 4 个字节的开销加上存储实际的字符串。
这些差异在小表中并不那么重要,但一旦开始存储数十万或数百万行,就会成为问题。
我进行了一个实验,看看实践中有何不同。有两个表只有一列 - id
作为主键。第一个表使用 text
,第二个表使用 uuid
:
create table bank_transfer(id text primary key
);create table bank_transfer_uuid(id uuid primary key
);
我没有指定主键索引的类型,因此 Postgres 使用默认的 B 树。
然后我使用 Spring 的 JdbcTemplate
中的 batchUpdate
向每个表插入 10 000 000
行:
jdbcTemplate.batchUpdate("insert into bank_transfer (id) values (?)",new BatchPreparedStatementSetter() {@Overridepublic void setValues(PreparedStatement ps, int i) throws SQLException {ps.setString(1, UUID.randomUUID().toString());}@Overridepublic int getBatchSize() {return 10_000_000;}
});
jdbcTemplate.batchUpdate("insert into bank_transfer_uuid (id) values (?)",new BatchPreparedStatementSetter() {@Overridepublic void setValues(PreparedStatement ps, int i) throws SQLException {ps.setObject(1, UUID.randomUUID());}@Overridepublic int getBatchSize() {return 10_000_000;}});
查询表大小和索引大小:
select relname as "table", indexrelname as "index",pg_size_pretty(pg_relation_size(relid)) "table size",pg_size_pretty(pg_relation_size(indexrelid)) "index size"
from pg_stat_all_indexes
where relname not like 'pg%';
+------------------+-----------------------+----------+----------+
|table |index |table size|index size|
+------------------+-----------------------+----------+----------+
|bank_transfer_uuid|bank_transfer_uuid_pkey|422 MB |394 MB |
|bank_transfer |bank_transfer_pkey |651 MB |730 MB |
+------------------+-----------------------+----------+----------+
使用 text
的表增大了 54%,索引大小增大了 85%。这也反映在 Postgres 用于存储这些表和索引的页数上:
select relname, relpages from pg_class
where relname like 'bank_transfer%';
+-----------------------+--------+
|relname |relpages|
+-----------------------+--------+
|bank_transfer |83334 |
|bank_transfer_pkey |85498 |
|bank_transfer_uuid |54055 |
|bank_transfer_uuid_pkey|50463 |
+-----------------------+--------+
更大的表、索引和更多的表意味着 Postgres 必须执行插入新行和获取行的工作 - 特别是当索引大小大于可用 RAM 内存时,Postgres 必须从磁盘加载索引。
UUID 和 B 树索引
随机 UUID 不太适合 B 树索引 - 并且 B 树索引是主键唯一可用的索引类型。
B 树索引最适合处理有序值 - 例如自动递增列或时间排序列。
UUID - 尽管看起来总是相似 - 有多种变体。 Java 的 UUID.randomUUID()
- 返回 UUID v4 - 这是一个伪随机值。对我们来说,更有趣的是 UUID v7 - 它生成按时间排序的值。这意味着每生成一个新的UUID v7,它就有一个更大的值。这使得它非常适合 B 树索引。
要在 Java 中使用 UUID v7,我们需要一个第三方库,例如 java-uuid-generator:
<dependency><groupId>com.fasterxml.uuid</groupId><artifactId>java-uuid-generator</artifactId><version>5.0.0</version>
</dependency>
然后我们可以使用以下命令生成 UUID v7:
UUID uuid = Generators.timeBasedEpochGenerator().generate();
// 多次运行结果, 字符串长度为36
0190a48c-2ee3-7c50-b45c-d51fecb36a9a
0190a48c-8fce-7fd3-b141-1fb312f9096e
0190a48c-f36b-707d-9826-644fe72b7e02
0190a48d-e236-76b5-a03c-54f09fa27e9c
理论上,这应该可以提高执行 INSERT
语句的性能。
UUID v7 如何影响 INSERT 性能
我创建了另一个表,与 bank_transfer_uuid
完全相同,但它将仅存储使用上述库生成的 UUID v7:
create table bank_transfer_uuid_v7(id uuid primary key
);
然后,我运行 10
轮,向每个表插入 10000
行,并测量需要多长时间:
for (int i = 1; i <= 10; i++) {measure(() -> IntStream.rangeClosed(0, 10000).forEach(it -> {jdbcClient.sql("insert into bank_transfer (id) values (:id)").param("id", UUID.randomUUID().toString()).update();}));measure(() -> IntStream.rangeClosed(0, 10000).forEach(it -> {jdbcClient.sql("insert into bank_transfer_uuid (id) values (:id)").param("id", UUID.randomUUID()).update();}));measure(() -> IntStream.rangeClosed(0, 10000).forEach(it -> {jdbcClient.sql("insert into bank_transfer_uuid_v7 (id) values (:id)").param("id", Generators.timeBasedEpochGenerator().generate()).update();}));
}
结果看起来有点随机,在与常规 text
列和 uuid
v4 的表的时间比较时:
+-------+-------+---------+
| text | uuid | uuid v7 |
+-------+-------+---------+
| 7428 | 8584 | 3398 |
| 5611 | 4966 | 3654 |
| 13849 | 10398 | 3771 |
| 6585 | 7624 | 3679 |
| 6131 | 5142 | 3861 |
| 6199 | 10336 | 3722 |
| 6764 | 6039 | 3644 |
| 9053 | 5515 | 3621 |
| 6134 | 5367 | 3706 |
| 11058 | 5551 | 3850 |
+-------+-------+---------+
但我们可以清楚地看到,插入 UUID v7 比插入常规 UUID v4 快约 2 倍。
Further reading 进一步阅读
- UUID v7 will likely be supported natively in Postgres 17
Postgres 17 可能会原生支持 UUID v7 - UUID Version 7 format
UUID 版本 7 格式 - UUIDs are Popular, but Bad for Performance
UUID 很流行,但对性能不利 - https://vladmihalcea.com/uuid-database-primary-key/
概括
正如一开始提到的 - 由于 UUID 长度 - 即使进行了所有这些优化,它也不是主键的最佳类型。如果您可以选择,请查看由 Vlad Mihalcea 维护的 TSID。
但如果您必须或出于某种原因想要使用 UUID,请考虑我提到的优化。另请记住,此类优化对于大型数据集会产生影响。如果您存储数百甚至数千行,并且访问量较低,您可能不会看到应用程序性能有任何差异。但是,如果您有可能拥有大型数据集或大访问量 - 最好从一开始就这样做,因为更改主键可能是一个相当大的挑战。
Maciej Walkowiak | PostgreSQL and UUID as primary key