金仓 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 点跑这两个存储过程，保证了永远有未来 30 天的空分区等着，90 天前的数据自动清理，业务完全无感知。

3. 混合负载的资源隔离

HTAP 听起来美好，但分析查询把交易拖垮的事情太常见。金仓的资源组功能是我们的救星：

-- 创建两个资源组
CREATE RESOURCE GROUP oltp_group WITH ( concurrency = 100, cpu_rate_limit = 70, memory_limit = '4GB', io_priority = 'HIGH' );
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
    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';
    ELSIF 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, 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),
    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 的压缩率更高）

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

写在最后

'融合数据库'不是新概念，但金仓的实践让我看到了国产数据库的务实思考。它没有盲目追新潮，而是在企业真实需求和技术可行性之间找到了平衡点。

当然也不是没槽点。比如社区版功能限制多，企业版价格不便宜；有些新特性的文档还不够详细，得自己摸索。但整体来说，金仓 KingbaseES 的'一库多能'思路，确实为很多企业提供了一条务实的数据架构演进路径。