干数据库这行快十年了，亲眼见证了企业数据架构的变迁。早年做项目，最头疼的就是'数据竖井'——交易系统用 Oracle，用户行为日志扔到 MongoDB，时序监控数据塞进 InfluxDB，图谱关系又得搞个 Neo4j。每个库都有自己的语法、管理工具和运维体系，开发团队整天在不同数据库之间做数据同步和格式转换，数据一致性难保证，系统复杂度却直线上升。
这几年'融合数据库'的概念越来越热，但很多厂商的理解还停留在'多模接口'层面。直到去年深度参与了某城商行的核心系统分布式改造项目，用金仓数据库 KingbaseES 完整跑了一轮，才算真正体会到什么是'一库多能'的设计哲学。今天就跟大家聊聊我们的实践心得，特别是金仓在这方面的独特思考。
一、为什么是'一库多能'，不是'多库拼装'？
先看个真实场景。我们那个银行客户要做实时反欺诈，需要在一个查询里关联：用户账户信息（结构化）、近期交易流水（带时序特征）、设备指纹（JSON 文档）、社交关系图谱（判断是否团伙），以及地理位置信息（空间数据）。如果按传统思路，至少要跨 5 个不同数据库做联合查询，光数据同步延迟就够受的，更别说保证事务一致性了。
金仓 KingbaseES 的解法很直接：让一个数据库原生具备多种数据模型的处理能力。
注意，我说的是'原生'，不是'插件化集成'。两者有本质区别。很多数据库也支持 JSON 类型，但底层还是当成文本处理，查询优化器根本不懂 JSON 结构。金仓的做法是从存储引擎层就开始区分数据模型，优化器能识别'这是 JSONB 字段里的某个键'，还能为它建 GIN 索引；时序数据不只是打个时间戳标签，而是真的按时间分区组织物理存储，自动做时间窗口聚合下推。
我们做压测时对比过：同样是'查询某个用户最近一周在特定区域的交易，并按交易对手关系网络做风险评分'这个需求：
- 传统多库方案：需要从 Oracle 抽交易数据、从 MongoDB 取设备信息、从图数据库计算关系网络，再用 Spark 做关联分析，端到端延迟 8-12 秒
- 金仓单库方案：一条 SQL 写完，执行时间稳定在 400 毫秒以内
性能差距主要来自两方面：一是省去了跨网络的数据搬运开销，二是金仓的优化器能基于完整的数据分布信息生成更优的执行计划。这就引出了它的核心设计思路。
二、金仓融合架构的三层设计
1. 统一存储引擎：不是简单的'什么都能存'
很多数据库宣传多模存储，但底层还是行存那套架构。金仓的存储引擎是真正的'分层设计'：
-- 建表时就能看出差别
CREATE TABLE user_behavior (
-- 传统结构化字段
user_id BIGINT PRIMARY KEY,
reg_time TIMESTAMPTZ,
-- JSONB 字段，但物理存储是优化过的二进制格式
device_info JSONB,
-- 时序字段，会自动按时间分区
last_active_time TIMESTAMPTZ
) PARTITION BY RANGE (last_active_time);
关键在这儿：不同的字段类型，底层存储格式不同。device_info 字段内部是按键值对组织的列式存储，查询时可以直接命中子字段，不用解析整个 JSON。
我们做过测试，存储 10 万个用户的设备信息（平均每个 JSON 2KB）：
- 传统做法：存成文本字段，查询特定键值需要全表扫描解析
- 金仓 JSONB：每个键值单独压缩存储，查询
device_info->>'os_version' = 'Android'时，只扫描 os_version 这个'虚拟列'，IO 减少 70%
更实用的是空间数据支持。我们有个需求要计算'最近 1 公里内的可疑交易设备数'：
-- 传统方案：查出所有设备坐标，在应用层算距离
-- 金仓方案：直接用空间函数下推到存储层
SELECT COUNT(DISTINCT device_id)
transactions
ST_DWithin(
device_location,
ST_Point(, ),
) transaction_time NOW() ;
