4. 数据存储架构：时序数据库选型、列式存储设计、分区策略

Tick 数据具有高频、海量、时间有序、不可变等特征。在坏账率监测与漂移哨兵场景中，存储层需要同时支撑高吞吐写入、快速聚合查询以及长时间序列的滚动管理。本章从时序数据库选型、列式存储设计与分区策略三个维度，构建适合 Tick 数据的存储底座。

4.1 时序数据库选型对比

传统关系型数据库（如 MySQL）在 Tick 数据场景下存在写入瓶颈与存储膨胀问题。时序数据库（TSDB）针对时间戳索引、降采样、数据生命周期管理做了专门优化。以下是主流时序数据库在 Tick 场景下的关键能力对比：

4.2 列式存储设计

列式存储是 Tick 数据高性能查询的核心。与行式存储不同，列式存储将同一列的数据连续存放，在聚合查询（如 SUM、AVG、COUNT）时只需读取相关列，大幅减少 I/O。同时，同列数据的类型一致，便于使用高效的压缩算法。

4.2.1 Tick 数据列族设计

以 ClickHouse 为例，Tick 数据表通常按“标签列 + 时间列 + 指标列”进行设计：

CREATE TABLE tick_metrics (
    symbol      String,          -- 标的代码（标签列）
    exchange    String,          -- 交易所（标签列）
    tick_time   DateTime64(3),   -- Tick 时间（时间列）
    price       Float64,         -- 最新价（指标列）
    volume      UInt64,          -- 成交量（指标列）
    bid_price   Float64,         -- 买一价（指标列）
    ask_price   Float64,         -- 卖一价（指标列）
    bad_rate    Float32,         -- 坏账率（衍生指标列）
    drift_flag  UInt8            -- 漂移标记（衍生指标列）
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(tick_time)
ORDER BY (symbol, tick_time);

4.2.2 压缩策略对比

4.3 分区策略

分区是 Tick 数据存储架构中管理数据生命周期与提升查询性能的关键手段。合理的分区策略可以减少查询扫描的数据量，同时支持高效的数据过期删除。

4.3.1 时间分区

Tick 数据天然按时间排序，最常用的分区键是时间字段。根据数据量与查询粒度，推荐以下分区方案：

• 按天分区： 适用于日查询频率高、数据量在 TB 级以下的场景。分区粒度细，便于按天删除过期数据。
• 按月分区： 适用于历史回溯分析、数据量在 PB 级以上的场景。分区数量少，管理开销低，但单分区数据量大。
• 按周分区： 折中方案，适用于中等规模且需要周度聚合的场景。

-- ClickHouse 按月分区示例
PARTITION BY toYYYYMM(tick_time)

-- TDengine 按天分区示例（自动创建）
CREATE TABLE tick_metrics USING tick_metrics_template TAGS('AAPL')
  PARTITION BY DAY;

4.3.2 二级分区（标签分区）

在时间分区的基础上，可以按标的代码（symbol）或交易所（exchange）进行二级分区，进一步减少查询扫描范围。ClickHouse 支持通过 SAMPLE BY 或 PARTITION BY 表达式实现多级分区。

4.4 存储架构总览

下图展示了 Tick 数据从写入到存储的完整架构，包含列式存储、分区策略与压缩算法的协同工作流程：

4.5 分区与查询性能关系

分区策略直接影响查询性能。以下实验数据基于 10 亿条 Tick 数据，对比不同分区方案下的查询耗时：

4.6 存储架构决策清单

在实施 Tick 数据存储架构时，请按以下清单逐项确认：

1. 选型确认： 是否选择了支持列式存储与高压缩比的时序数据库？
2. 列族设计： 标签列、时间列、指标列是否分离？衍生指标是否在写入时预计算？
3. 压缩策略： 数值列是否使用 DoubleDelta 或 Gorilla 压缩？标签列是否使用字典编码？
4. 分区键选择： 一级分区是否为时间字段？二级分区是否为高频过滤字段？
5. TTL 策略： 是否配置了自动过期策略？保留周期是否与业务需求对齐？
6. 查询验证： 是否使用典型查询（如坏账率聚合、漂移标记扫描）验证了分区裁剪效果？