OpenTeleDB 征文精選｜我用三個(gè)場景驗(yàn)證了 OpenTeleDB XStore 的"零膨脹"到底是不是真的

2026-03-16 16:16:03　來源: 開源中國

廣東舉報(bào)

分享至

OpenTeleDB 數(shù)據(jù)庫線上征文活動優(yōu)秀作品來襲！本篇為精選文章，分享實(shí)戰(zhàn)經(jīng)驗(yàn)與技術(shù)感悟，敬請閱讀。

用過 PostgreSQL 的人都知道，MVCC 機(jī)制帶來了優(yōu)秀的并發(fā)性能，但也埋下了一個(gè) "定時(shí)炸彈"——表膨脹。每次 UPDATE 操作都會產(chǎn)生一條新版本記錄，舊記錄成為 "死元組"（dead tuples），只能等 VACUUM 來清理。

在我維護(hù)的一個(gè)審計(jì)日志系統(tǒng)中，每天寫入幾十萬條記錄，偶爾還有批量更新操作。運(yùn)行一段時(shí)間后，表從最初的 100MB 膨脹到 2GB，查詢性能直線下降。定期跑 VACUUM FULL 雖然能解決問題，但會鎖表，在業(yè)務(wù)高峰期根本不敢執(zhí)行。

最近看到 OpenTeleDB 開源了，它的 XStore 引擎號稱 "原地更新、零膨脹"，我第一反應(yīng)是：又是營銷話術(shù)？抱著懷疑的態(tài)度，我決定親自驗(yàn)證一下。

XStore 的核心原理

XStore 與傳統(tǒng) Heap 引擎的本質(zhì)區(qū)別在于數(shù)據(jù)更新方式：

Heap 引擎（PostgreSQL 默認(rèn)）：UPDATE 時(shí)創(chuàng)建新版本，標(biāo)記舊版本為死元組，依賴 VACUUM 回收空間。這種 "追加寫" 模式在高頻更新場景下會導(dǎo)致表體積快速膨脹。

XStore 引擎：采用 "原地更新" 策略，配合獨(dú)立的 Undo Log 管理舊版本數(shù)據(jù)。更新操作直接修改原記錄位置，舊數(shù)據(jù)寫入 Undo 空間，由后臺的 discard_worker 進(jìn)程自動回收。表本身不會產(chǎn)生死元組，也就不需要 VACUUM。

從日志中可以看到 XStore 的 Undo 回收機(jī)制在持續(xù)工作：

discard_worker_main: update globalRecycleXid: oldestXmin=202754...

這意味著 Undo 空間會隨著事務(wù)推進(jìn)自動清理，不需要人工干預(yù)。

測試環(huán)境與準(zhǔn)備

本次測試在一臺云服務(wù)器上進(jìn)行，配置如下：

項(xiàng)目

配置

操作系統(tǒng)

CentOS 7.9 x86_64

數(shù)據(jù)庫

OpenTeleDB v2.0 (PostgreSQL 17.6)

CPU

2 核

內(nèi)存

2GB

存儲

SSD 40GB

驗(yàn)證啟動：

XStore 引擎在 OpenTeleDB 中以擴(kuò)展形式提供，啟用方式很簡單：

CREATE EXTENSION xstore;
ALTERDATABASE bench_xstore SET default_table_access_method = 'xstore';

執(zhí)行后，該數(shù)據(jù)庫中新建的表會默認(rèn)使用 XStore 引擎。

上圖展示了在 bench_xstore 數(shù)據(jù)庫中啟用 XStore 擴(kuò)展，并用 pgbench -i -s 10 初始化測試表的過程。整個(gè)初始化在 4.20 秒內(nèi)完成。

場景一：pgbench 標(biāo)準(zhǔn)壓測對比

pgbench 是 PostgreSQL 自帶的基準(zhǔn)測試工具，模擬 TPC-B 類型的事務(wù)負(fù)載，包含大量的 UPDATE 操作，非常適合測試存儲引擎在高頻更新場景下的表現(xiàn)。

Heap 引擎壓測

對 bench_heap 數(shù)據(jù)庫執(zhí)行 100 并發(fā)、60 秒壓測：

pgbench-c100-j4-T60bench_heap

Heap 引擎結(jié)果：

TPS：1819.97（不含連接建立時(shí)間）
平均延遲：54.946 ms
事務(wù)總數(shù)：109,291
失敗事務(wù)：0

XStore 引擎壓測

同樣的壓測參數(shù)應(yīng)用于 bench_xstore 數(shù)據(jù)庫：

XStore 引擎結(jié)果：

TPS：1544.53（不含連接建立時(shí)間）
平均延遲：64.745 ms
事務(wù)總數(shù)：92,622
失敗事務(wù)：0

從吞吐量看，XStore 比 Heap 低約 15%。這符合預(yù)期 ------ 原地更新需要額外維護(hù) Undo Log，單次寫入開銷略高。但 XStore 的優(yōu)勢不在瞬時(shí)性能，而在長期運(yùn)行的穩(wěn)定性。

關(guān)鍵差異：死元組統(tǒng)計(jì)

壓測結(jié)束后，對比兩個(gè)數(shù)據(jù)庫的空間占用和死元組情況：

指標(biāo)

Heap 引擎

XStore 引擎

數(shù)據(jù)庫大小

167 MB

178 MB

死元組數(shù)量

37,502

這就是核心差異。Heap 引擎積累了 37,502 個(gè)死元組，如果不及時(shí) VACUUM，這些 "垃圾" 會持續(xù)累積，表體積不斷膨脹。而 XStore 的死元組始終為 0，Undo 空間由 discard_worker 自動回收。

場景二：業(yè)務(wù)訂單表高頻更新

pgbench 是標(biāo)準(zhǔn)化測試，接下來模擬一個(gè)更貼近實(shí)際業(yè)務(wù)的場景：訂單狀態(tài)流轉(zhuǎn)。

創(chuàng)建訂單表

使用 XStore 引擎創(chuàng)建一張訂單表，插入 10 萬條測試數(shù)據(jù)：

CREATETABLE orders (
    order_id BIGSERIAL PRIMARY KEY,
    user_id INTNOTNULL,
    product_id INTNOTNULL,
    quantity INTDEFAULT1,
statusVARCHAR(20) DEFAULT'pending',
    total_amount DECIMAL(10,2),
    created_at TIMESTAMPDEFAULTNOW(),
    updated_at TIMESTAMPDEFAULTNOW()
) USING xstore;

 CREATEINDEX idx_orders_user ON orders(user_id);
CREATEINDEX idx_orders_status ON orders(status);

 INSERTINTO orders (user_id, product_id, quantity, total_amount)
SELECT
    (random() * 10000)::int,
    (random() * 1000)::int,
    (random() * 5 + 1)::int,
    (random() * 1000)::decimal(10,2)
FROM generate_series(1, 100000);

初始空間占用

數(shù)據(jù)插入后，查看表的初始大?。?/p>

初始大小為 8,272 KB（約 8MB）。

模擬訂單狀態(tài)流轉(zhuǎn)

在真實(shí)業(yè)務(wù)中，訂單會經(jīng)歷 pending → paid → shipped → delivered → completed 的狀態(tài)變更。用一個(gè)循環(huán)模擬 5 輪全表更新：

DO $$
DECLARE
    i INT;
BEGIN
FOR i IN1..5LOOP
UPDATE orders SET
status = CASE
WHENstatus = 'pending'THEN'paid'
WHENstatus = 'paid'THEN'shipped'
WHENstatus = 'shipped'THEN'delivered'
WHENstatus = 'delivered'THEN'completed'
ELSEstatus
END,
            updated_at = NOW();
        RAISE NOTICE 'Round % completed', i;
ENDLOOP;
END $$;

5 輪更新意味著 10 萬行 × 5 次 = 50 萬次 UPDATE 操作。

更新完成后，表大小從 8MB 增長到 16MB ，翻了一倍。這個(gè)增長主要來自 updated_at 時(shí)間戳字段的變化，以及 XStore 引擎內(nèi)部的空間管理開銷。

值得注意的是，圖中顯示死元組為 97,829。這是因?yàn)?pg_stat_user_tables 的統(tǒng)計(jì)信息存在延遲，XStore 的 discard_worker 正在后臺回收這些 Undo 記錄。等待片刻后重新查詢，死元組會降為 0。

場景三：審計(jì)日志高頻寫入

審計(jì)日志是典型的 "只增不刪、偶爾更新" 場景，數(shù)據(jù)量大，更新頻繁，最容易出現(xiàn)表膨脹問題。

創(chuàng)建審計(jì)日志表

CREATETABLE audit_log (
id BIGSERIAL PRIMARY KEY,
    table_name VARCHAR(50),
    operation VARCHAR(10),
    old_data JSONB,
    new_data JSONB,
    user_id INT,
    ip_address INET,
    created_at TIMESTAMPDEFAULTNOW()
) USING xstore;


 CREATEINDEX idx_audit_created ON audit_log(created_at);
CREATEINDEX idx_audit_table ON audit_log(table_name);

模擬 7 天數(shù)據(jù)寫入

每天寫入 10 萬條記錄，模擬一周的審計(jì)數(shù)據(jù)：

7 天共插入 70 萬條記錄。

查看表空間

指標(biāo)

數(shù)值

表大小

107 MB

索引大小

27 MB

活躍行數(shù)

700,000

死元組

70 萬條 JSONB 數(shù)據(jù)，表大小 107MB，死元組為 0。

模擬批量更新

假設(shè)需要對前 10 萬條記錄做一次數(shù)據(jù)訂正：

UPDATE audit_log
SET new_data = new_data || '{"corrected": true}'::jsonb
WHEREid <= 100000;

更新 10 萬條記錄后：

表大?。?07 MB → 123 MB
死元組：仍為 0

空間增長了 16MB，這是 JSONB 字段追加新鍵值對導(dǎo)致的數(shù)據(jù)本身變大，而不是死元組膨脹。如果用傳統(tǒng) Heap 引擎執(zhí)行同樣的操作，會產(chǎn)生 10 萬個(gè)死元組，表體積可能翻倍。

日志中可以看到 discard_worker 持續(xù)在工作：

discard_worker_main: update globalRecycleXid: oldestXmin=202754...loops=1382

loops=1382 表示 Undo 回收循環(huán)已經(jīng)執(zhí)行了 1382 次，系統(tǒng)在自動維護(hù)存儲空間。

性能與空間的權(quán)衡

通過三個(gè)場景的測試，可以總結(jié)出 XStore 與 Heap 的特性對比：

維度

Heap 引擎

XStore 引擎

單次寫入性能

較高（追加寫）

略低（原地更新 + Undo）

死元組

會累積，需 VACUUM

始終為 0

表膨脹

嚴(yán)重（不及時(shí)清理會翻倍）

無膨脹

維護(hù)成本

需要調(diào)優(yōu) VACUUM 參數(shù)

自動回收，無需干預(yù)

適用場景

讀多寫少、批量導(dǎo)入

高頻更新、長期運(yùn)行

XStore 的 TPS 比 Heap 低 15% 左右，但換來的是零運(yùn)維成本和穩(wěn)定的存儲空間。對于審計(jì)日志、訂單系統(tǒng)、IoT 數(shù)據(jù)采集這類高頻寫入場景，XStore 的長期收益遠(yuǎn)超過那點(diǎn)性能差距。

我的體驗(yàn)總結(jié)

說實(shí)話，測試之前我對 "零膨脹" 這個(gè)宣傳是半信半疑的。但跑完三個(gè)場景后，我確實(shí)服了 ------70 萬條審計(jì)記錄 + 10 萬次更新，死元組始終是 0，這在傳統(tǒng) Heap 引擎上根本不可能。

讓我印象最深的是 discard_worker 這個(gè)后臺進(jìn)程。以前用 PostgreSQL，我得時(shí)刻盯著 pg_stat_user_tables 的死元組數(shù)量，一旦超過閾值就得手動跑 VACUUM?，F(xiàn)在 XStore 把這事全自動化了，我甚至不用關(guān)心 Undo 空間 ------ 它自己會清理。

當(dāng)然，XStore 也有它的代價(jià) ------ 從測試數(shù)據(jù)看，它的 TPS 比 Heap 低 15% 左右。但這點(diǎn)性能差距換來的是零膨脹和零運(yùn)維，對于高頻更新、長周期運(yùn)行的業(yè)務(wù)來說，絕對劃算。如果你像我一樣被 VACUUM 調(diào)優(yōu)折騰過，XStore 真的值得一試。

技術(shù)選型沒有銀彈，關(guān)鍵是理解自己的業(yè)務(wù)特點(diǎn)。這次體驗(yàn)讓我對 OpenTeleDB 有了更多期待，后續(xù)我打算再測試一下它的 XProxy 高并發(fā)連接能力。

參考資料

OpenTeleDB 社區(qū)：https://openteledb.cn/
OpenTeleDB Gitee 倉庫：https://gitee.com/teledb/openteledb
PostgreSQL 官方文檔 - Table Access Method：https://www.postgresql.org/docs/17/tableam.html
MVCC 與 Vacuum 機(jī)制解析：https://www.postgresql.org/docs/17/routine-vacuuming.html

作者：一只牛博

特別聲明：以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺“網(wǎng)易號”用戶上傳并發(fā)布，本平臺僅提供信息存儲服務(wù)。

Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.