OpenTeleDB 征文精選｜我用三個場景驗證了 OpenTeleDB XStore 的"零膨脹"到底是不是真的

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

廣東舉報

分享至

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

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

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

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

XStore 的核心原理

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

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

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

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

discard_worker_main: update globalRecycleXid: oldestXmin=202754...

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

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

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

項目

配置

操作系統(tǒng)

CentOS 7.9 x86_64

數(shù)據(jù)庫

OpenTeleDB v2.0 (PostgreSQL 17.6)

CPU

2 核

內(nèi)存

2GB

存儲

SSD 40GB

驗證啟動：

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

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

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

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

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

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

Heap 引擎壓測

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

pgbench-c100-j4-T60bench_heap

Heap 引擎結(jié)果：

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

XStore 引擎壓測

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

XStore 引擎結(jié)果：

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

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

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

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

指標(biāo)

Heap 引擎

XStore 引擎

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

167 MB

178 MB

死元組數(shù)量

37,502

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

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

pgbench 是標(biāo)準(zhǔn)化測試，接下來模擬一個更貼近實際業(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)

在真實業(yè)務(wù)中，訂單會經(jīng)歷 pending → paid → shipped → delivered → completed 的狀態(tài)變更。用一個循環(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 ，翻了一倍。這個增長主要來自 updated_at 時間戳字段的變化，以及 XStore 引擎內(nèi)部的空間管理開銷。

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

場景三：審計日志高頻寫入

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

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

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 萬條記錄，模擬一周的審計數(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 萬條記錄后：

表大小：107 MB → 123 MB
死元組：仍為 0

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

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

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

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

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

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

維度

Heap 引擎

XStore 引擎

單次寫入性能

較高（追加寫）

略低（原地更新 + Undo）

死元組

會累積，需 VACUUM

始終為 0

表膨脹

嚴重（不及時清理會翻倍）

無膨脹

維護成本

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

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

適用場景

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

高頻更新、長期運行

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

我的體驗總結(jié)

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

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

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

技術(shù)選型沒有銀彈，關(guān)鍵是理解自己的業(yè)務(wù)特點。這次體驗讓我對 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 機制解析：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.