国产时序数据库实战，金仓如何破解电力行业数据困局

面对能源电力、智能制造等行业海量时序数据处理的刚性需求，国产数据库能否真正扛起大旗？我们从几个真实项目里找到了答案。

一、前言：国产数据库的"关键时刻"

最近两年，在电力、能源这些关键行业里，我明显感受到一个变化：大家讨论国产数据库时，不再停留在"能不能用"的阶段，而是开始认真考虑"怎么用好"的问题。

这个转变背后有两股力量在推动：

一是业务需求的倒逼------现在一个中等规模的变电站，每秒产生的监测数据就能达到几十万条；新能源场站的风机、光伏板每时每刻都在产生海量时序数据。传统的关系型数据库已经力不从心，而国外的专业时序数据库又面临各种限制。

二是政策环境的推动------信创已经从"试点"走向"全面推进"，特别是在能源、电力这些关系到国计民生的关键领域，自主可控的要求越来越高。

在这个背景下，金仓的时序数据库解决方案进入了我们的视野。经过几个项目的实际落地，我积累了一些真刀真枪的经验，今天就来聊聊这个过程中我们遇到的坑、填过的坑，以及一些实实在在的收获。

二、金仓时序引擎：不是简单的"又一个时序数据库"

2.1 架构设计的务实思路

第一次接触金仓时序数据库时，我和很多人的第一反应一样："这又是一个基于PostgreSQL改的时序方案吧？"深入了解之后才发现，这个看法有点片面。

金仓的时序引擎确实借鉴了现代时序数据库的优秀理念，但它最大的特点在于不搞"技术理想主义" 。很多专门的时序数据库追求极致的写入性能，却在复杂查询、事务一致性上做了妥协。而金仓走的是"实用主义路线"------在保证企业级功能完整性的基础上，把时序性能做到足够好。

这背后的逻辑其实很清晰：在电力调度、智能制造这些场景里，系统不可能只处理简单的指标写入。一个典型的查询可能是："找出华东区域过去24小时内，电压波动超过10%且温度异常的设备，并关联这些设备最近的维修记录"。这种查询涉及时间窗口、空间范围、多表关联和JSON字段查询------这已经不是简单的时序查询了。

实战经验分享：

去年我们在一个省级电网项目中，初期考虑过专门的时序数据库，但在POC测试阶段就遇到了瓶颈：简单的指标写入确实快，但一到复杂的业务分析场景，要么需要把数据导出到其他系统，要么查询性能直线下降。后来切换到金仓的时序方案，最大的感受就是"不用在功能和性能之间做单选题了"。

2.2 性能表现：数据说话

我知道大家对性能数据比较关注，这里分享一组真实的测试对比（基于某电网公司的测试环境）：

**测试场景：** 5000个测点，采样频率1Hz，连续写入7天

数据库类型	写入吞吐量(点/秒)	存储占用(压缩后)	复杂查询响应时间(秒)
传统关系库(Oracle)	约8万	2.1TB	8.7
专用时序库A	约35万	1.4TB	不支持复杂关联查询
金仓时序引擎	约28万	0.9TB	1.2

这个对比很能说明问题：金仓在写入性能上确实比专用时序库略低，但差距在实际业务中是可以接受的（28万点/秒对绝大多数场景都足够了）。而在存储效率和复杂查询能力上，金仓的优势非常明显------存储节省了35%，复杂查询速度快了7倍多。

更重要的是，在实际生产环境中，稳定性往往比峰值性能更重要。金仓的写入性能曲线非常平稳，不会出现某些时序数据库那种"忽高忽低"的情况。这在电力监控这种对稳定性要求极高的场景里，是个很大的加分项。

三、核心功能剖析：不只是"快"那么简单

3.1 多模数据处理的实战价值

"多模融合"这个词现在很火，但在时序场景里到底有什么用？我举个实际的例子。

在智慧电厂的项目里，我们不仅要记录设备的温度、压力、振动这些时序指标，还需要管理设备的静态信息（型号、安装位置、维护记录），有时候还要处理设备巡检时拍的图片、视频片段。传统的做法是用多个系统：时序数据库存指标，关系数据库存设备信息，文件系统存多媒体数据。

这种架构带来的问题很明显：数据孤岛。想分析"某型号设备在高温环境下的故障特征"，需要从三个系统里取数据，然后再做关联分析------效率低不说，还容易出错。

金仓的解决思路很直接：在一个数据库里支持多种数据类型。听起来简单，但实现起来需要底层存储引擎、查询优化器都做深度适配。

看个实际的表设计例子：

sql 复制代码

-- 这是我们在实际项目中使用的设备监测表结构
-- 兼顾了时序性能和多模查询需求

CREATE TABLE power_plant_monitoring (
    -- 时序主维度
    record_time TIMESTAMPTZ NOT NULL,
    device_id VARCHAR(32) NOT NULL,
    
    -- 时序指标（高频变化）
    temperature DECIMAL(5,2),  -- 温度
    pressure DECIMAL(6,2),     -- 压力
    vibration_level SMALLINT,  -- 振动等级
    
    -- 空间数据（GIS位置）
    geo_location GEOGRAPHY(POINT, 4326),
    
    -- 标签数据（低频变化）
    device_status VARCHAR(20),  -- 设备状态
    operator_id INTEGER,        -- 操作员
    
    -- 文档数据（设备日志、报告）
    inspection_report JSONB,    -- 巡检报告
    alarm_details JSONB,        -- 告警详情
    
    -- 扩展字段（预留业务扩展）
    tags TEXT[],                -- 标签数组
    
    -- 主键设计：时间+设备
    PRIMARY KEY (record_time, device_id)
)
-- 关键在这里：多级分区策略
PARTITION BY RANGE (record_time)
INTERVAL ('1 day'::interval)  -- 按天自动分区
(
    START ('2025-01-01') 
    END ('2025-12-31')
    EVERY ('1 month')  -- 每月一个主分区
)
-- 再按设备类型做子分区
SUBPARTITION BY LIST (device_id)
SUBPARTITION TEMPLATE (
    SUBPARTITION motors VALUES ('motor_001', 'motor_002', 'motor_003'),
    SUBPARTITION pumps VALUES ('pump_001', 'pump_002'),
    SUBPARTITION transformers VALUES ('transformer_001', 'transformer_002')
);

-- 创建复合索引：一个索引支持多种查询模式
CREATE INDEX idx_smart_query ON power_plant_monitoring 
USING BRIN (record_time)  -- 时序范围查询用BRIN索引
INCLUDE (device_id, temperature, device_status);

-- 空间索引：支持GIS查询
CREATE INDEX idx_geo_location ON power_plant_monitoring 
USING GIST (geo_location);

-- JSON字段索引：支持文档查询
CREATE INDEX idx_inspection_report ON power_plant_monitoring 
USING GIN (inspection_report);

这个设计的精妙之处在于：它用一张表解决了过去需要多张表、甚至多个系统才能解决的问题。

高频的时序指标（温度、压力）按时间分区，保证写入性能
低频的标签数据（设备状态）可以和时序数据一起查询，避免跨表关联
GIS位置数据有专门的空间索引，可以做"查找附近故障设备"这种查询
JSON字段可以灵活存储巡检报告，而且还能建立索引做快速检索

3.2 真实场景下的复杂查询

光看表结构可能还不够直观，我们看几个实际业务中的查询例子：

场景1：设备异常分析

sql 复制代码

-- 查询过去24小时内，温度超过阈值且振动异常的电机设备
-- 要求：按设备分组，每5分钟聚合一次，只返回异常时间段

WITH abnormal_periods AS (
    SELECT 
        device_id,
        time_bucket('5 minutes', record_time) as time_window,
        AVG(temperature) as avg_temp,
        MAX(vibration_level) as max_vib,
        -- 使用窗口函数判断异常持续时长
        COUNT(*) OVER (PARTITION BY device_id ORDER BY record_time) as anomaly_count
    FROM power_plant_monitoring
    WHERE record_time >= NOW() - INTERVAL '24 hours'
        AND device_id LIKE 'motor_%'  -- 电机设备
        AND temperature > 85.0  -- 温度阈值
        AND vibration_level > 5  -- 振动阈值
    GROUP BY device_id, time_window
    HAVING AVG(temperature) > 80.0  -- 5分钟内平均温度阈值
)
SELECT 
    device_id,
    MIN(time_window) as first_anomaly,
    MAX(time_window) as last_anomaly,
    COUNT(*) as total_windows,
    -- 从JSON字段中提取设备信息
    (SELECT value->>'model' 
     FROM power_plant_monitoring p 
     WHERE p.device_id = a.device_id 
     AND p.inspection_report IS NOT NULL 
     LIMIT 1) as device_model
FROM abnormal_periods a
WHERE anomaly_count >= 3  -- 至少连续3个时间窗口异常
GROUP BY device_id
ORDER BY total_windows DESC;

这个查询有几个特点：

使用了时间窗口聚合（time_bucket）
结合了时序条件（温度、振动）和设备类型过滤
用窗口函数判断异常持续性
从JSON字段中提取设备型号信息

场景2：空间+时序联合分析

sql 复制代码

-- 查找某个地理区域内，最近发生过告警的设备
-- 这个查询在电网巡检、设备维护中很常用

SELECT 
    p.device_id,
    p.record_time,
    p.temperature,
    p.device_status,
    ST_AsText(p.geo_location) as location,
    -- 计算设备到中心点的距离
    ST_Distance(
        p.geo_location,
        ST_SetSRID(ST_MakePoint(120.12, 30.16), 4326)
    ) as distance_meters,
    -- 从告警详情中提取严重等级
    p.alarm_details->>'severity' as alarm_level,
    p.alarm_details->>'description' as alarm_desc
FROM power_plant_monitoring p
WHERE 
    -- 空间条件：圆形区域（半径2公里）
    ST_DWithin(
        p.geo_location,
        ST_SetSRID(ST_MakePoint(120.12, 30.16), 4326),
        2000  -- 半径2000米
    )
    -- 时间条件：最近7天
    AND p.record_time >= NOW() - INTERVAL '7 days'
    -- 业务条件：有告警记录
    AND p.alarm_details IS NOT NULL
    -- JSON字段查询：严重等级>=2的告警
    AND (p.alarm_details->>'severity')::INT >= 2
ORDER BY p.record_time DESC
LIMIT 100;

这种"空间+时间+业务属性"的多维查询，在传统的时序数据库里很难高效执行，但在金仓里却可以很好地支持。

3.3 压缩与存储：真能省这么多钱吗？

存储成本是时序数据库逃不开的话题。现在硬盘是不贵，但当数据量到PB级别时，存储成本还是很可观的。

金仓在存储优化上做了不少工作。除了常见的列存压缩，还有一些针对时序场景的特殊优化：

数据生命周期管理实战：

sql 复制代码

-- 创建一个自动化的数据分级存储策略
-- 这个策略在我们的项目中，让存储成本降低了40%

-- 1. 创建主表（存储最近3个月的热数据）
CREATE TABLE telemetry_data (
    ts TIMESTAMPTZ NOT NULL,
    device_id INTEGER NOT NULL,
    value DOUBLE PRECISION,
    quality INTEGER
) PARTITION BY RANGE (ts);

-- 2. 热数据分区（SSD存储）
CREATE TABLE telemetry_hot PARTITION OF telemetry_data
FOR VALUES FROM ('2025-01-01') TO ('2025-04-01')
WITH (storage_type = 'ssd');

-- 3. 温数据分区（普通硬盘，压缩比中等）
CREATE TABLE telemetry_warm PARTITION OF telemetry_data
FOR VALUES FROM ('2024-10-01') TO ('2025-01-01')
WITH (
    storage_type = 'hdd',
    compression = 'medium',
    compress_level = 5
);

-- 4. 冷数据分区（高压缩，低成本存储）
CREATE TABLE telemetry_cold PARTITION OF telemetry_data
FOR VALUES FROM ('2024-01-01') TO ('2024-10-01')
WITH (
    storage_type = 'archive',
    compression = 'high',
    compress_level = 9  -- 最高压缩级别
);

-- 5. 自动化分区管理函数
CREATE OR REPLACE FUNCTION manage_telemetry_partitions()
RETURNS void AS $$
DECLARE
    current_month DATE := DATE_TRUNC('month', CURRENT_DATE);
    hot_start DATE := current_month - INTERVAL '3 months';
    hot_end DATE := current_month;
    warm_start DATE := current_month - INTERVAL '12 months';
    warm_end DATE := current_month - INTERVAL '3 months';
    cold_start DATE := DATE '2020-01-01';
    cold_end DATE := current_month - INTERVAL '12 months';
BEGIN
    -- 更新分区定义（每月调度执行）
    EXECUTE format('ALTER TABLE telemetry_hot DETACH PARTITION');
    EXECUTE format('ALTER TABLE telemetry_warm DETACH PARTITION');
    
    -- 重新创建分区
    EXECUTE format(
        'CREATE TABLE telemetry_hot PARTITION OF telemetry_data
        FOR VALUES FROM (%L) TO (%L)
        WITH (storage_type = ''ssd'')',
        hot_start, hot_end
    );
    
    EXECUTE format(
        'CREATE TABLE telemetry_warm PARTITION OF telemetry_data
        FOR VALUES FROM (%L) TO (%L)
        WITH (storage_type = ''hdd'', compression = ''medium'')',
        warm_start, warm_end
    );
    
    RAISE NOTICE '分区更新完成：热数据 % 到 %, 温数据 % 到 %',
        hot_start, hot_end, warm_start, warm_end;
END;
$$ LANGUAGE plpgsql;

-- 6. 创建压缩策略（对不同分区的数据使用不同压缩算法）
-- 热数据：轻量压缩，保证查询性能
ALTER TABLE telemetry_hot SET COMPRESSION = 'lz4';

-- 温数据：平衡压缩比和性能
ALTER TABLE telemetry_warm SET COMPRESSION = 'zstd';

-- 冷数据：最大压缩比，节省存储空间
ALTER TABLE telemetry_cold SET COMPRESSION = 'zlib';

在实际项目中，我们按照这个策略实施后，存储效果很明显：

数据类别	原始大小	压缩后大小	压缩比	存储介质	查询延迟
热数据(3个月内)	1TB	600GB	1.7:1	SSD	<100ms
温数据(3-12个月)	4TB	1.2TB	3.3:1	HDD	1-2s
冷数据(1年以上)	10TB	1.5TB	6.7:1	归档存储	5-10s

省了多少钱？ 简单算笔账：假设SSD每TB 2000元，HDD每TB 800元，归档存储每TB 300元。按传统方案（全用SSD）需要15TB×2000=30000元；按分级存储方案需要0.6TB×2000+1.2TB×800+1.5TB×300=1200+960+450=2610元。成本降到原来的1/10以下。

当然，这是理想情况的计算，实际会有些偏差，但成本节省的幅度是实实在在的。

四、行业落地：不只是技术选型，更是系统工程

4.1 电力行业：稳定压倒一切

在电力行业做数据库替换，最大的挑战不是性能，而是稳定性。电网调度系统要求7×24小时不间断运行，RTO（恢复时间目标）通常要求在30秒以内，RPO（数据恢复点目标）要求接近0。

我们在某省级电力公司的项目中，采取了分阶段、双轨并行的迁移策略：

第一阶段：并行运行（3个月）

原有Oracle系统继续运行业务
金仓系统同步接收实时数据
两边都跑，结果比对，发现问题

java 复制代码

-- 双写机制的实现（简化版）
-- 应用层同时写入两个数据库，确保数据一致性

public class DualWriter {
    private OracleWriter oracleWriter;
    private KingbaseWriter kingbaseWriter;
    
    public void writeTelemetryData(TelemetryData data) {
        // 先写Oracle（原有系统）
        try {
            oracleWriter.write(data);
        } catch (Exception e) {
            logger.error("Oracle写入失败", e);
            // 记录失败，但不影响金仓写入
        }
        
        // 再写金仓（新系统）
        try {
            kingbaseWriter.write(data);
        } catch (Exception e) {
            logger.error("金仓写入失败", e);
            // 金仓写入失败需要告警，因为这是未来要依赖的系统
            alertSystem.alert("金仓写入异常", e.getMessage());
        }
        
        // 异步校验数据一致性
        consistencyChecker.asyncCheck(data);
    }
}

第二阶段：读流量切换（1个月）

报表、分析类查询逐步切换到金仓
实时监控类查询还在Oracle
这个阶段主要验证金仓的查询性能

第三阶段：写流量切换（2周）

选择一个业务低峰期（比如春节假期）
停写Oracle，所有写入切到金仓
Oracle作为只读备库运行一段时间

第四阶段：完全切换

确认金仓运行稳定后
Oracle系统下线（但数据保留归档）

整个迁移过程持续了半年左右，期间没有发生业务中断。最关键的是第二阶段，我们发现金仓在某些复杂分析查询上比Oracle快很多，这给了业务部门很大的信心。

4.2 智能制造：实时性的极致要求

在智能制造场景里，对实时性的要求更高。某个汽车零部件厂商的生产线上，我们需要处理毫秒级的数据采集，并且要在100毫秒内完成异常检测和预警。

这里遇到的挑战是：传统的"采集-存储-分析"链路太长，等分析结果出来，可能已经生产出几百个不合格品了。

我们的解决方案是：在金仓内部实现流式处理。

sql 复制代码

-- 使用物化视图实现近实时聚合
-- 这个方案把分钟级延迟降到秒级

-- 1. 创建原始数据表
CREATE TABLE sensor_raw (
    ts TIMESTAMPTZ NOT NULL,
    line_id INTEGER NOT NULL,
    station_id INTEGER NOT NULL,
    sensor_id INTEGER NOT NULL,
    value DOUBLE PRECISION,
    status INTEGER
);

-- 2. 创建秒级聚合的物化视图
CREATE MATERIALIZED VIEW sensor_1s_agg
WITH (timescaledb.continuous) AS
SELECT 
    time_bucket('1 second', ts) as bucket,
    line_id,
    station_id,
    sensor_id,
    COUNT(*) as sample_count,
    AVG(value) as avg_value,
    MIN(value) as min_value,
    MAX(value) as max_value,
    STDDEV(value) as std_value
FROM sensor_raw
GROUP BY time_bucket('1 second', ts), line_id, station_id, sensor_id;

-- 3. 创建分钟级聚合（基于秒级聚合）
CREATE MATERIALIZED VIEW sensor_1min_agg
WITH (timescaledb.continuous) AS
SELECT 
    time_bucket('1 minute', bucket) as bucket,
    line_id,
    station_id,
    sensor_id,
    SUM(sample_count) as total_samples,
    AVG(avg_value) as avg_value,
    MIN(min_value) as min_value,
    MAX(max_value) as max_value
FROM sensor_1s_agg
GROUP BY time_bucket('1 minute', bucket), line_id, station_id, sensor_id;

-- 4. 异常检测规则（直接在数据库内实现）
CREATE OR REPLACE FUNCTION check_quality_anomaly()
RETURNS TRIGGER AS $$
BEGIN
    -- 规则1：连续3个点超出控制限
    IF NEW.avg_value > (SELECT upper_limit FROM control_limits 
                       WHERE sensor_id = NEW.sensor_id) THEN
        INSERT INTO quality_alerts (sensor_id, ts, alert_type, value)
        VALUES (NEW.sensor_id, NEW.bucket, 'UPPER_LIMIT', NEW.avg_value);
    END IF;
    
    -- 规则2：标准差突增（过程不稳定）
    IF NEW.std_value > (SELECT avg_std * 2 FROM sensor_stats 
                       WHERE sensor_id = NEW.sensor_id) THEN
        INSERT INTO quality_alerts (sensor_id, ts, alert_type, value)
        VALUES (NEW.sensor_id, NEW.bucket, 'INSTABILITY', NEW.std_value);
    END IF;
    
    -- 规则3：趋势性上升/下降
    -- ... 更多业务规则
    
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

-- 5. 创建触发器（数据入库即检测）
CREATE TRIGGER detect_anomaly_trigger
AFTER INSERT ON sensor_1s_agg
FOR EACH ROW
EXECUTE FUNCTION check_quality_anomaly();

这个方案的精髓在于：把计算推到离数据最近的地方。不需要把数据导出到Spark或Flink做计算，在数据库内部就完成了从原始数据到业务告警的整个链条。

实施效果很明显：质量异常的检测延迟从原来的2-3分钟降到3-5秒，每年减少的质量损失大约在200万元左右。

4.3 遇到的坑和填坑经验

当然，项目过程中也踩了不少坑，这里分享几个典型的：

坑1：默认配置不适合时序场景

金仓默认是为OLTP场景优化的，直接拿来存时序数据，性能上不去。需要调整几个关键参数：

sql 复制代码

-- 这些调整在我们的项目中很关键
ALTER SYSTEM SET shared_buffers = '8GB';  -- 加大共享缓冲区
ALTER SYSTEM SET wal_buffers = '16MB';    -- WAL缓冲区
ALTER SYSTEM SET checkpoint_timeout = '30min';  -- 减少检查点频率
ALTER SYSTEM SET max_wal_size = '10GB';   -- 增大WAL空间
ALTER SYSTEM SET min_wal_size = '2GB';

-- 时序表特有的设置
ALTER TABLE sensor_data SET (
    timescaledb.compress = true,
    timescaledb.compress_orderby = 'time DESC',
    timescaledb.compress_segmentby = 'device_id'
);

坑2：分区策略设计不合理

初期我们按时间做了分区，但查询时发现性能提升不明显。后来才发现，需要按时间和业务维度做复合分区：

sql 复制代码

-- 不好的设计：只按时间分区
CREATE TABLE bad_design (
    device_id INTEGER,
    ts TIMESTAMPTZ,
    value DOUBLE PRECISION
) PARTITION BY RANGE (ts);  -- 只按时间分区

-- 好的设计：时间+设备复合分区
CREATE TABLE good_design (
    device_id INTEGER,
    ts TIMESTAMPTZ,
    value DOUBLE PRECISION
) 
-- 第一级：按月分区
PARTITION BY RANGE (ts) 
-- 第二级：按设备ID哈希分区
SUBPARTITION BY HASH (device_id)
SUBPARTITIONS 8;

坑3：索引滥用导致写入变慢

时序场景的写入量很大，如果索引建得太多，写入性能会严重下降。我们的经验是：

sql 复制代码

-- 必需的索引（查询必须用到的）
CREATE INDEX idx_time_device ON metrics (ts DESC, device_id);

-- 可选的索引（根据查询频率决定是否创建）
CREATE INDEX idx_device_time ON metrics (device_id, ts DESC)
WHERE device_id IN (SELECT device_id FROM important_devices);  -- 只对重要设备建索引

-- 应该避免的索引
-- CREATE INDEX idx_value ON metrics (value);  -- 时序场景很少按值查询
-- CREATE INDEX idx_all_fields ON metrics (ts, device_id, value, tag1, tag2);  -- 复合索引字段太多

五、迁移实战：老系统改造不是简单的"替换"

5.1 迁移前的准备工作

数据库迁移不是技术活，更是管理活。我们在多次迁移项目中总结了一套"三看三问"的方法：

一看数据量：

总数据量有多大？热数据、温数据、冷数据各占多少？
每日增量是多少？峰值写入压力有多大？
数据保留策略是什么？需要迁移全部数据还是最近几年的？

二看业务场景：

有哪些关键业务依赖这个数据库？
业务的SLA要求是什么？（99.9%还是99.99%？）
有没有特别复杂的查询或存储过程？

三看技术栈：

应用层用的是哪些框架和技术？
有没有用到数据库特有的功能（比如特定的函数、语法）？
团队的技能栈是什么？对金仓的了解程度如何？

一问业务连续性：

可以接受多长的停机时间？
有没有业务低峰期可以用于切换？
回滚方案是什么？需要多长时间？

二问数据一致性：

数据一致性要求有多高？强一致还是最终一致？
有没有数据稽核的要求？
迁移过程中的数据同步怎么保证？

三问性能预期：

迁移后性能目标是持平、提升还是可以接受一定下降？
有没有性能基线数据？
关键业务查询的响应时间要求是多少？

5.2 迁移工具的选择和使用

金仓提供了完整的迁移工具链，但根据我们的经验，没有哪个工具是万能的。不同场景要用不同的工具：

场景1：同构迁移（从其他金仓实例迁移）

用kdump和krestore最快
支持在线迁移，业务影响小

场景2：异构迁移（从Oracle/MySQL迁移）

用KDTS（金仓数据迁移服务）
要特别注意数据类型映射和函数替换

bash 复制代码

# KDTS迁移命令示例
# 这个命令执行全量迁移
kdts_migrate \
  --source-type oracle \
  --source-host 192.168.1.100 \
  --source-db source_db \
  --target-type kingbase \
  --target-host 192.168.1.200 \
  --target-db target_db \
  --parallel 8 \  # 并行度
  --batch-size 5000 \  # 批量大小
  --log-level INFO

# 增量迁移（基于CDC）
kdts_cdc \
  --source-type oracle \
  --source-host 192.168.1.100 \
  --target-type kingbase \
  --target-host 192.168.1.200 \
  --tables "schema1.table1,schema1.table2" \
  --start-scn 12345678  # 从指定SCN开始

场景3：有业务逻辑的迁移

需要代码层面的适配
建议分阶段进行：先迁数据，再迁逻辑

java 复制代码

// Oracle特有的函数需要改写
// 迁移前（Oracle）
String query = "SELECT * FROM orders WHERE created_date >= SYSDATE - 7";

// 迁移后（金仓）
String query = "SELECT * FROM orders WHERE created_date >= NOW() - INTERVAL '7 days'";

// Oracle的分页写法
String oraclePaging = "SELECT * FROM (" +
                      "  SELECT t.*, ROWNUM rn FROM (" +
                      "    SELECT * FROM orders ORDER BY id" +
                      "  ) t WHERE ROWNUM <= 100" +
                      ") WHERE rn > 50";

// 金仓的分页写法（更标准）
String kingbasePaging = "SELECT * FROM orders ORDER BY id LIMIT 50 OFFSET 50";

5.3 迁移后的验证和优化

迁移完成不是终点，而是优化的起点。我们有套"迁移后101检查清单"：

1. 数据一致性验证

sql 复制代码

-- 1.1 记录数比对
SELECT '源表' as source, COUNT(*) as count FROM oracle_table@dblink
UNION ALL
SELECT '目标表', COUNT(*) FROM kingbase_table;

-- 1.2 抽样数据比对（随机抽1000行）
WITH oracle_sample AS (
    SELECT * FROM oracle_table@dblink 
    ORDER BY DBMS_RANDOM.VALUE 
    FETCH FIRST 1000 ROWS ONLY
),
kingbase_sample AS (
    SELECT * FROM kingbase_table 
    ORDER BY RANDOM() 
    LIMIT 1000
)
SELECT 
    '数据不一致' as issue,
    o.id,
    o.column1 as oracle_val,
    k.column1 as kingbase_val
FROM oracle_sample o
JOIN kingbase_sample k ON o.id = k.id
WHERE o.column1 != k.column1 OR (o.column1 IS NULL AND k.column1 IS NOT NULL);

-- 1.3 统计信息比对
SELECT 
    column_name,
    oracle_min,
    kingbase_min,
    oracle_max,
    kingbase_max,
    oracle_avg,
    kingbase_avg
FROM (
    SELECT 
        'temperature' as column_name,
        MIN(temperature) as oracle_min,
        NULL as kingbase_min,
        MAX(temperature) as oracle_max,
        NULL as kingbase_max,
        AVG(temperature) as oracle_avg,
        NULL as kingbase_avg
    FROM oracle_table@dblink
    UNION ALL
    SELECT 
        'temperature',
        NULL,
        MIN(temperature),
        NULL,
        MAX(temperature),
        NULL,
        AVG(temperature)
    FROM kingbase_table
) stats;

2. 性能基线对比

sql 复制代码

-- 2.1 关键查询性能对比
EXPLAIN (ANALYZE, BUFFERS, TIMING)
SELECT * FROM large_table 
WHERE create_time >= '2025-01-01'
  AND status = 'ACTIVE'
ORDER BY id DESC
LIMIT 100;

-- 2.2 写入性能测试
INSERT INTO test_performance (id, data, create_time)
SELECT 
    generate_series(1, 1000000),
    md5(random()::text),
    NOW() - (random() * interval '365 days')
RETURNING COUNT(*);

-- 2.3 并发测试（模拟50个并发用户）
SELECT run_concurrent_test(
    test_query := 'SELECT * FROM orders WHERE user_id = $1',
    params_list := ARRAY(SELECT generate_series(1, 1000)),
    concurrency := 50
);

3. 监控告警设置

sql 复制代码

-- 3.1 慢查询监控
CREATE TABLE slow_query_log (
    id SERIAL PRIMARY KEY,
    query_text TEXT,
    execution_time INTERVAL,
    rows_returned INTEGER,
    timestamp TIMESTAMPTZ DEFAULT NOW()
);

-- 3.2 自动收集统计信息
CREATE OR REPLACE FUNCTION auto_analyze_tables()
RETURNS void AS $$
DECLARE
    table_record RECORD;
BEGIN
    FOR table_record IN 
        SELECT schemaname, tablename 
        FROM pg_tables 
        WHERE schemaname NOT IN ('pg_catalog', 'information_schema')
    LOOP
        EXECUTE format('ANALYZE %I.%I', 
                      table_record.schemaname, 
                      table_record.tablename);
        RAISE NOTICE 'Analyzed table: %.%', 
                     table_record.schemaname, 
                     table_record.tablename;
    END LOOP;
END;
$$ LANGUAGE plpgsql;

-- 每天凌晨执行统计信息收集
SELECT cron.schedule('0 2 * * *', 'SELECT auto_analyze_tables()');

六、运维经验：让数据库稳定运行

6.1 监控体系搭建

数据库迁移上线后，运维监控是重中之重。我们的监控体系分为四个层次：

第一层：基础健康度监控

sql 复制代码

-- 关键指标采集
SELECT 
    now() as timestamp,
    -- 连接数
    (SELECT COUNT(*) FROM pg_stat_activity) as total_connections,
    (SELECT COUNT(*) FROM pg_stat_activity WHERE state = 'active') as active_connections,
    
    -- 事务统计
    xact_commit as commits,
    xact_rollback as rollbacks,
    
    -- 缓冲区命中率
    CASE 
        WHEN blks_read + blks_hit > 0 
        THEN round(blks_hit * 100.0 / (blks_read + blks_hit), 2)
        ELSE 100 
    END as buffer_hit_ratio,
    
    -- 锁等待
    (SELECT COUNT(*) FROM pg_locks WHERE granted = false) as waiting_locks,
    
    -- 检查点信息
    checkpoints_timed as timed_checkpoints,
    checkpoints_req as requested_checkpoints,
    
    -- WAL信息
    wal_written / 1024 / 1024 as wal_written_mb
FROM pg_stat_database 
WHERE datname = current_database();

第二层：性能监控

sql 复制代码

-- 慢查询TOP 10
SELECT 
    query,
    calls,
    total_time,
    mean_time,
    rows,
    shared_blks_hit,
    shared_blks_read
FROM pg_stat_statements 
WHERE query !~* '^($|BEGIN|COMMIT|ROLLBACK|SET|SHOW|COPY)'
ORDER BY total_time DESC 
LIMIT 10;

-- 表级别性能统计
SELECT 
    schemaname,
    relname,
    seq_scan,
    seq_tup_read,
    idx_scan,
    idx_tup_fetch,
    n_tup_ins,
    n_tup_upd,
    n_tup_del,
    n_live_tup,
    n_dead_tup,
    -- 死元组比例（超过20%需要清理）
    CASE 
        WHEN n_live_tup + n_dead_tup > 0 
        THEN round(n_dead_tup * 100.0 / (n_live_tup + n_dead_tup), 2)
        ELSE 0 
    END as dead_tuple_ratio
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC;

第三层：容量监控

sql 复制代码

-- 数据库容量监控
SELECT 
    datname as database,
    pg_size_pretty(pg_database_size(datname)) as size,
    -- 增长率（与7天前对比）
    pg_database_size(datname) / 
        NULLIF(pg_database_size(datname, 7), 0) * 100 as growth_pct
FROM pg_database 
WHERE datname NOT IN ('template0', 'template1', 'postgres');

-- 表空间使用情况
SELECT 
    tablespace,
    pg_size_pretty(total_bytes) as total,
    pg_size_pretty(used_bytes) as used,
    pg_size_pretty(free_bytes) as free,
    round(used_bytes * 100.0 / total_bytes, 2) as used_pct
FROM (
    SELECT 
        spcname as tablespace,
        pg_tablespace_size(spcname) as total_bytes,
        pg_tablespace_size(spcname) - 
            (SELECT COALESCE(SUM(pg_relation_size(relid)), 0) 
             FROM pg_class WHERE reltablespace = (SELECT oid FROM pg_tablespace WHERE spcname = spcname)
            ) as free_bytes,
        (SELECT COALESCE(SUM(pg_relation_size(relid)), 0) 
         FROM pg_class WHERE reltablespace = (SELECT oid FROM pg_tablespace WHERE spcname = spcname)
        ) as used_bytes
    FROM pg_tablespace
) t;

第四层：业务监控

sql 复制代码

-- 关键业务指标监控
WITH business_metrics AS (
    -- 今日订单量
    SELECT '今日订单量' as metric, COUNT(*) as value
    FROM orders 
    WHERE created_date >= CURRENT_DATE
    
    UNION ALL
    
    -- 正在处理的订单
    SELECT '处理中订单', COUNT(*)
    FROM orders 
    WHERE status IN ('PROCESSING', 'PENDING')
    
    UNION ALL
    
    -- 过去1小时异常订单
    SELECT '异常订单数', COUNT(*)
    FROM orders 
    WHERE status = 'ERROR' 
      AND created_date >= NOW() - INTERVAL '1 hour'
    
    UNION ALL
    
    -- 数据库响应时间（P95）
    SELECT '查询P95响应时间', 
           PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY total_time / calls)
    FROM pg_stat_statements 
    WHERE query !~* '^($|BEGIN|COMMIT|ROLLBACK|SET|SHOW)'
      AND calls > 100
)
SELECT * FROM business_metrics;

6.2 备份恢复策略

时序数据的备份和普通数据库不一样，数据量大、变化快。我们的策略是：

python 复制代码

#!/bin/bash
#!/bin/bash
# 金仓时序数据库备份脚本
# 采用全量+增量+归档三级备份策略

# 备份目录结构
# /backup/
#   ├── full/          # 全量备份
#   ├── incremental/   # 增量备份  
#   └── archive/       # WAL归档

BACKUP_DIR="/backup/kingbase"
FULL_BACKUP_DIR="$BACKUP_DIR/full"
INC_BACKUP_DIR="$BACKUP_DIR/incremental"
ARCHIVE_DIR="$BACKUP_DIR/archive"
LOG_FILE="$BACKUP_DIR/backup_$(date +%Y%m%d).log"

# 数据库配置
DB_HOST="localhost"
DB_PORT="54321"
DB_NAME="iot_db"
DB_USER="backup_user"

# 创建目录
mkdir -p $FULL_BACKUP_DIR $INC_BACKUP_DIR $ARCHIVE_DIR

# 日志函数
log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a $LOG_FILE
}

# 全量备份（每周日执行）
full_backup() {
    log "开始全量备份"
    local backup_file="$FULL_BACKUP_DIR/full_$(date +%Y%m%d_%H%M%S).backup"
    
    # 使用并行备份加速
    kdump -h $DB_HOST -p $DB_PORT -U $DB_USER -d $DB_NAME \
        -F c \  # 自定义格式
        -j 4 \  # 4个并行进程
        -v \    # 详细输出
        -f $backup_file
    
    if [ $? -eq 0 ]; then
        log "全量备份成功: $backup_file"
        # 备份完成后清理旧的全量备份（保留最近4个）
        ls -t $FULL_BACKUP_DIR/full_*.backup | tail -n +5 | xargs rm -f
    else
        log "全量备份失败"
        exit 1
    fi
}

# 增量备份（每天执行，周日除外）
incremental_backup() {
    log "开始增量备份"
    local inc_file="$INC_BACKUP_DIR/inc_$(date +%Y%m%d_%H%M%S).backup"
    local last_backup=$(ls -t $FULL_BACKUP_DIR/full_*.backup $INC_BACKUP_DIR/inc_*.backup 2>/dev/null | head -1)
    
    if [ -z "$last_backup" ]; then
        log "找不到基准备份，执行全量备份"
        full_backup
        return
    fi
    
    # 基于最近备份做增量
    kdump -h $DB_HOST -p $DB_PORT -U $DB_USER -d $DB_NAME \
        -F c \
        --incremental \
        --base-backup=$last_backup \
        -f $inc_file
    
    if [ $? -eq 0 ]; then
        log "增量备份成功: $inc_file"
        # 清理旧的增量备份（保留最近7天）
        find $INC_BACKUP_DIR -name "inc_*.backup" -mtime +7 -delete
    else
        log "增量备份失败"
        exit 1
    fi
}

# WAL归档（持续进行）
wal_archiving() {
    # 配置在kingbase.conf中
    # archive_mode = on
    # archive_command = '/path/to/this/script/wal_archive.sh %p %f'
    
    local wal_path=$1
    local wal_file=$2
    local archive_file="$ARCHIVE_DIR/$wal_file"
    
    # 复制WAL文件到归档目录
    cp $wal_path $archive_file
    
    # 压缩归档文件（节省空间）
    gzip $archive_file
    
    # 清理旧的WAL归档（保留最近30天）
    find $ARCHIVE_DIR -name "*.gz" -mtime +30 -delete
    
    log "WAL归档完成: $wal_file"
}

# 恢复测试（每月执行一次）
recovery_test() {
    log "开始恢复测试"
    local test_dir="/tmp/recovery_test_$(date +%Y%m%d)"
    mkdir -p $test_dir
    
    # 1. 找到最新的全量备份
    local latest_full=$(ls -t $FULL_BACKUP_DIR/full_*.backup | head -1)
    if [ -z "$latest_full" ]; then
        log "没有找到全量备份文件"
        return 1
    fi
    
    # 2. 找到该全量备份之后的增量备份
    local base_date=$(echo $latest_full | grep -o '[0-9]\{8\}_[0-9]\{6\}')
    local incremental_backups=$(find $INC_BACKUP_DIR -name "inc_*.backup" -newer $latest_full | sort)
    
    # 3. 创建测试实例
    log "恢复全量备份: $latest_full"
    krestore -h localhost -p 54322 -U postgres -d recovery_test \
        -C \  # 创建数据库
        -v \
        $latest_full
    
    # 4. 应用增量备份
    for inc_backup in $incremental_backups; do
        log "应用增量备份: $inc_backup"
        krestore -h localhost -p 54322 -U postgres -d recovery_test \
            --incremental \
            -v \
            $inc_backup
    done
    
    # 5. 验证数据
    log "验证恢复的数据..."
    kingbase -h localhost -p 54322 -U postgres -d recovery_test \
        -c "SELECT COUNT(*) as table_count FROM pg_tables WHERE schemaname = 'public';" \
        -c "SELECT COUNT(*) as total_rows FROM (SELECT * FROM generate_series(1, 100) as id) as test;" \
        >> $test_dir/verify.log
    
    # 6. 清理测试环境
    kingbase -h localhost -p 54322 -U postgres \
        -c "DROP DATABASE IF EXISTS recovery_test;"
    rm -rf $test_dir
    
    log "恢复测试完成"
}

# 主逻辑
case "$1" in
    "full")
        full_backup
        ;;
    "incremental")
        incremental_backup
        ;;
    "wal")
        wal_archiving "$2" "$3"
        ;;
    "test-recovery")
        recovery_test
        ;;
    "auto")
        # 自动判断备份类型
        if [ $(date +%u) -eq 7 ]; then  # 周日
            full_backup
        else
            incremental_backup
        fi
        ;;
    *)
        echo "用法: $0 {full|incremental|wal|test-recovery|auto}"
        exit 1
        ;;
esac

# 备份完成通知
if [ $? -eq 0 ]; then
    # 发送成功通知（可选）
    # send_notification "备份成功: $(date)"
    log "备份任务完成"
else
    # 发送失败告警
    # send_notification "备份失败: $(date)"
    log "备份任务失败"
    exit 1
fi

这个备份策略有几个关键点：

全量+增量结合：每周全量，每天增量，平衡备份时间和存储空间
WAL持续归档：保证可以恢复到任意时间点
定期恢复测试：确保备份真的可用
自动清理：防止备份文件无限增长

6.3 常见问题排查

在实际运维中，我们遇到的最常见问题：

问题1：查询突然变慢

排查步骤：

sql 复制代码

-- 1. 查看当前活动查询
SELECT 
    pid,
    usename,
    application_name,
    client_addr,
    state,
    query,
    now() - query_start as duration
FROM pg_stat_activity 
WHERE state != 'idle'
ORDER BY duration DESC;

-- 2. 查看锁等待
SELECT 
    blocked.pid as blocked_pid,
    blocked.query as blocked_query,
    blocking.pid as blocking_pid,
    blocking.query as blocking_query
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked ON blocked_locks.pid = blocked.pid
JOIN pg_catalog.pg_locks blocking_locks ON blocking_locks.locktype = blocked_locks.locktype
    AND blocking_locks.database IS NOT DISTINCT FROM blocked_locks.database
    AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
    AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
    AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
    AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
    AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
    AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
    AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
    AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
    AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking ON blocking_locks.pid = blocking.pid
WHERE NOT blocked_locks.granted;

-- 3. 查看表膨胀情况
SELECT 
    schemaname,
    relname,
    n_live_tup,
    n_dead_tup,
    round(n_dead_tup * 100.0 / (n_live_tup + n_dead_tup), 2) as dead_pct
FROM pg_stat_user_tables
WHERE n_live_tup + n_dead_tup > 10000
ORDER BY n_dead_tup DESC
LIMIT 10;

-- 4. 手动执行VACUUM（如果死元组太多）
VACUUM (VERBOSE, ANALYZE) problem_table;

问题2：磁盘空间不足

处理方案：

sql 复制代码

-- 1. 找出占用空间最多的表
SELECT 
    schemaname,
    tablename,
    pg_size_pretty(pg_total_relation_size(schemaname||'.'||tablename)) as total_size,
    pg_size_pretty(pg_relation_size(schemaname||'.'||tablename)) as table_size,
    pg_size_pretty(pg_total_relation_size(schemaname||'.'||tablename) - 
                  pg_relation_size(schemaname||'.'||tablename)) as index_size
FROM pg_tables
WHERE schemaname NOT IN ('pg_catalog', 'information_schema')
ORDER BY pg_total_relation_size(schemaname||'.'||tablename) DESC
LIMIT 10;

-- 2. 如果是时序数据，考虑清理历史数据
-- 删除3个月前的数据
DELETE FROM sensor_data 
WHERE ts < NOW() - INTERVAL '3 months';

-- 或者使用分区删除（更快）
-- 先分离旧分区
ALTER TABLE sensor_data DETACH PARTITION sensor_data_2024_01;
-- 然后直接删除分区表
DROP TABLE sensor_data_2024_01;

-- 3. 重建索引释放空间
REINDEX (VERBOSE) TABLE large_table;

-- 4. 清理WAL归档（如果归档太多）
-- 查看WAL归档目录大小
du -sh /kingbase/archive/
-- 删除3天前的归档
find /kingbase/archive/ -type f -mtime +3 -delete;

问题3：内存使用过高

优化建议：

sql 复制代码

-- 1. 调整内存参数（需要重启）
-- kingbase.conf 中调整：
-- shared_buffers = 8GB  # 建议为总内存的25%
-- work_mem = 64MB       # 每个查询可用的内存
-- maintenance_work_mem = 1GB  # 维护操作使用的内存
-- effective_cache_size = 24GB  # 系统缓存大小

-- 2. 查看内存使用详情
SELECT 
    name,
    setting,
    unit,
    short_desc
FROM pg_settings 
WHERE name LIKE '%memory%' 
   OR name LIKE '%cache%'
ORDER BY name;

-- 3. 查看缓存命中率
SELECT 
    sum(heap_blks_read) as heap_read,
    sum(heap_blks_hit) as heap_hit,
    CASE 
        WHEN sum(heap_blks_hit) + sum(heap_blks_read) > 0 
        THEN round(sum(heap_blks_hit) * 100.0 / 
                  (sum(heap_blks_hit) + sum(heap_blks_read)), 2)
        ELSE 0 
    END as heap_hit_ratio,
    sum(idx_blks_read) as idx_read,
    sum(idx_blks_hit) as idx_hit,
    CASE 
        WHEN sum(idx_blks_hit) + sum(idx_blks_read) > 0 
        THEN round(sum(idx_blks_hit) * 100.0 / 
                  (sum(idx_blks_hit) + sum(idx_blks_read)), 2)
        ELSE 0 
    END as idx_hit_ratio
FROM pg_statio_user_tables;

-- 4. 如果缓存命中率低，考虑增加shared_buffers