OpenTeleDB从 Heap 到 XStore：高更新场景下的存储引擎实验报告
引言
在现代 OLTP 系统中，高频写入和更新操作是常态，这对存储引擎的性能、空间管理和索引维护提出了巨大挑战。传统 Heap 表在持续更新下容易产生空间膨胀，导致 VACUUM 频繁、查询性能波动。OpenTeleDB 的 XStore 提供了原位更新和 Undo 日志机制，为高频写入场景提供了另一种解决方案。本次实验，我将通过完整的操练代码，展示 XStore 在高频更新下的空间、索引和查询表现，并与 Heap 表做直观对比。OpenTeleDB部署十分简单。本篇文章不展示部署过程，直接针对核心操练。
一、我的目标
实验目标是通过对比 Heap 表和 XStore 表在高频写入场景下的表现，评估两者在空间膨胀、查询性能和索引压力上的差异，验证 XStore 的原位更新机制在控制表空间增长和维持查询效率方面的效果，并总结在高频更新场景下选择存储引擎的策略。实验环境基于 PostgreSQL 兼容的 OpenTeleDB，已启用 XStore 存储引擎。
二、操练步骤与代码
创建表结构
-- XStore 表 CREATE TABLE xstore_demo ( id SERIAL PRIMARY KEY, name TEXT, value INT, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) USING XSTORE; -- Heap 表 CREATE TABLE heap_demo ( id SERIAL PRIMARY KEY, name TEXT, value INT, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );两张表结构一致，便于对比高频更新的行为。
批量插入初始数据
-- 插入 500 万条记录 INSERT INTO xstore_demo (name, value) SELECT 'item_' || g, g FROM generate_series(1, 5000000) AS g; INSERT INTO heap_demo (name, value) SELECT 'item_' || g, g FROM generate_series(1, 5000000) AS g;此操作完成后，表的初始空间可通过以下命令查看：
-- 查看表空间 SELECT 'heap_demo' AS table_name, pg_size_pretty(pg_total_relation_size('heap_demo')) AS total_size; SELECT 'xstore_demo' AS table_name, pg_size_pretty(pg_total_relation_size('xstore_demo')) AS total_size;table_name | total_size ------------+------------ heap_demo | 394 MB (1 row) table_name | total_size -------------+------------ xstore_demo | 492 MB (1 row)高频更新操练
为了模拟 OLTP 高频写入场景，我们执行多轮全表更新操作：
-- 更新函数 DO $$ DECLARE i INT; BEGIN FOR i IN 1..5 LOOP UPDATE xstore_demo SET value = value + 1, updated_at = CURRENT_TIMESTAMP; UPDATE heap_demo SET value = value + 1, updated_at = CURRENT_TIMESTAMP; END LOOP; END $$;每轮更新均增加数值并更新时间戳，相当于持续的写入和修改负载。
结果如下
table_name | total_size ------------+------------ heap_demo | 2153 MB (1 row) table_name | total_size -------------+------------ xstore_demo | 492 MB (1 row)查询性能测试
为了验证在高频更新后查询性能的稳定性，我们进行循环随机查询：
-- XStore 随机查询测试 DO $$ DECLARE t_start TIMESTAMP; t_end TIMESTAMP; BEGIN t_start := clock_timestamp(); FOR i IN 1..50 LOOP PERFORM * FROM xstore_demo ORDER BY random() LIMIT 1000; END LOOP; t_end := clock_timestamp(); RAISE NOTICE 'XStore 查询耗时: %', t_end - t_start; END $$; -- Heap 随机查询测试 DO $$ DECLARE t_start TIMESTAMP; t_end TIMESTAMP; BEGIN t_start := clock_timestamp(); FOR i IN 1..50 LOOP PERFORM * FROM heap_demo ORDER BY random() LIMIT 1000; END LOOP; t_end := clock_timestamp(); RAISE NOTICE 'Heap 查询耗时: %', t_end - t_start; END $$;通过上述操练，我们可以直接观测 XStore 与 Heap 在高频更新和随机查询下的表现差异。
XStore 查询耗时: 00:03:14.027135
Heap 查询耗时: 00:07:00.539208
三、实验观察与分析
通过 500 万行数据、5 轮全表更新、50 轮随机查询的对比测试，可以非常直观地看到XStore 与 PostgreSQL Heap 在高频更新场景下的行为差异。这种差异不是“参数调优”层面的，而是存储引擎语义层面的根本不同。
3.1 表空间膨胀对比：MVCC vs 原位更新
| 表类型 | 初始空间 | 5 轮更新后空间 | 膨胀倍数 |
|---|---|---|---|
| Heap | 394 MB | 2153 MB | ≈ 5.46x |
| XStore | 492 MB | 492 MB | ≈ 1.0x |
可以看到：
- Heap 表在 5 轮全表 UPDATE 后，体积从394MB 膨胀到 2.1GB
- XStore 表几乎完全不膨胀
这并不是偶然，而是 PostgreSQL 传统 MVCC 机制的必然结果。
Heap 表为什么会膨胀？
PostgreSQL 的 Heap 表在执行 UPDATE 时，并不会覆盖原行，而是：
- 标记旧行
dead tuple - 在新位置写入一条新版本
- 通过事务可见性判断来选择版本
因此，每一轮全表更新，都会：
- 复制 500 万条新版本
- 留下 500 万条 dead tuple
- 索引同样被多次重写
而在没有VACUUM FULL的情况下：
这些 dead tuple 会一直占用磁盘空间和缓存页。
XStore 的行为完全不同
XStore 使用的是原位更新（In-Place Update）+ Undo 日志：
- 数据页直接覆盖
- 旧版本写入 Undo 链
- 不产生大量无效版本
因此：
XStore 的写放大极低，磁盘空间几乎稳定。
3.2 随机查询性能对比：碎片化是隐形杀手
| 表类型 | 50 轮随机查询耗时 |
|---|---|
| XStore | 3分14秒 |
| Heap | 7分00秒 |
Heap 的查询耗时几乎是 XStore 的2.1 倍。
这背后并不是 SQL 执行计划的差异，而是物理页结构已经被更新破坏。
Heap 表在高频更新后发生了什么？
- 表页中混杂大量 dead tuple
- 实际可见行分散在多个块
- 缓存命中率下降
- 每次随机扫描需要更多 page IO
即使你看到的是同一条数据：
SELECT * FROM heap_demo ORDER BY random() LIMIT 1000;实际上 PostgreSQL 需要：
- 扫描更多块
- 跳过大量无效版本
- 做更多可见性判断
而这些都不会体现在EXPLAIN中。
XStore 的优势
XStore 的数据页结构是“紧凑态”：
- 没有版本碎片
- 没有 dead tuple
- 页密度稳定
因此随机访问时：
每次扫描命中的数据更集中，CPU Cache 和 Page Cache 命中率更高。
3.3 写放大与 IO 行为对比
| 维度 | Heap | XStore |
|---|---|---|
| UPDATE 写入 | 新行 + 索引 + WAL | 数据页 + Undo |
| 版本增长 | 每轮翻倍 | 固定 |
| VACUUM 依赖 | 强 | 弱 |
| IO 放大 | 高 | 低 |
| 查询稳定性 | 下降明显 | 几乎不变 |
在 Heap 上：
- UPDATE ≈ INSERT + DELETE
- 索引反复膨胀
- 必须依赖 VACUUM、FREEZE、REINDEX 才能回收
在 XStore 上：
- UPDATE ≈ 页内修改
- 无历史垃圾堆积
- 存储状态长期稳定
3.4 这组实验说明了什么？
这不是“XStore 比 PG 快一点”的问题，而是：
XStore 改变的是 PostgreSQL 在高频更新场景下的物理演化路径。
Heap：
- 每次写都在制造未来的技术债
- 依赖后台维护任务“补救”
XStore：
- 在设计层面避免版本爆炸
- 将“垃圾回收”从存储结构中消除
3.5 适用场景总结
结论一句话：
Heap 是为“版本正确性”而生， XStore 是为“写入可持续性”而生。
这组实验只是一个最小复现，但它已经足够说明：在高频更新场景下，存储引擎的物理语义，比 SQL 优化更重要。
四、总结
这次完整跑完 XStore 与 Heap 的高频更新对比实验，我最大的感受是：数据库的“慢”，往往不是 SQL 写错了，而是存储引擎在默默付利息。过去我也习惯通过加索引、调参数、扩内存来掩盖性能问题，但这次实验让我直观地看到，Heap 在每一次 UPDATE 时，其实都在为未来制造碎片和负担，而 XStore 从设计层面就把这种“结构性内耗”消掉了。对我来说，这不仅是一次性能对比，更是一次对数据库底层认知的刷新：真正决定系统上限的，不是查询写得多漂亮，而是引擎是否能在长期写入压力下保持“结构不劣化”。这也是我开始认真看待“新一代内核”价值的原因。