从多库并存到一库多能：金仓 KingbaseES 融合架构实践

有了空间索引，查询就不再是笨重的全量扫描，而是索引范围扫描，效率会好很多。

智能计算层：SQL 能走多远，业务就能写多简单

'一库多能'最直接的收益，其实是开发体验统一了。团队不再需要分'Oracle DBA''MongoDB 专家''时序数据库工程师'，很多事一套 SQL 就能说清楚。

而 KingbaseES 的优势不只是'能写 SQL'，而是让 SQL 对多模数据更友好。比如我们分析用户交易行为模式时，经常会把时序窗口、JSON 聚合、空间聚类和关系判断揉在一起：

WITH user_session AS (
    SELECT
        user_id,
        SESSION_WINDOW(transaction_time, INTERVAL '5 minutes') AS session_window,
        COUNT(*) AS trans_count,
        SUM(amount) AS total_amount,
        JSONB_AGG(DISTINCT device_info->>'model') AS device_models,
        ST_ClusterRadius(ARRAY_AGG(location)) AS cluster_radius
    FROM transactions
    WHERE transaction_date = CURRENT_DATE
    GROUP BY 1, 2
)
SELECT
    u.user_id,
    u.session_window,
    u.trans_count,
    EXISTS (
        SELECT 1
        FROM user_relations r
        WHERE r.user_id = u.user_id
          AND r.related_user_id IN (
              SELECT user_id
              FROM user_session s2
              WHERE s2.session_window && u.session_window
                AND ST_DWithin(s2.avg_location, u.avg_location, 500)
          )
    ) AS is_group_behavior
FROM user_session u
WHERE u.trans_count > 10;

这个查询里同时碰到了时序窗口、JSON 聚合、空间分析和图关系判断。放在传统架构里，可能得写一大堆中间逻辑，还要跨多个系统来回搬数据。放到 KingbaseES 里，核心思路就是一条 SQL。

真正关键的还是优化器。它能识别 SESSION_WINDOW 这类时序操作，知道该优先按时间分区扫描；看到 JSONB 聚合，会倾向于直接从二进制 JSONB 里提取目标字段；遇到空间函数，则会配合空间索引去做计算。对业务来说，表达力高了，代码自然会短很多。

分布式扩展：融合不意味着只能单机

多模型数据库常见的一个软肋是：功能挺全，量一上来就吃不住。KingbaseES 的处理方式比较务实——按业务维度分片，按数据类型优化。

CREATE TABLE user_profile (
    user_id BIGINT,
    base_info JSONB,
    credit_history JSONB,
    tags TEXT[],
    PRIMARY KEY (user_id)
) PARTITION BY HASH (user_id);

-- 同一个用户的数据逻辑上在一张表里，物理上可以按不同特性优化

在我们那个银行项目里，事务一致性是重点。KingbaseES 的思路是把大部分高频操作控制在单分片内，用本地事务保证 ACID；跨分片事务再走分布式机制，但尽量把复杂度收敛到少数场景。现实里最常见的其实是用户内操作，这部分打通以后，整体系统就已经顺很多了。

集群压测的结果也比较稳：在 16 个节点的环境里，TPS 能到 120 万，平均延迟大约 4.2ms。对于核心交易叠加实时风控的混合负载，这个表现已经很有说服力。

一些真实踩坑：官方文档没展开的地方

JSONB 性能不是银弹

KingbaseES 的 JSONB 设计得不错，但如果用法不讲究，照样会踩坑。

一个常见问题是把多层 JSON 解析直接写进 WHERE：

-- 不太推荐：在 WHERE 里做多层 JSON 解析
SELECT *
FROM orders
WHERE order_info->'user'->>'name' LIKE '张%'
  AND order_info->'items'->0->>'price'::numeric > 1000;

这样写的问题是，每次查询都可能要解析整段 JSON，索引也很难真正发挥作用。更稳妥的做法，是把常用字段提成生成列，再单独建索引：

ALTER TABLE orders
ADD COLUMN user_name VARCHAR
GENERATED ALWAYS AS (order_info->'user'->>'name') STORED;

CREATE INDEX idx_user_name ON orders(user_name);

这样查询路径会干净很多，优化器也更容易选到合适的索引。

另一个细节是索引选择。对于 JSONB 中多个常用键，索引设计不能太随意，最好结合实际过滤条件来定。部分索引也很有价值，比如只给 Android 设备建索引：

CREATE INDEX idx_android_users
ON users USING gin ((profile->'device'))
WHERE profile->>'os_type' = 'Android';

这样能明显缩小索引体积。

时序数据要考虑'老化'

时序数据有个很现实的特点：越新的越热，越旧的越冷。分区表很好用，但如果不提前规划分区生命周期，后面维护会很麻烦。

我们在交易表上做的是按天分区，并且提前创建未来 30 天的分区，同时清理 90 天以前的数据。这样做的好处很直接：

• 写入时不会因为分区不存在而卡住
• 历史数据能够自动归档或删除
• 业务侧基本无感知

这类运维动作最好交给定时任务，别靠人工盯。

混合负载一定要做资源隔离

HTAP 听起来很美，但如果分析查询把交易拖慢了，体验立刻就会变差。我们在项目里很重视资源组隔离：交易类查询和分析类查询分开跑，CPU、内存、IO 配额都尽量隔开。

实测很明显：没做隔离时，一个大分析查询能把交易响应时间从 5ms 拉到 200ms；做了隔离之后，分析查询可能略慢一点，但交易延迟能稳定很多，基本不会互相拖累。

从 Oracle 迁移过来，真正要改的是什么？

这个项目最开始是从 Oracle 迁移过来的。客户最关心的无非两件事：业务代码要改多少，性能会不会掉。

KingbaseES 的 Oracle 兼容模式确实帮了不少忙。我们统计过，大约 85% 的存储过程可以直接跑，剩下的主要是一些 Oracle 特有语法和函数需要调整，比如：

• ROWNUM 改成 ROW_NUMBER()
• SYSDATE 改成 CURRENT_TIMESTAMP
• (+) 外连接改成标准 SQL

但更重要的不是语法，而是数据模型的重构。原来在 Oracle 里分散在不同表、不同实例里的信息，迁到 KingbaseES 后，我们顺势做了一次融合：把用户基本信息、扩展属性、地址信息整合到更统一的模型里，配合 JSONB、空间类型和生成列，把查询路径理顺了。

迁移时用了金仓的 KFS 工具，支持在线迁移，全库 20TB 数据的停机时间控制在 2 小时内。迁移后的结果也比较实在：

• 存储空间减少约 35%
• 复杂查询平均提速 4 到 8 倍
• 数据访问层代码减少了约 60%

对一个核心系统来说，这些数字已经足够说明问题了。

运维监控：一库好用，还得一库好管

功能强只是第一步，好不好管，往往决定了数据库能不能真正落地。

KingbaseES 的监控和诊断能力，我个人觉得是比较'DBA 友好'的。它不只是给你一堆指标，更重要的是能把一些调优线索直接摆到面前。

比如 JSONB 字段里哪些键值最值得建索引，时序表最近的访问模式是什么，哪些查询长期命中不了理想计划，这些都能通过诊断信息慢慢看出来。对于日常优化，这种提示很有价值。

执行计划里给出的建议也挺实用。我们曾经根据优化器的提示，把一个核心查询从 1200ms 压到了 45ms。不是靠'玄学调参'，而是老老实实按执行计划去优化索引和分区策略。

融合数据库的边界在哪里？

用了 KingbaseES 一年多，我们也一直在想它的边界。

我自己的判断是，它特别适合这几类场景：

• 需要混合事务分析能力的业务，比如实时风控
• 数据结构多样，但彼此关联紧密的场景，比如用户画像
• 希望尽量简化技术栈、减少多库运维成本的团队

但它也不是要替代所有专用数据库。比如：

• 纯全文检索，专门的搜索引擎通常更强
• 超大规模图计算，专用图数据库的算法库更丰富
• 海量时序数据，专用时序库在压缩和写入上可能更极致

KingbaseES 更聪明的地方在于，它没有去追求'万能'，而是尽量把企业级核心场景做稳、做实。银行、政务、能源这类领域，很多时候需要的不是某个单点能力特别夸张，而是稳定、可靠、可运维、能扩展。

写在最后

'融合数据库'不是新概念，但 KingbaseES 让我看到了一种更务实的路线：不盲目堆概念，而是在企业真实需求和技术可行性之间找平衡。

我们团队现在新项目会优先评估它，不是因为某种外部要求，而是它确实能把复杂度压下来。以前可能要三套数据库、三套运维体系、三拨人盯着，现在很多事情可以收敛到一个平台里处理，开发和运维都轻松不少。

更重要的是，这种'一库多能'不是把问题藏起来，而是把本来散落在不同系统里的数据和计算尽量收拢到一个清晰的架构里。对真正要上线、要稳定、要长期演进的系统来说，这种价值很实在。