3. 因子库存储引擎选型：关系型数据库 vs 列式存储 vs 内存数据库

排放因子库的存储引擎选择直接决定了碳足迹数据刷新的吞吐量与响应延迟。在生产环境中，我们通常在三类引擎中做技术选型：关系型数据库（PostgreSQL / MySQL）、列式存储（ClickHouse） 与 内存数据库（Redis）。三类引擎在数据模型、写入模式、查询特征与扩展能力上存在本质差异，下面从碳足迹场景出发进行系统对比。

3.1 三类引擎的核心差异

3.2 存储引擎架构对比

下图展示了三类引擎在排放因子库中的典型部署位置与数据流向。关系型数据库作为因子元数据的主存储，ClickHouse 承担批量刷新后的分析查询，Redis 则作为热数据缓存层。

3.3 关系型数据库：PostgreSQL vs MySQL

在关系型数据库内部，PostgreSQL 与 MySQL 在因子库场景下的差异主要体现在以下方面：

• JSON / JSONB 支持： PostgreSQL 的 JSONB 支持索引与内部字段查询，适合存储因子来源、置信度、区域标签等半结构化元数据；MySQL 的 JSON 类型功能较弱。
• 并发控制： PostgreSQL 使用 MVCC 实现高并发读写，不会出现写阻塞读；MySQL InnoDB 也使用 MVCC，但在高并发写入时间隙锁冲突更频繁。
• 分区表： PostgreSQL 支持声明式分区（范围、列表、哈希），适合按因子类型或区域做分区裁剪；MySQL 分区功能相对有限。
• 扩展性： PostgreSQL 支持外部数据包装器（FDW），可直接查询 ClickHouse 或 Redis 中的数据；MySQL 的联邦引擎使用较少。

3.4 列式存储 ClickHouse 在因子刷新中的优势

ClickHouse 的列式存储与向量化执行引擎使其在批量因子刷新场景中具备显著优势：

1. 列裁剪： 查询只读取涉及的列，避免读取整行数据。例如计算“电力排放因子平均值”时只需读取 factor_value 一列。
2. 数据压缩： 同列数据类型一致，压缩比可达 5~10 倍，减少 I/O 开销。
3. 向量化计算： CPU 一次处理一批数据（如 1024 行），而非逐行处理，适合大规模聚合。
4. MergeTree 引擎： 数据按主键排序后分区存储，批量插入后后台合并，写入吞吐极高。

-- ClickHouse 创建因子表的典型 DDL
CREATE TABLE emission_factors (
    factor_code    String,
    factor_name    String,
    factor_value   Float64,
    unit           String,
    source         String,
    region         String,
    valid_from     Date,
    valid_to       Date
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(valid_from)
ORDER BY (region, factor_code)
SETTINGS index_granularity = 8192;

3.5 内存数据库 Redis 的缓存加速策略

Redis 在因子库中主要承担热数据缓存与实时计算加速角色，典型使用模式包括：

3.6 混合存储架构推荐

在生产级排放因子库中，我们推荐采用三层混合存储架构：