網易首頁 > 網易號 > 正文申請入駐

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

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

廣東舉報

分享至

OpenTeleDB 數據庫線上征文活動優秀作品來襲！本篇為精選文章，分享實戰經驗與技術感悟，敬請閱讀。

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

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

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

XStore 的核心原理

XStore 與傳統 Heap 引擎的本質區別在于數據更新方式：

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

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

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

discard_worker_main: update globalRecycleXid: oldestXmin=202754...

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

測試環境與準備

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

項目

配置

操作系統

CentOS 7.9 x86_64

數據庫

OpenTeleDB v2.0 (PostgreSQL 17.6)

CPU

2 核

內存

2GB

存儲

SSD 40GB

驗證啟動：

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

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

執行后，該數據庫中新建的表會默認使用 XStore 引擎。

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

場景一：pgbench 標準壓測對比

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

Heap 引擎壓測

對 bench_heap 數據庫執行 100 并發、60 秒壓測：

pgbench-c100-j4-T60bench_heap

Heap 引擎結果：

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

XStore 引擎壓測

同樣的壓測參數應用于 bench_xstore 數據庫：

XStore 引擎結果：

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

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

關鍵差異：死元組統計

壓測結束后，對比兩個數據庫的空間占用和死元組情況：

指標

Heap 引擎

XStore 引擎

數據庫大小

167 MB

178 MB

死元組數量

37,502

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

場景二：業務訂單表高頻更新

pgbench 是標準化測試，接下來模擬一個更貼近實際業務的場景：訂單狀態流轉。

創建訂單表

使用 XStore 引擎創建一張訂單表，插入 10 萬條測試數據：

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);

初始空間占用

數據插入后，查看表的初始大小：

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

模擬訂單狀態流轉

在真實業務中，訂單會經歷 pending → paid → shipped → delivered → completed 的狀態變更。用一個循環模擬 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 引擎內部的空間管理開銷。

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

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

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

創建審計日志表

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 天數據寫入

每天寫入 10 萬條記錄，模擬一周的審計數據：

7 天共插入 70 萬條記錄。

查看表空間

指標

數值

表大小

107 MB

索引大小

27 MB

活躍行數

700,000

死元組

70 萬條 JSONB 數據，表大小 107MB，死元組為 0。

模擬批量更新

假設需要對前 10 萬條記錄做一次數據訂正：

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

更新 10 萬條記錄后：

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

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

日志中可以看到 discard_worker 持續在工作：

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

loops=1382 表示 Undo 回收循環已經執行了 1382 次，系統在自動維護存儲空間。

性能與空間的權衡

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

維度

Heap 引擎

XStore 引擎

單次寫入性能

較高（追加寫）

略低（原地更新 + Undo）

死元組

會累積，需 VACUUM

始終為 0

表膨脹

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

無膨脹

維護成本

需要調優 VACUUM 參數

自動回收，無需干預

適用場景

讀多寫少、批量導入

高頻更新、長期運行

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

我的體驗總結

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

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

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

技術選型沒有銀彈，關鍵是理解自己的業務特點。這次體驗讓我對 OpenTeleDB 有了更多期待，后續我打算再測試一下它的 XProxy 高并發連接能力。

參考資料

OpenTeleDB 社區：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

作者：一只牛博

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

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.