高频期权Tick数据的数据库设计（快速写入+查询性能优化）

阿华AIGC实验室

2026-3-30

嘿，刚好常年跟金融Tick数据打交道，做过类似的印度股指（NIFTY/BANKNIFTY/SENSEX）期权数据仓库，完全贴合你要的快速写入+回测性能需求，给你唠唠最落地的方案：

一、最优Schema设计（核心是让查询/聚合少干活）

1. 时间戳：合并成单个带时区的TIMESTAMP

别分开存Date+Time！提前在CSV预处理阶段把Date和Time拼接成TIMESTAMP WITH TIME ZONE（比如2023-12-23 09:15:00+05:30），导入后直接存成一个字段。这样查询时不用做字符串拼接，聚合/时间范围过滤的速度能提升一大截，还能避免时区混乱（印度时区的坑你懂的）。

2. 字段拆分：别让数据库解析Ticker

你的原Ticker字段（比如NIFTY23DEC2318000CE）一定要拆成独立的可聚合字段，不然每次按Strike/OptionType聚合时都要解析字符串，慢到离谱：

Underlying：枚举类型（NIFTY/BANKNIFTY/SENSEX），避免字符串匹配
ExpiryDate：日期类型，对应期权到期日
Strike：数值类型（比如18000.0），别存字符串
OptionType：枚举类型（CE/PE），直接对应看涨/看跌
保留你原有的业务字段：LTP, BuyPrice, BuyQty, SellPrice, SellQty, LTQ, OpenInterest
新增Timestamp：刚才说的合并后的时间戳

3. 分区策略：按「标的+日期/月份」分区

绝对要分区，不然百万级日数据攒几个月后，全表查询会卡死：

优先选按Underlying + 日期分区（比如NIFTY_20231223），因为你批量导入是每日CSV，写入时直接命中对应分区，不会影响其他分区的查询；回测时按标的+时间范围过滤，直接扫对应分区，不用碰全表。
如果数据量特别大（比如单标的日数据超1000万行），可以升级成按Underlying + 月份分区，减少分区数量（避免分区过多导致的元数据开销）。
注意：分区键一定要是查询时高频用到的过滤条件（标的+时间），不然分区白加。

4. 索引策略：分数据库类型来

OLAP数据库（比如ClickHouse）：不用二级索引！用物化视图和排序键代替。排序键设为(Underlying, ExpiryDate, Strike, OptionType, Timestamp)，这样数据写入时就按这个顺序排序，查询时直接按排序后的顺序扫，聚合速度拉满。
关系型数据库（比如PostgreSQL+TimescaleDB）：用复合覆盖索引，比如CREATE INDEX idx_opt_agg ON ticks (Underlying, ExpiryDate, Strike, OptionType, Timestamp) INCLUDE (LTP, OpenInterest, BuyPrice, SellPrice);，这样聚合查询时直接从索引里拿数据，不用回表扫原始数据。另外加部分索引，比如只给NIFTY的近期数据加索引，减少索引大小。

二、数据库选型：性能优先选这个

1. 首选：ClickHouse

我自己用它跑了3年的NIFTY期权Tick数据，写入速度能到每秒百万级，聚合查询速度是PostgreSQL的10-100倍，完全适配你的回测需求：

天生为时间序列/OLAP优化的列式存储，大表聚合、时间范围查询快到离谱
自带分区、排序键、物化视图，不用额外插件
批量导入CSV的原生支持，直接用clickhouse-client --query="INSERT INTO ticks FORMAT CSV"就能秒导几十万行
缺点：不支持ACID事务，适合批量写入+只读查询的场景（你的需求刚好是这个）

2. 备选：PostgreSQL + TimescaleDB

如果你需要偶尔做一些事务操作（比如修正历史数据），或者要跟其他业务系统对接，选这个：

TimescaleDB是PostgreSQL的时间序列扩展，自动分区、连续聚合，性能比原生PostgreSQL好10倍以上
支持所有PostgreSQL的SQL语法，灵活度高
缺点：写入速度比ClickHouse慢，大表聚合还是不如ClickHouse

避坑：别用MySQL/MongoDB

MySQL：列式存储支持差，大表查询慢到怀疑人生，索引开销大
MongoDB：聚合性能拉胯，不适合大规模金融数据的回测查询

三、最佳实践：让你的系统跑飞起来

1. 批量写入优化

预处理CSV再导入：提前把Date+Time拼成Timestamp，解析Ticker成独立字段，计算好Greeks（别让数据库做这些计算，导入时直接写）
关闭约束检查：批量导入时关闭外键、唯一约束，导入后再打开，避免数据库做额外的校验
用原生导入工具：ClickHouse用clickhouse-client，PostgreSQL用COPY命令，别用ORM框架插入，速度差100倍都不止

2. 数据归档：轻装上阵

把超过1年的旧数据归档到冷存储（比如本地的机械硬盘，或者对象存储），或者用数据库的分区归档功能：

ClickHouse：把旧分区 detach 出来，存到冷存储，需要时再attach回去
PostgreSQL+TimescaleDB：用move_chunk命令把旧数据移到冷存储
这样热数据的查询速度不会被旧数据拖慢

3. 物化视图：预计算代替实时计算

针对你常用的聚合查询（比如按Strike/OptionType的LTP平均值、OpenInterest的最大值），提前创建物化视图：

比如ClickHouse的物化视图：

CREATE MATERIALIZED VIEW mv_opt_daily_agg
ENGINE = MergeTree
PARTITION BY (Underlying, toDate(Timestamp))
ORDER BY (Underlying, ExpiryDate, Strike, OptionType)
AS
SELECT
    Underlying,
    ExpiryDate,
    Strike,
    OptionType,
    toDate(Timestamp) AS Date,
    avg(LTP) AS avg_ltp,
    max(OpenInterest) AS max_oi,
    count(*) AS tick_count
FROM ticks
GROUP BY Underlying, ExpiryDate, Strike, OptionType, toDate(Timestamp)

回测时直接查这个物化视图，不用扫原始数据，速度能提升100倍

4. 回测查询优化

别查所有字段：只查你需要的字段（比如Timestamp, LTP, Strike, OptionType），别用SELECT *，减少数据传输和内存开销
分块并行查询：回测时按时间分块（比如每次查1个月的数据），并行处理，避免一次性加载太大的数据集到内存
预计算Greeks：导入时就计算好Delta/Gamma/Vega等希腊值，存到数据库里，回测时不用实时计算，节省大量CPU时间