当前位置：首页 > news >正文

我花了一天时间，拆了一下 OpenTeleDB 的 XStore，到底解决了 PG 的哪根老筋？

news 2026/5/12 2:51:06

这两年数据库圈有点像3年前的云原生圈：“分布式”、“新一代内核”、“重构存储引擎”这些词突然又密集起来了。

前几天刷群，看到有人转了 OpenTeleDB 的开源消息，说是“基于 PostgreSQL 的新一代内核”。说实话，我第一反应是：又一个魔改 PG？

但看到里面提到一个点：原位更新 + Undo 引擎（XStore），我还是没忍住下了源码。因为这恰好戳中我这些年被 PG 折磨得最狠的痛点：

表膨胀、autovacuum 抽风、性能像心电图一样忽高忽低。

所以这次我没看 PPT，也没看宣传稿，直接跑到机器上拆了半天，想看看它究竟动了 PG 的哪根“老筋”。

一、先说结论：XStore 不是快，而是“稳”

我装的是 OpenTeleDB 的 17.6 内核版。创建方式很直观：

SELECT relname, amname FROM pg_class c JOIN pg_am a ON c.relam = a.oid WHERE relname = 'test_xstore';

这一步其实就已经很有意思了——它不是 fork 了一套新引擎，而是作为插件挂进去的。这个思路我很认可：

不绑死 PG 版本
能跟着大版本升级
出问题可以随时回退

像 Citus、openHalo 这些“成功插件化路线”的项目，本质都是这个思路。

二、打开数据目录，我第一次意识到：它真不是换皮

在$PGDATA下面，多了一个非常显眼的目录：

drwx------ 2 postgres postgres 4096 Nov 3 20:15 undo

这就是 XStore 的核心：它不是靠多版本链来维护 MVCC，而是靠 Undo 日志回滚。

这点和 Oracle、MySQL InnoDB 的逻辑更像。

也正是它敢说“原位更新”的底气来源。

三、插入测试：它不快，但很“诚实”

我用同样的参数，在同一台机器上跑了两组：

INSERT INTO test_xstore (name, value) SELECT md5(random()::text), (random()*1000)::int FROM generate_series(1,10000000);

INSERT INTO test_heap (name, value) SELECT md5(random()::text), (random()*1000)::int FROM generate_series(1,10000000);

结果是：

写慢了将近一倍。这点我反而觉得真实：因为 XStore 在写数据页的同时，还要写一份 Undo。物理写入翻倍，吞吐下降是必然的。如果一个系统告诉你“原位更新 + Undo 还更快”，那我反而会不太信。

四、创新实验：模拟1千万数据的存储膨胀对比

我设计了一项创新实验：在 1000 万条级别的大数据量下，评估 XStore 与 Heap 表在高频更新下的空间膨胀、索引稳定性以及查询性能表现。该实验主要有两个创新点：

大规模数据模拟

使用generate_series(1,10000000)生成 1000 万条数据，保证数据量级对存储膨胀影响明显。
初始数据包括id、name、value和updated_at四列，与前期实验一致，但数据量增加十倍，以模拟真实大规模 OLTP 系统负载。

多维度空间分析

不仅监控表总大小，还分别统计索引占用和 TOAST 表空间。
每轮更新后，通过pg_relation_size、pg_total_relation_size和pg_indexes_size获取精细化指标。
引入可视化趋势分析，绘制表空间增长曲线，以直观展示 XStore 与 Heap 的差异。

4.1实验设计

表结构

CREATE TABLE xstore_large ( id SERIAL PRIMARY KEY, name TEXT, value INT, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) USING XSTORE; CREATE TABLE heap_large ( id SERIAL PRIMARY KEY, name TEXT, value INT, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

初始化 1000 万条数据

INSERT INTO xstore_large (name, value) SELECT 'name_' || g, g FROM generate_series(1, 10000000) AS g; INSERT INTO heap_large (name, value) SELECT 'name_' || g, g FROM generate_series(1, 10000000) AS g;

先对现在存入1000w数据的空间监控与记录一下如下。

xstore_total | xstore_index | heap_total | heap_index --------------+--------------+------------+------------ 985 MB | 388 MB | 789 MB | 214 MB

多轮全表更新

连续 5 轮更新，每轮更新value和updated_at，模拟写入密集场景：

UPDATE xstore_large SET value = value + 1, updated_at = CURRENT_TIMESTAMP; UPDATE heap_large SET value = value + 1, updated_at = CURRENT_TIMESTAMP;

空间监控与记录

SELECT pg_size_pretty(pg_total_relation_size('xstore_large')) AS xstore_total, pg_size_pretty(pg_indexes_size('xstore_large')) AS xstore_index, pg_size_pretty(pg_total_relation_size('heap_large')) AS heap_total, pg_size_pretty(pg_indexes_size('heap_large')) AS heap_index;

第一轮：

xstore_total | xstore_index | heap_total | heap_index --------------+--------------+------------+------------ 985 MB | 388 MB | 1578 MB | 428 MB

第五轮：

xstore_total | xstore_index | heap_total | heap_index --------------+--------------+------------+------------ 985 MB | 388 MB | 1628 MB | 428 MB

4.2千万数据更新膨胀可视化

五、实验结论

这组 1000 万级数据 + 多轮全表更新的实验，其实把 PG 传统 Heap 表的“老问题”放大得非常清楚。

最核心的对比结果只有一句话：

XStore 的空间是线性的、可预测的；Heap 表的空间是失控的、不可预测的。

具体来看：
1. 表空间膨胀
a. Heap 表在第一次更新后，表体空间直接翻倍，从 789MB 飙到 1578MB。
b. 之后每一轮更新，虽然增长幅度趋缓，但空间再也回不到初始状态。
c. XStore 从头到尾不变： 985MB → 985MB → 985MB
2. 索引体积稳定性
a. Heap 表索引从 214MB 膨胀到 428MB，且在后续更新中保持“高位横盘”。
b. XStore 的索引尺寸始终维持在 388MB 左右，没有明显漂移。
3. 更新行为本质差异
a. Heap：每一次 UPDATE，本质都是 DELETE + INSERT → 老版本残留 → 表膨胀 → 索引碎片 → autovacuum 压力。
b. XStore：真正的原位更新 → 历史版本进 Undo → 主表物理页不变 → 无膨胀。
4. 长期可运维性
a. 在 Heap 表上，如果你不 VACUUM，它一定会慢；如果你 VACUUM，系统一定会抖。
b. 在 XStore 上，这两件事都不再是必选项。
这意味着什么？

它不是让你飞起来，而是让你不再塌方。