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

這兩年數(shù)據(jù)庫(kù)圈有點(diǎn)像 3 年前的云原生圈："分布式"、"新一代內(nèi)核"、"重構(gòu)存儲(chǔ)引擎" 這些詞突然又密集起來(lái)了。

前幾天刷群，看到有人轉(zhuǎn)了 OpenTeleDB 的開(kāi)源消息，說(shuō)是 "基于 PostgreSQL 的新一代內(nèi)核"。說(shuō)實(shí)話(huà)，我第一反應(yīng)是：又一個(gè)魔改 PG？

但看到里面提到一個(gè)點(diǎn)：原位更新 + Undo 引擎（XStore），我還是沒(méi)忍住下了源碼。 因?yàn)檫@恰好戳中我這些年被 PG 折磨得最狠的痛點(diǎn)：

表膨脹、autovacuum 抽風(fēng)、性能像心電圖一樣忽高忽低。

所以這次我沒(méi)看 PPT，也沒(méi)看宣傳稿，直接跑到機(jī)器上拆了半天，想看看它究竟動(dòng)了 PG 的哪根 "老筋"。

一、先說(shuō)結(jié)論：XStore 不是快，而是 "穩(wěn)"

我裝的是 OpenTeleDB 的 17.6 內(nèi)核版。 創(chuàng)建方式很直觀：

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

這一步其實(shí)就已經(jīng)很有意思了 ------ 它不是 fork 了一套新引擎，而是作為插件掛進(jìn)去的。 這個(gè)思路我很認(rèn)可：

• 不綁死 PG 版本

• 能跟著大版本升級(jí)

• 出問(wèn)題可以隨時(shí)回退

像 Citus、openHalo 這些 "成功插件化路線(xiàn)" 的項(xiàng)目，本質(zhì)都是這個(gè)思路。

二、打開(kāi)數(shù)據(jù)目錄，我第一次意識(shí)到：它真不是換皮

在 $PGDATA 下面，多了一個(gè)非常顯眼的目錄：

drwx------2postgrespostgres4096Nov320:15undo

這就是 XStore 的核心： 它不是靠多版本鏈來(lái)維護(hù) MVCC，而是靠 Undo 日志回滾。

這點(diǎn)和 Oracle、MySQL InnoDB 的邏輯更像。

也正是它敢說(shuō) "原位更新" 的底氣來(lái)源。

三、插入測(cè)試：它不快，但很 "誠(chéng)實(shí)"

我用同樣的參數(shù)，在同一臺(tái)機(jī)器上跑了兩組：

INSERTINTO test_xstore (name, value) SELECTmd5(random()::text), (random()*1000)::int FROM generate_series(1,10000000);

INSERTINTO test_heap (name, value) SELECTmd5(random()::text), (random()*1000)::int FROM generate_series(1,10000000);

結(jié)果是：

寫(xiě)慢了將近一倍。這點(diǎn)我反而覺(jué)得真實(shí)：因?yàn)?XStore 在寫(xiě)數(shù)據(jù)頁(yè)的同時(shí)，還要寫(xiě)一份 Undo。物理寫(xiě)入翻倍，吞吐下降是必然的。如果一個(gè)系統(tǒng)告訴你 "原位更新 + Undo 還更快"，那我反而會(huì)不太信。

四、創(chuàng)新實(shí)驗(yàn)：模擬 1 千萬(wàn)數(shù)據(jù)的存儲(chǔ)膨脹對(duì)比

我設(shè)計(jì)了一項(xiàng)創(chuàng)新實(shí)驗(yàn)：在 1000 萬(wàn)條級(jí)別的大數(shù)據(jù)量下，評(píng)估 XStore 與 Heap 表在高頻更新下的空間膨脹、索引穩(wěn)定性以及查詢(xún)性能表現(xiàn)。該實(shí)驗(yàn)主要有兩個(gè)創(chuàng)新點(diǎn)：

大規(guī)模數(shù)據(jù)模擬

1. 使用 generate_series(1,10000000) 生成 1000 萬(wàn)條數(shù)據(jù)，保證數(shù)據(jù)量級(jí)對(duì)存儲(chǔ)膨脹影響明顯。

2. 初始數(shù)據(jù)包括 id、name、value 和 updated_at 四列，與前期實(shí)驗(yàn)一致，但數(shù)據(jù)量增加十倍，以模擬真實(shí)大規(guī)模 OLTP 系統(tǒng)負(fù)載。

多維度空間分析

1. 不僅監(jiān)控表總大小，還分別統(tǒng)計(jì)索引占用和 TOAST 表空間。

2. 每輪更新后，通過(guò) pg_relation_size、pg_total_relation_size 和 pg_indexes_size 獲取精細(xì)化指標(biāo)。

3. 引入 可視化趨勢(shì)分析，繪制表空間增長(zhǎng)曲線(xiàn)，以直觀展示 XStore 與 Heap 的差異。

4.1 實(shí)驗(yàn)設(shè)計(jì)

表結(jié)構(gòu)

CREATETABLE xstore_large ( idSERIAL PRIMARY KEY, nameTEXT, valueINT,     updated_at TIMESTAMPDEFAULTCURRENT_TIMESTAMP ) USING XSTORE; CREATETABLE heap_large ( idSERIAL PRIMARY KEY, nameTEXT, valueINT,     updated_at TIMESTAMPDEFAULTCURRENT_TIMESTAMP );

初始化 1000 萬(wàn)條數(shù)據(jù)

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

先對(duì)現(xiàn)在存入 1000w 數(shù)據(jù)的空間監(jiān)控與記錄一下如下。

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;

 985 MB       | 388 MB       | 789 MB     | 214 MB

多輪全表更新

• 連續(xù) 5 輪更新，每輪更新 value 和 updated_at，模擬寫(xiě)入密集場(chǎng)景：

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

空間監(jiān)控與記錄

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;

第一輪：

 985 MB       | 388 MB       | 1578 MB    | 428 MB

第五輪：

 985 MB       | 388 MB       | 1628 MB    | 428 MB

4.2 千萬(wàn)數(shù)據(jù)更新膨脹可視化

五、實(shí)驗(yàn)結(jié)論

這組 1000 萬(wàn)級(jí)數(shù)據(jù) + 多輪全表更新的實(shí)驗(yàn)，其實(shí)把 PG 傳統(tǒng) Heap 表的 "老問(wèn)題" 放大得非常清楚。

最核心的對(duì)比結(jié)果只有一句話(huà)：

XStore 的空間是線(xiàn)性的、可預(yù)測(cè)的；Heap 表的空間是失控的、不可預(yù)測(cè)的。

具體來(lái)看：

1. 表空間膨脹

a. Heap 表在第一次更新后，表體空間直接翻倍，從 789MB 飆到 1578MB。

b. 之后每一輪更新，雖然增長(zhǎng)幅度趨緩，但空間再也回不到初始狀態(tài)。

c. XStore 從頭到尾不變： 985MB → 985MB → 985MB

1. 索引體積穩(wěn)定性

a. Heap 表索引從 214MB 膨脹到 428MB，且在后續(xù)更新中保持 "高位橫盤(pán)"。

b. XStore 的索引尺寸始終維持在 388MB 左右，沒(méi)有明顯漂移。

1. 更新行為本質(zhì)差異

a. Heap：每一次 UPDATE，本質(zhì)都是 DELETE + INSERT → 老版本殘留 → 表膨脹 → 索引碎片 → autovacuum 壓力。

b. XStore：真正的原位更新 → 歷史版本進(jìn) Undo → 主表物理頁(yè)不變 → 無(wú)膨脹。

1. 長(zhǎng)期可運(yùn)維性

a. 在 Heap 表上，如果你不 VACUUM，它一定會(huì)慢； 如果你 VACUUM，系統(tǒng)一定會(huì)抖。

b. 在 XStore 上，這兩件事都不再是必選項(xiàng)。

這意味著什么？

它不是讓你飛起來(lái)，而是讓你不再塌方。

六、我的心得

說(shuō)實(shí)話(huà)，這幾年我已經(jīng)對(duì) "新一代數(shù)據(jù)庫(kù)內(nèi)核" 這類(lèi)說(shuō)法有點(diǎn)免疫了。大多數(shù)項(xiàng)目，要么是在 PG 上糊一層分布式殼； 要么就是換個(gè)名字，重新賣(mài)一遍 MVCC。而 XStore 給我的感覺(jué)不一樣。它沒(méi)有試圖掩蓋代價(jià)。寫(xiě)入更慢， IO 更多，架構(gòu)更復(fù)雜。

但它正面承認(rèn)了一個(gè)事實(shí)：

PostgreSQL 的 MVCC，在高頻更新場(chǎng)景下已經(jīng)接近物理極限。

這不是參數(shù)調(diào)優(yōu)能解決的事，也不是加機(jī)器能扛住的事，而是存儲(chǔ)模型本身的問(wèn)題。這些年我見(jiàn)過(guò)太多系統(tǒng)：白天 QPS 很穩(wěn)，半夜 autovacuum 開(kāi)始清垃圾，延遲突然拉長(zhǎng)，業(yè)務(wù)報(bào)警，DBA 開(kāi)始手工 VACUUM / REINDEX / CLUSTER，第二天繼續(xù)循環(huán)。

這不是運(yùn)維水平的問(wèn)題，而是模型在和現(xiàn)實(shí)硬扛。XStore 讓我第一次意識(shí)到：原來(lái) PG 也可以選擇不走這條老路。它沒(méi)有追求 "更快"，而是選擇了一個(gè)更難、但更穩(wěn)的方向：

• 用 Undo 換空間可控

• 用寫(xiě)放大換性能平滑

• 用工程復(fù)雜度換系統(tǒng)長(zhǎng)期可預(yù)期性

如果你是寫(xiě)多、更新密集型 OLTP 系統(tǒng)，如果你被表膨脹、索引碎片、autovacuum 抽風(fēng)折磨過(guò)，那你會(huì)和我一樣 --- 不一定立刻用它，但你會(huì)開(kāi)始認(rèn)真看它。這大概就是我這次拆源碼、跑實(shí)驗(yàn)，最大的收獲。

作者：難忘兄