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

金仓会为 device_location 字段建立 R-Tree 索引，查询变成简单的索引范围扫描，性能提升两个数量级。

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

'一库多能'最大的好处是开发体验统一。团队不再需要分'Oracle DBA'、'MongoDB 专家'、'时序数据库工程师'，一套 SQL 语法搞定所有。

但金仓做得更彻底——它让 SQL 变得'更聪明'。例如分析用户交易行为模式：

WITH user_session AS (
    -- 时序分析：按 5 分钟会话窗口切分
    SELECT 
        user_id, 
        SESSION_WINDOW(transaction_time, INTERVAL '5 minutes') as session_window,
        -- 窗口函数：计算会话内统计
        COUNT(*) as trans_count, 
        SUM(amount) as total_amount,
        -- JSON 分析：提取设备特征
        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 聚合、空间聚类、图关系判断。在传统架构里，可能需要写几百行代码，调用四五个系统。在金仓里，就是一条 SQL 的事情。

关键在于优化器。金仓的优化器能识别出 SESSION_WINDOW 是时序操作，会自动选择按时间分区扫描；看到 JSONB_AGG，知道从压缩的二进制 JSONB 里直接提取 model 字段，不用解压整个文档；遇到 ST_ClusterRadius，会调用空间索引计算。

3. 分布式扩展：融合不是单点，也要能线性扩展

这是很多'融合数据库'的软肋。支持多模型很好，但数据量大了怎么办？金仓的答案很务实：按业务维度分片，按数据类型优化。

项目中的分片策略：

-- 用户维度分片，但不同类型数据存储策略不同
CREATE TABLE user_profile (
    user_id BIGINT,
    base_info JSONB, -- 频繁更新的基本信息，行存储
    credit_history JSONB, -- 只追加的信用历史，列存储
    tags TEXT[], -- 标签数组，GIN 倒排索引
    PRIMARY KEY (user_id)
) PARTITION BY HASH (user_id);

关键设计：同一个用户的不同类型数据，物理上可以存储在不同介质。行存储部分放 SSD，列存储部分可以放普通硬盘。但逻辑上还是一个表，查询时自动关联。

分片后的事务一致性是个难点。解决方案是'分组提交 + 异步复制'：

• 同一用户的所有修改（无论什么数据类型）保证在同一个分片内，用本地事务保证 ACID
• 跨用户的事务用两阶段提交，但会做优化：90% 的交易是用户内操作，只有 10% 需要分布式事务
• 最终通过异步复制保证跨分片一致性，但提供'会话一致性'选项，对应用透明

实测下来，16 个节点的集群，TPS 能到 120 万，平均延迟 4.2ms。对于银行核心交易 + 实时风控的混合负载，完全够用。

三、真实踩坑记录：那些官方文档没细说的细节

1. JSONB 性能陷阱与避坑指南

虽然金仓的 JSONB 做得不错，但也不是银弹。常见的问题包括：

坑 1：无节制的嵌套查询

-- 错误示范：在 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);
-- 查询直接走 B-tree 索引

坑 2：JSONB 的索引选择

-- 场景：查询 device_info 里 os_type 和 app_version 的组合
-- 方案 1：建两个 gin 索引（错！）
CREATE INDEX idx_os ON devices USING gin ((device_info->'os'));
CREATE INDEX idx_app ON devices USING gin ((device_info->'app'));

-- 方案 2：建一个多列 gin 索引（对！）
CREATE INDEX idx_device_combo ON devices USING gin ((device_info->'os'), (device_info->'app'));
-- 第二个索引大小只有第一个的 60%，查询时能同时命中两个条件

金仓的 JSONB 索引有个特性：支持部分索引。比如只给 Android 设备建索引：

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

索引大小直接减半。

2. 时序数据的老化策略

时序数据最大的特点是'越新的越热，越旧的越冷'。金仓的分区表很好用，但自动老化需要自己配置：

-- 创建按天分区的交易表
CREATE TABLE transactions (
    trans_id BIGSERIAL,
    user_id BIGINT,
    amount NUMERIC(10,2),
    trans_time TIMESTAMPTZ NOT NULL
) PARTITION BY RANGE (trans_time);

-- 关键：提前创建分区
CREATE OR REPLACE PROCEDURE create_transaction_partitions()
LANGUAGE plpgsql AS $$
DECLARE start_date DATE := CURRENT_DATE;
i INT;
BEGIN
    FOR i IN 0..30 LOOP
        DECLARE part_date DATE := start_date + i;
        part_name TEXT := 'trans_' || to_char(part_date, 'YYYYMMDD');
        BEGIN
            IF NOT EXISTS (
                SELECT 1 FROM pg_tables WHERE tablename = part_name
            ) THEN
                EXECUTE format(
                    'CREATE TABLE %I PARTITION OF transactions '
                    'FOR VALUES FROM (%L) TO (%L) '
                    'WITH (fillfactor=95)',
                    part_name, part_date, part_date + 1
                );
            END IF;
        END;
    END LOOP;
END;
$$;

-- 自动清理旧数据
CREATE OR REPLACE PROCEDURE drop_old_partitions(retention_days INT DEFAULT 90)
LANGUAGE plpgsql AS $$
DECLARE old_date DATE := CURRENT_DATE - retention_days;
part_record RECORD;
BEGIN
    FOR part_record IN 
        SELECT inhrelid::regclass as part_name 
        FROM pg_inherits JOIN pg_class ON inhrelid = oid 
        WHERE inhparent = 'transactions'::regclass 
        AND relname ~ '^trans_\d{8}$' 
        AND substring(relname from 'trans_(\d{4})(\d{2})(\d{2})')::DATE < old_date
    LOOP
        -- 先解除分区关系
        EXECUTE format('ALTER TABLE transactions DETACH PARTITION %s', part_record.part_name);
        -- 再删除表
        EXECUTE format('DROP TABLE %s', part_record.part_name);
        RAISE NOTICE 'Dropped partition: %', part_record.part_name;
    END LOOP;
END;
$$;

设置每天凌晨 2 点跑这两个存储过程，保证了：

1. 永远有未来 30 天的空分区等着
2. 90 天前的数据自动清理
3. 业务完全无感知

3. 混合负载的资源隔离

HTAP 听起来美好，但分析查询把交易拖垮的事情太常见。资源组功能是解决之道：

-- 创建两个资源组
CREATE RESOURCE GROUP oltp_group WITH (
    concurrency = 100, -- 最大并发数
    cpu_rate_limit = 70, -- CPU 使用率上限
    memory_limit = '4GB', -- 内存上限
    io_priority = 'HIGH' -- IO 优先级
);
CREATE RESOURCE GROUP olap_group WITH (
    concurrency = 20,
    cpu_rate_limit = 30,
    memory_limit = '8GB',
    io_priority = 'LOW'
);

-- 用户绑定资源组
ALTER USER app_user SET resource_group = 'oltp_group';
ALTER USER bi_user SET resource_group = 'olap_group';

-- 更细粒度：按查询类型动态分配
CREATE OR REPLACE FUNCTION assign_resource_group()
RETURNS void LANGUAGE plpgsql AS $$
BEGIN
    -- 交易类查询走 OLTP 组
    IF current_query() LIKE 'INSERT%' OR current_query() LIKE 'UPDATE%' OR current_query() LIKE 'DELETE%' OR 
       (current_query() LIKE 'SELECT%' AND current_query() ~ 'WHERE.*=.*') THEN
        SET LOCAL resource_group = 'oltp_group';
    -- 分析类查询走 OLAP 组
    ELSEIF current_query() LIKE 'SELECT%' AND (
        current_query() LIKE '%GROUP BY%' OR 
        current_query() LIKE '%WINDOW%' OR 
        current_query() LIKE '%PARTITION%'
    ) THEN
        SET LOCAL resource_group = 'olap_group';
    END IF;
END;
$$;

实测效果：在未做资源隔离时，一个大的分析查询能让交易响应时间从 5ms 飙升到 200ms。做了隔离后，分析查询可能会慢点（从 2 秒变成 3 秒），但交易响应时间始终稳定在 10ms 以内。

四、迁移实战：从'拆'到'合'的平滑过渡

项目是从 Oracle 迁移过来的。客户最担心两件事：1）业务代码要重写多少？2）性能会不会下降？

金仓的 Oracle 兼容模式确实省了不少事。统计显示，大概 85% 的存储过程可以直接跑，只有 15% 需要调整。主要调整点集中在：

• Oracle 特有的伪列（ROWNUM 改成 ROW_NUMBER()）
• 日期函数（SYSDATE 改成 CURRENT_TIMESTAMP）
• 一些特殊语法（(+) 外连接改成标准 SQL）

更重要的是数据模型的重构。原来在 Oracle 里，各种数据是分散在不同表甚至不同实例里的。迁移到金仓，我们趁机做了'数据融合'：

迁移前（Oracle）：

-- 用户基本信息表
CREATE TABLE users (
    user_id NUMBER,
    name VARCHAR2(100),
    id_card VARCHAR2(20)
);
-- 用户扩展信息（另一个实例）
CREATE TABLE user_ext (
    user_id NUMBER,
    preferences CLOB, -- 存 JSON 文本
    device_info CLOB
);
-- 用户地址表
CREATE TABLE user_address (
    user_id NUMBER,
    lng NUMBER, -- 经度
    lat NUMBER -- 纬度
);

迁移后（金仓）：

-- 融合成一张表
CREATE TABLE users (
    user_id BIGINT PRIMARY KEY,
    name VARCHAR(100),
    id_card VARCHAR(20),
    -- JSONB 替代 CLOB
    preferences JSONB,
    device_info JSONB,
    -- 空间数据类型
    location GEOMETRY(Point, 4490)
) PARTITION BY HASH (user_id);

-- 生成列加速查询
ALTER TABLE users ADD COLUMN province VARCHAR(20) GENERATED ALWAYS AS (preferences->>'province') STORED;
-- 建复合索引
CREATE INDEX idx_users_combo ON users USING btree (province, (device_info->>'os_type'));

迁移过程用了 KFS 工具，支持在线迁移，业务停机时间只有 2 小时（全库 20TB 数据）。迁移后效果：

• 存储空间：减少 35%（JSONB 压缩 + 列存储）
• 复杂查询：平均提速 4-8 倍
• 代码量：减少 60% 的数据访问层代码

五、运维监控：让'一库'好管是关键

功能再强，不好管也是白搭。金仓的监控体系设计得很'DBA 友好'。

1. 性能洞察

-- 常用诊断查询
-- 1. 看哪些 JSONB 字段最值得建索引
SELECT tablename, (jsonb_object_keys(jsonb_fields)->>'key') as json_key, COUNT(*) as frequency, AVG(LENGTH(jsonb_fields->>key)) as avg_length 
FROM (
    SELECT tablename, jsonb_object_keys(device_info) as key, device_info 
    FROM users 
    WHERE device_info IS NOT NULL
) t 
GROUP BY 1, 2 ORDER BY 3 DESC LIMIT 10;

-- 2. 时序数据访问模式
SELECT 
    DATE_TRUNC('hour', query_time) as hour,
    CASE 
        WHEN query_text LIKE '%WHERE transaction_time > NOW() - interval%' THEN 'recent_data'
        WHEN query_text LIKE '%WHERE transaction_time < %' THEN 'historical_data'
        ELSE 'other'
    END as query_type,
    COUNT(*) as query_count, 
    AVG(execution_time) as avg_time 
FROM query_history 
WHERE table_name = 'transactions' 
GROUP BY 1, 2 ORDER BY 1 DESC;

2. 智能调优建议

金仓内置的优化器能给出很实在的建议：

-- 执行计划里会给出'Hint'
EXPLAIN (ANALYZE, BUFFERS) 
SELECT * FROM users 
WHERE preferences->>'city' = '北京' 
AND device_info->>'model' = 'iPhone';

输出会包含：

• 建议 1：考虑在 (preferences->>'city', device_info->>'model') 上创建复合索引
• 建议 2：city 字段基数低，考虑使用位图索引
• 建议 3：该查询常与时间范围组合，考虑按时间分区

实施索引优化后，一个核心查询从 1200ms 降到了 45ms。

六、思考：融合数据库的边界在哪里？

目前看：

适合融合的场景：

1. 混合事务分析（HTAP）需求明显的，比如实时风控
2. 数据结构多样但关联紧密的，比如用户画像
3. 希望简化技术栈的中小型团队

可能还需要专用库的场景：

1. 纯粹的全文检索（Elasticsearch 还是更强）
2. 超大规模图计算（Neo4j/JanusGraph 的算法更丰富）
3. 海量时序数据（InfluxDB 的压缩率更高）

但金仓聪明的地方在于，它不追求'万能'，而是在'企业级核心场景'上做到极致。银行、政务、能源这些领域，需要的不是某个单点能力特别强，而是稳定、可靠、易运维。金仓抓住了这个痛点。