NodeDB把多模型拆成4個(gè)引擎，第3個(gè)讓同行集體沉默

多模型數(shù)據(jù)庫(kù)喊了十年，真正拆開看引擎設(shè)計(jì)的沒幾個(gè)。NodeDB這次把底牌亮出來了：不是堆功能，是分家。

他們承認(rèn)了一件事：一個(gè)引擎吃遍天是假話。

這話從NodeDB團(tuán)隊(duì)嘴里說出來有點(diǎn)意思。畢竟"統(tǒng)一引擎"曾是這行的政治正確——對(duì)外宣傳口徑一致，對(duì)內(nèi)技術(shù)債堆成山。NodeDB的解法很產(chǎn)品經(jīng)理思維：先畫清楚哪些負(fù)載真的需要獨(dú)立血統(tǒng)，哪些可以蹭別人的基礎(chǔ)設(shè)施。

最終切出四個(gè)核心引擎家族：Document、Columnar、Strict、Graph。外加兩個(gè)"半獨(dú)立"選手：Time-Series和Spatial。這六塊拼盤，構(gòu)成了NodeDB對(duì)"多模型"這個(gè)詞的重新定義。

Document和Columnar：老熟人的新站位

Document（文檔模型）和Columnar（列式存儲(chǔ)）沒什么爭(zhēng)議。前者管靈活schema的半結(jié)構(gòu)化數(shù)據(jù)，后者扛分析型負(fù)載。這倆在市面上都有成熟參照物，MongoDB和ClickHouse分別打了樣。

NodeDB的Document引擎走標(biāo)準(zhǔn)路線：BSON-like文檔、嵌套對(duì)象、數(shù)組索引、聚合管道。沒驚喜，但也沒犯錯(cuò)。Columnar倒是值得多看一眼——它不只是"能跑OLAP"，而是被設(shè)計(jì)成其他引擎的墊腳石。

Time-Series和Spatial兩個(gè)模型，直接被掛靠在Columnar底下。

這個(gè)決策有點(diǎn)狠。市面上不少產(chǎn)品給時(shí)序數(shù)據(jù)單開一個(gè)TSDB引擎，圖個(gè)宣傳好聽。NodeDB的判斷是：時(shí)序的核心痛點(diǎn)在攝入速度和連續(xù)聚合，不是存儲(chǔ)格式本身。Columnar的壓縮率和向量化執(zhí)行，反而比專用引擎更香。

具體實(shí)現(xiàn)上，時(shí)序模塊繼承Columnar的存儲(chǔ)層，疊加ILP（行協(xié)議）攝入、PromQL查詢語法、時(shí)間窗口SQL函數(shù)。Spatial同理——地理空間索引和H3網(wǎng)格算法做進(jìn)Columnar的查詢層，底層還是列式掃描。

這種"寄生"架構(gòu)省了什么？至少省了一次數(shù)據(jù)搬運(yùn)。時(shí)序數(shù)據(jù)從攝入到分析，不用跨引擎ETL。地理圍欄查詢和BI報(bào)表，可以在同一個(gè)執(zhí)行計(jì)劃里完成。

Strict：最被低估的引擎

四個(gè)核心引擎里，Strict（嚴(yán)格模式）最容易被誤解。外行看名字，以為是"帶schema校驗(yàn)的文檔庫(kù)"。NodeDB團(tuán)隊(duì)專門澄清：不是。

「Strict exists because structured workloads need a different path」，這是他們的原話。

區(qū)別在哪？文檔模型的schema是勸退性質(zhì)的——你寫錯(cuò)字段，它報(bào)錯(cuò)。Strict的schema是物理性質(zhì)的——字段有固定偏移，查詢直接地址跳轉(zhuǎn)，不用解析文檔結(jié)構(gòu)。換句話說，Strict的行存儲(chǔ)模式更接近傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)，而非文檔的頁(yè)內(nèi)B樹。

這個(gè)區(qū)分擊中了一個(gè)行業(yè)痼疾：很多"多模型"產(chǎn)品把結(jié)構(gòu)化數(shù)據(jù)當(dāng)二等公民。

你可以建表，但底層還是文檔存儲(chǔ)；你可以跑TP負(fù)載，但執(zhí)行計(jì)劃沒針對(duì)點(diǎn)查優(yōu)化。NodeDB的Strict引擎從存儲(chǔ)格式開始重建：定長(zhǎng)字段緊湊排列，主鍵索引直接映射行地址，更新操作走原地修改而非寫時(shí)復(fù)制。

代價(jià)是靈活性。Strict表需要預(yù)定義字段類型，嵌套結(jié)構(gòu)受限，數(shù)組操作不如Document原生。但換來的是行級(jí)性能——點(diǎn)查延遲、更新吞吐量、事務(wù)回滾速度，都回到傳統(tǒng)OLTP的舒適區(qū)。

一個(gè)細(xì)節(jié)：Strict和Document可以共存于同一數(shù)據(jù)庫(kù)，但數(shù)據(jù)不混存。查詢時(shí)跨引擎關(guān)聯(lián)？可以，但執(zhí)行計(jì)劃會(huì)標(biāo)注引擎邊界，讓用戶清楚代價(jià)在哪。

Graph：最難啃的骨頭

圖引擎是NodeDB最后一個(gè)核心家族，也是技術(shù)債風(fēng)險(xiǎn)最高的模塊。圖數(shù)據(jù)庫(kù)的坑，這行里人人知道：屬性圖模型和RDF的宗教戰(zhàn)爭(zhēng)、鄰接表vs鄰接矩陣的存儲(chǔ)爭(zhēng)議、查詢優(yōu)化器的NP-hard噩夢(mèng)。

NodeDB的選擇是屬性圖路線，Cypher查詢語法，GQL標(biāo)準(zhǔn)兼容。存儲(chǔ)層用鄰接表+索引混合：出邊列表緊湊存儲(chǔ)，入邊走反向索引，屬性字段根據(jù)訪問模式動(dòng)態(tài)選擇行存或列存。

這個(gè)設(shè)計(jì)沒跳出現(xiàn)有框架，但有個(gè)務(wù)實(shí)細(xì)節(jié)：圖引擎和Strict引擎共享事務(wù)管理器。這意味著圖遍歷和結(jié)構(gòu)化更新可以打包在一個(gè)ACID事務(wù)里，不用兩階段提交。

跨模型事務(wù)是多模型的圣杯，也是墳場(chǎng)。NodeDB的解法不是"全局統(tǒng)一事務(wù)"，而是"有限打通"——只有Strict和Graph之間原生支持，其他引擎組合走異步同步或應(yīng)用層補(bǔ)償。

這種"部分連通"策略很產(chǎn)品經(jīng)理：不承諾萬能，但把高頻場(chǎng)景做透。

coherence：比引擎更難的問題

六個(gè)引擎擺出來，故事只講了一半。NodeDB團(tuán)隊(duì)花更多篇幅講的，是"coherence"——這個(gè)詞在原文出現(xiàn)四次，每次都在強(qiáng)調(diào)同一件事：多模型的敵人不是技術(shù)復(fù)雜度，是用戶認(rèn)知負(fù)擔(dān)。

他們列了三條 coherence 原則：

第一，統(tǒng)一的身份認(rèn)證和權(quán)限體系。不管數(shù)據(jù)存在哪個(gè)引擎，用戶看到的是同一套角色、同一套ACL規(guī)則。底層引擎各自的權(quán)限機(jī)制被屏蔽，防止"能讀A引擎但漏了B引擎"的安全漏洞。

第二，一致的備份和恢復(fù)語義。全量快照跨引擎一致性點(diǎn)，增量日志按全局時(shí)間戳排序。恢復(fù)時(shí)可以指定恢復(fù)到某個(gè)引擎子集，但默認(rèn)行為是全庫(kù)一致。

第三，查詢層面的有限透明。不是"一個(gè)SQL跑遍所有引擎"，而是"每個(gè)引擎有自己的方言，但共享表達(dá)式解析器和類型系統(tǒng)"。用戶寫Cypher查圖、寫SQL查列存，但函數(shù)名、類型轉(zhuǎn)換規(guī)則、錯(cuò)誤碼格式保持一致。

最后這條最有爭(zhēng)議。業(yè)界有派別主張"統(tǒng)一查詢語言"——SQL++或者GQL的擴(kuò)展，試圖用一層語法糖蓋住所有差異。NodeDB明確反對(duì)：「That would flatten the models」。

他們的觀察是，模型差異不只是語法，是執(zhí)行語義。圖遍歷的代價(jià)模型和關(guān)系代數(shù)完全不同，強(qiáng)行統(tǒng)一查詢計(jì)劃只會(huì)生成次優(yōu)執(zhí)行。與其騙用戶"寫一樣的東西"，不如誠(chéng)實(shí)暴露差異，但降低上下文切換成本。

Repo里的證據(jù)

技術(shù)文章容易飄，NodeDB這次給出了具體的代碼倉(cāng)庫(kù)指向。Strict引擎的當(dāng)前實(shí)現(xiàn)被描述為"row-like storage mode with direct field access"，時(shí)序模塊標(biāo)注為"columnar profile with ILP ingest"。

這些不是路線圖PPT，是已經(jīng)合并的代碼路徑。Graph引擎的Cypher解析器基于開源項(xiàng)目二次開發(fā)，但執(zhí)行引擎自研，目前支持到GQL 2024草案的子集。

一個(gè)值得注意的時(shí)間點(diǎn)：Spatial模塊的H3網(wǎng)格支持是2024年Q4合并的，比GeoHash實(shí)現(xiàn)晚了兩個(gè)版本。這個(gè)順序反映了優(yōu)先級(jí)——先搞定點(diǎn)查和范圍查詢，再補(bǔ)全復(fù)雜多邊形分析。

性能數(shù)字方面，NodeDB沒給官方benchmark，但repo里的回歸測(cè)試暴露了部分信息：Strict引擎的單行點(diǎn)查延遲中位數(shù)0.8ms（p99 4.2ms），Document同條件查詢中位數(shù)2.1ms（p99 12ms）。時(shí)序數(shù)據(jù)的ILP攝入吞吐在單節(jié)點(diǎn)測(cè)試達(dá)到120萬點(diǎn)/秒，但備注注明"未啟用連續(xù)聚合"。

這些數(shù)字不算驚艷，但提供了錨點(diǎn)。真正的考驗(yàn)在跨引擎查詢——目前repo里只有一個(gè)實(shí)驗(yàn)性的Federated Planner，支持Document和Strict的聯(lián)合查詢，Graph和其他引擎的打通還在TODO列表。

NodeDB團(tuán)隊(duì)的原話是：「The harder problem is coherence」。引擎可以一個(gè)個(gè)攢，但讓用戶覺得"這是一個(gè)數(shù)據(jù)庫(kù)而不是六個(gè)縫合怪"，需要更長(zhǎng)時(shí)間。

多模型數(shù)據(jù)庫(kù)的競(jìng)賽，現(xiàn)在才到中場(chǎng)。NodeDB把架構(gòu)攤開了，接下來要看的是：有多少用戶真的需要同時(shí)跑這六種負(fù)載，以及他們?cè)覆辉敢鉃?一個(gè)邊界"付溢價(jià)。