NodeDB把多模型拆成4个引擎，第3个让同行集体沉默

多模型数据库喊了十年，真正拆开看引擎设计的没几个。NodeDB这次把底牌亮出来了：不是堆功能，是分家。

他们承认了一件事：一个引擎吃遍天是假话。

这话从NodeDB团队嘴里说出来有点意思。毕竟"统一引擎"曾是这行的政治正确——对外宣传口径一致，对内技术债堆成山。NodeDB的解法很产品经理思维：先画清楚哪些负载真的需要独立血统，哪些可以蹭别人的基础设施。

最终切出四个核心引擎家族：Document、Columnar、Strict、Graph。外加两个"半独立"选手：Time-Series和Spatial。这六块拼盘，构成了NodeDB对"多模型"这个词的重新定义。

Document和Columnar：老熟人的新站位

Document（文档模型）和Columnar（列式存储）没什么争议。前者管灵活schema的半结构化数据，后者扛分析型负载。这俩在市面上都有成熟参照物，MongoDB和ClickHouse分别打了样。

NodeDB的Document引擎走标准路线：BSON-like文档、嵌套对象、数组索引、聚合管道。没惊喜，但也没犯错。Columnar倒是值得多看一眼——它不只是"能跑OLAP"，而是被设计成其他引擎的垫脚石。

Time-Series和Spatial两个模型，直接被挂靠在Columnar底下。

这个决策有点狠。市面上不少产品给时序数据单开一个TSDB引擎，图个宣传好听。NodeDB的判断是：时序的核心痛点在摄入速度和连续聚合，不是存储格式本身。Columnar的压缩率和向量化执行，反而比专用引擎更香。

具体实现上，时序模块继承Columnar的存储层，叠加ILP（行协议）摄入、PromQL查询语法、时间窗口SQL函数。Spatial同理——地理空间索引和H3网格算法做进Columnar的查询层，底层还是列式扫描。

这种"寄生"架构省了什么？至少省了一次数据搬运。时序数据从摄入到分析，不用跨引擎ETL。地理围栏查询和BI报表，可以在同一个执行计划里完成。

Strict：最被低估的引擎

四个核心引擎里，Strict（严格模式）最容易被误解。外行看名字，以为是"带schema校验的文档库"。NodeDB团队专门澄清：不是。

「Strict exists because structured workloads need a different path」，这是他们的原话。

区别在哪？文档模型的schema是劝退性质的——你写错字段，它报错。Strict的schema是物理性质的——字段有固定偏移，查询直接地址跳转，不用解析文档结构。换句话说，Strict的行存储模式更接近传统关系型数据库，而非文档的页内B树。

这个区分击中了一个行业痼疾：很多"多模型"产品把结构化数据当二等公民。

你可以建表，但底层还是文档存储；你可以跑TP负载，但执行计划没针对点查优化。NodeDB的Strict引擎从存储格式开始重建：定长字段紧凑排列，主键索引直接映射行地址，更新操作走原地修改而非写时复制。

代价是灵活性。Strict表需要预定义字段类型，嵌套结构受限，数组操作不如Document原生。但换来的是行级性能——点查延迟、更新吞吐量、事务回滚速度，都回到传统OLTP的舒适区。

一个细节：Strict和Document可以共存于同一数据库，但数据不混存。查询时跨引擎关联？可以，但执行计划会标注引擎边界，让用户清楚代价在哪。

Graph：最难啃的骨头

图引擎是NodeDB最后一个核心家族，也是技术债风险最高的模块。图数据库的坑，这行里人人知道：属性图模型和RDF的宗教战争、邻接表vs邻接矩阵的存储争议、查询优化器的NP-hard噩梦。

NodeDB的选择是属性图路线，Cypher查询语法，GQL标准兼容。存储层用邻接表+索引混合：出边列表紧凑存储，入边走反向索引，属性字段根据访问模式动态选择行存或列存。

这个设计没跳出现有框架，但有个务实细节：图引擎和Strict引擎共享事务管理器。这意味着图遍历和结构化更新可以打包在一个ACID事务里，不用两阶段提交。

跨模型事务是多模型的圣杯，也是坟场。NodeDB的解法不是"全局统一事务"，而是"有限打通"——只有Strict和Graph之间原生支持，其他引擎组合走异步同步或应用层补偿。

这种"部分连通"策略很产品经理：不承诺万能，但把高频场景做透。

coherence：比引擎更难的问题

六个引擎摆出来，故事只讲了一半。NodeDB团队花更多篇幅讲的，是"coherence"——这个词在原文出现四次，每次都在强调同一件事：多模型的敌人不是技术复杂度，是用户认知负担。

他们列了三条 coherence 原则：

第一，统一的身份认证和权限体系。不管数据存在哪个引擎，用户看到的是同一套角色、同一套ACL规则。底层引擎各自的权限机制被屏蔽，防止"能读A引擎但漏了B引擎"的安全漏洞。

第二，一致的备份和恢复语义。全量快照跨引擎一致性点，增量日志按全局时间戳排序。恢复时可以指定恢复到某个引擎子集，但默认行为是全库一致。

第三，查询层面的有限透明。不是"一个SQL跑遍所有引擎"，而是"每个引擎有自己的方言，但共享表达式解析器和类型系统"。用户写Cypher查图、写SQL查列存，但函数名、类型转换规则、错误码格式保持一致。

最后这条最有争议。业界有派别主张"统一查询语言"——SQL++或者GQL的扩展，试图用一层语法糖盖住所有差异。NodeDB明确反对：「That would flatten the models」。

他们的观察是，模型差异不只是语法，是执行语义。图遍历的代价模型和关系代数完全不同，强行统一查询计划只会生成次优执行。与其骗用户"写一样的东西"，不如诚实暴露差异，但降低上下文切换成本。

Repo里的证据

技术文章容易飘，NodeDB这次给出了具体的代码仓库指向。Strict引擎的当前实现被描述为"row-like storage mode with direct field access"，时序模块标注为"columnar profile with ILP ingest"。

这些不是路线图PPT，是已经合并的代码路径。Graph引擎的Cypher解析器基于开源项目二次开发，但执行引擎自研，目前支持到GQL 2024草案的子集。

一个值得注意的时间点：Spatial模块的H3网格支持是2024年Q4合并的，比GeoHash实现晚了两个版本。这个顺序反映了优先级——先搞定点查和范围查询，再补全复杂多边形分析。

性能数字方面，NodeDB没给官方benchmark，但repo里的回归测试暴露了部分信息：Strict引擎的单行点查延迟中位数0.8ms（p99 4.2ms），Document同条件查询中位数2.1ms（p99 12ms）。时序数据的ILP摄入吞吐在单节点测试达到120万点/秒，但备注注明"未启用连续聚合"。

这些数字不算惊艳，但提供了锚点。真正的考验在跨引擎查询——目前repo里只有一个实验性的Federated Planner，支持Document和Strict的联合查询，Graph和其他引擎的打通还在TODO列表。

NodeDB团队的原话是：「The harder problem is coherence」。引擎可以一个个攒，但让用户觉得"这是一个数据库而不是六个缝合怪"，需要更长时间。

多模型数据库的竞赛，现在才到中场。NodeDB把架构摊开了，接下来要看的是：有多少用户真的需要同时跑这六种负载，以及他们愿不愿意为"一个边界"付溢价。