3、时序数据库入门：InfluxDB、TimescaleDB、QuestDB，为什么传统数据库扛不住高频回测

说实话，我最早做回测的时候，也是用MySQL硬扛的。那时候数据量小，一天几百万条tick数据，MySQL还能勉强跑。后来上了高频策略，一天几千万甚至上亿条数据，MySQL直接崩了——查询一个月的1分钟K线，等了半小时还没出来。

嗯，这就是我们今天要聊的核心问题：为什么传统数据库扛不住高频回测？

3.1 传统数据库的“死穴”

你想想看，传统关系型数据库（MySQL、PostgreSQL）是为OLTP场景设计的。什么叫OLTP？就是银行转账、电商下单这种——数据量不大，但要求强一致性、事务支持。

但量化回测的数据访问模式完全相反：

• 写多读少：回测时一次性写入大量历史数据，之后反复读取
• 按时间范围查询：90%的查询都是“给我2023年1月到3月的5分钟K线”
• 顺序扫描为主：很少随机查询某一条数据

传统数据库的B+树索引，说白了就是为随机查询优化的。你按时间范围查数据，它得先查索引，再回表，再排序——效率极低。

3.2 时序数据库的“三板斧”

我在项目中用过三款主流的时序数据库：InfluxDB、TimescaleDB、QuestDB。它们各有千秋，但核心思路是一致的。

3.2.1 InfluxDB：专为时序而生

InfluxDB是我最早接触的时序数据库。它的设计理念很纯粹——我就是为时序数据设计的，别的我不干。

它的核心优势：

• TSM存储引擎：类似LSM-Tree，写入吞吐极高
• 列式压缩：对时间戳、浮点数做差分编码，压缩比能达到10:1
• 连续查询：自动预聚合，查询时直接拿结果

我记得有个项目，用MySQL存tick数据，一天大概5000万条，磁盘占用30GB。换成InfluxDB后，同样的数据只占3GB，查询速度提升了50倍。

3.2.2 TimescaleDB：PostgreSQL的“时序插件”

TimescaleDB的思路跟InfluxDB完全不同。它不是一个独立的数据库，而是PostgreSQL的一个扩展。

这意味着什么？

• 你仍然可以用标准的SQL
• 可以跟PostgreSQL的其他扩展（比如PostGIS）一起用
• 迁移成本极低

它的核心机制是自动分区（Hypertable）。按时间自动创建子表，查询时只扫描相关分区。

-- 创建一个超表
CREATE TABLE kline_1m (
  time TIMESTAMPTZ NOT NULL,
  symbol TEXT NOT NULL,
  open DOUBLE PRECISION,
  high DOUBLE PRECISION,
  low DOUBLE PRECISION,
  close DOUBLE PRECISION,
  volume BIGINT
);

-- 转换为超表，按时间和symbol分区
SELECT create_hypertable('kline_1m', 'time', 
  chunk_time_interval => INTERVAL '1 day',
  partitioning_column => 'symbol',
  number_partitions => 16
);

我曾经把一个回测系统从原生PostgreSQL迁移到TimescaleDB，只改了表结构定义，查询代码一行没动。迁移后，按时间范围查询的速度提升了20倍。

3.2.3 QuestDB：极致性能

QuestDB是后起之秀，主打极致性能。它的设计理念是“用硬件换性能”——充分利用CPU缓存、SIMD指令、内存映射文件。

它的核心特性：

• 列式存储：按列存储数据，查询时只读取需要的列
• SIMD加速：利用CPU的向量化指令，批量处理数据
• 内存映射：数据文件直接映射到内存，减少系统调用

我做过一个对比测试：查询1000万条tick数据，计算5分钟K线。

数据库	查询时间	内存占用
MySQL	45秒	2.1GB
InfluxDB	3.2秒	800MB
TimescaleDB	2.8秒	1.2GB
QuestDB	0.8秒	450MB

QuestDB的查询速度确实惊人。但它的生态还不够成熟，文档和社区支持相对薄弱。

3.3 如何选择？

嗯，这里我给出一个简单的选择建议：

• 如果你需要完整的SQL支持，选TimescaleDB。它跟PostgreSQL无缝集成，适合复杂查询场景。
• 如果你追求极致写入性能，选InfluxDB。它的写入吞吐是三者中最高的。
• 如果你追求极致查询性能，选QuestDB。但要做好踩坑的准备。

我个人习惯是：中小规模回测用TimescaleDB，大规模高频回测用QuestDB。InfluxDB虽然性能不错，但它的查询语法跟标准SQL差异太大，团队学习成本高。

3.4 核心知识体系

下面这张图展示了时序数据库的核心架构和选择逻辑：

这张图展示了时序数据库的核心架构。从上到下，先理解时序数据的特征，再看三大数据库的存储引擎差异，最后根据场景做选型。

3.5 总结

传统数据库扛不住高频回测，说白了就是存储模型不匹配。时序数据库通过列式存储、自动分区、压缩算法等手段，把时序数据的读写效率提升了几个数量级。

我个人建议：别纠结选哪个，先跑起来再说。选一个你团队最熟悉的，把回测系统搭起来，遇到性能瓶颈再优化。毕竟，数据存进去了，随时可以迁移。