企业数据架构经历了显著变迁。早年项目常面临'数据竖井'问题——交易系统用 Oracle，日志存 MongoDB，时序数据入 InfluxDB，图谱关系需 Neo4j。每个库拥有独立语法、管理工具和运维体系，开发团队需在不同数据库间同步转换数据，一致性难保证且系统复杂度上升。
近年来'融合数据库'概念兴起，但部分厂商理解仍停留在'多模接口'。深度参与某城商行核心系统分布式改造项目后，使用金仓数据库 KingbaseES 完整跑通全流程，体会到'一库多能'的设计哲学。
一、为什么是'一库多能'，不是'多库拼装'？
真实场景如银行实时反欺诈，需在单查询中关联用户账户（结构化）、交易流水（时序）、设备指纹（JSON）、社交关系（图）及地理位置（空间）。传统思路需跨 5 个数据库联合查询，数据同步延迟高且事务一致性难保。
金仓的解法是让一个数据库原生具备多种数据模型处理能力。注意是'原生'而非'插件化集成'。底层存储引擎区分数据模型，优化器识别 JSONB 字段并建 GIN 索引；时序数据按时间分区组织物理存储，自动下推聚合。
压测对比显示：同样需求下，传统多库方案端到端延迟 8-12 秒，金仓单库方案稳定在 400 毫秒以内。性能提升源于省去跨网络搬运开销，以及优化器基于完整数据分布生成更优执行计划。
二、金仓融合架构的三层设计
1. 统一存储引擎
金仓存储引擎采用分层设计，非简单行存。
-- 建表时体现差异
CREATE TABLE user_behavior (
user_id BIGINT PRIMARY KEY,
reg_time TIMESTAMPTZ,
device_info JSONB,
last_active_time TIMESTAMPTZ
) PARTITION BY RANGE (last_active_time);
不同字段类型底层存储格式不同。JSONB 字段内部按键值对组织列式存储，查询特定键值无需解析整个 JSON。测试显示，存储 10 万用户设备信息，金仓 JSONB 查询 IO 减少 70%。
空间数据支持方面，计算'最近 1 公里内可疑交易设备数'可直接用空间函数下推至存储层，建立 R-Tree 索引，性能提升两个数量级。
2. 智能计算层
'一库多能'带来开发体验统一，一套 SQL 语法搞定所有。金仓让 SQL 更聪明，涉及时序窗口、JSON 聚合、空间聚类、图关系判断的复杂查询可一条 SQL 完成。
关键在于优化器。识别 SESSION_WINDOW 自动选择时间分区扫描；看到 JSONB_AGG 直接从压缩二进制提取字段；遇到 ST_ClusterRadius 调用空间索引计算。
3. 分布式扩展
融合数据库需支持线性扩展。策略是按业务维度分片，按数据类型优化。
-- 用户维度分片，不同类型数据存储策略不同
CREATE TABLE user_profile (
user_id BIGINT,
base_info JSONB,
credit_history JSONB,
tags TEXT[],
PRIMARY KEY (user_id)
) PARTITION BY HASH (user_id);
同一用户修改在同一分片内保证 ACID，跨用户事务用两阶段提交优化。实测 16 节点集群 TPS 达 120 万，平均延迟 4.2ms。
三、真实踩坑记录
1. JSONB 性能陷阱
坑 1：无节制嵌套查询
-- 错误示范
SELECT orders order_info ;
orders user_name GENERATED ALWAYS (order_info) STORED;
INDEX idx_user_name orders(user_name);
