时序数据库选型（上）：InfluxDB、TimescaleDB、QuestDB 核心特性对比与适用场景
做量化系统，时序数据库是绕不开的坎。行情数据、订单簿快照、交易记录，全是时间戳打头的玩意儿。我见过不少团队，一开始图省事用 MySQL 硬扛，结果数据量一上来，查询慢得像蜗牛爬，最后不得不推倒重来。
今天咱们聊聊三款主流的时序数据库：InfluxDB、TimescaleDB、QuestDB。它们各有各的脾气，选对了能省不少事。
为什么需要专门的时序数据库？
普通数据库处理时序数据，其实挺吃力的。你想想看，行情数据每秒可能产生几千条记录，每条都带时间戳、价格、成交量。MySQL 用 B+ 树索引，写入一多就卡壳。时序数据库就不一样了，它们针对时间序列做了大量优化。
核心差异点：
- 写入优化：时序数据库通常采用 LSM-Tree 或类似结构，写入吞吐量远高于传统 B+ 树
- 存储压缩：时间戳和数值可以高效压缩，存储成本能降到 MySQL 的 1/10
- 查询优化：时间范围查询、降采样聚合，这些操作在时序数据库里是原生支持的
我个人习惯把时序数据库分成两类：一类是原生时序数据库（InfluxDB、QuestDB），另一类是 PostgreSQL 扩展（TimescaleDB）。这两类在架构上差别很大，选型时要特别注意。
InfluxDB：老牌劲旅，生态最成熟
InfluxDB 是我最早接触的时序数据库。2015 年那会儿，我在一个高频交易项目里用它存储 tick 级行情数据，一用就是好几年。
核心特性：
- 数据模型：measurement + tag + field + timestamp。tag 用于索引，field 存实际数值
- 写入协议：支持 HTTP/Line Protocol，简单粗暴，一行文本就是一条记录
- 查询语言：InfluxQL（类 SQL）和 Flux（函数式），Flux 功能更强但学习曲线陡
- 存储引擎：TSM（Time-Structured Merge Tree），写入性能极佳
我的经验：InfluxDB 的 tag 设计很关键。tag 太多会导致索引膨胀，写入变慢。我一般把 tag 控制在 5 个以内，比如 symbol、exchange、side 这种高频过滤字段。field 可以多，但别把 tag 当 field 用。
适用场景：
- 高频行情数据存储（tick 级、毫秒级）
- 监控指标采集（服务器 CPU、内存、网络）
- IoT 设备数据汇聚
避坑指南：我曾经在 InfluxDB 1.x 版本里遇到过数据丢失的问题。原因是 TSM 文件合并时，如果磁盘空间不足，会直接丢弃旧数据。后来我养成了习惯：磁盘使用率超过 70% 就报警，留足合并空间。
TimescaleDB：PostgreSQL 的时序超能力
TimescaleDB 不是从头造轮子，它是在 PostgreSQL 上加了时序扩展。这意味着什么？你可以在同一个数据库里同时处理时序数据和业务数据，不用搞两套系统。
核心特性：
- 数据模型：完全兼容 PostgreSQL 表结构，只是多了 hypertable 的概念
- 自动分区：按时间自动创建 chunk（分区表），对用户透明
- 查询能力：标准 SQL + 时序函数（time_bucket、first、last 等）
- 存储引擎：底层还是 PostgreSQL 的堆存储，但加了压缩和索引优化
创建 hypertable 示例：
-- 先创建普通表
CREATE TABLE trades (
time TIMESTAMPTZ NOT NULL,
symbol TEXT NOT NULL,
price NUMERIC,
volume NUMERIC
);
-- 转为 hypertable
SELECT create_hypertable('trades', 'time');
-- 按天自动分区，保留 30 天数据
SELECT add_retention_policy('trades', INTERVAL '30 days');我个人觉得 TimescaleDB 最大的优势是生态。PostgreSQL 有的它都有：GIS 扩展、全文搜索、JSON 支持。如果你的量化系统需要同时管理交易记录、用户信息、风控规则，TimescaleDB 能让你少维护一套数据库。
适用场景：
- 需要 SQL 复杂查询的场景（多表 JOIN、窗口函数）
- 时序数据 + 业务数据混合存储
- 团队已经熟悉 PostgreSQL，不想学新语言
避坑指南：TimescaleDB 的写入性能不如 InfluxDB 和 QuestDB。我在一个项目中测试过，单机写入吞吐量大概在 5 万条/秒左右，而 InfluxDB 能到 20 万条/秒。如果你的行情数据量特别大（比如每秒几十万条 tick），TimescaleDB 可能会成为瓶颈。
QuestDB：为低延迟而生的新秀
QuestDB 是近几年冒出来的，主打低延迟和高吞吐。它的设计理念很纯粹：用 Java 实现，但性能直逼 C++ 写的系统。
核心特性：
- 数据模型：类似 InfluxDB，但更简洁。表 + 列 + 时间戳
- 写入协议：支持 InfluxDB Line Protocol、PostgreSQL Wire Protocol、REST API
- 查询语言：标准 SQL + 时序扩展
- 存储引擎：列式存储 + SIMD 指令优化，聚合查询极快
性能数据（来自官方测试）：
| 操作 | QuestDB | InfluxDB | TimescaleDB |
|---|---|---|---|
| 写入吞吐量 | 150 万行/秒 | 50 万行/秒 | 5 万行/秒 |
| 聚合查询（1 亿行） | 50ms | 200ms | 800ms |
| 时间范围查询 | 10ms | 30ms | 100ms |
QuestDB 的列式存储对量化分析特别友好。比如你要计算某只股票过去 1 小时的 VWAP（成交量加权平均价），QuestDB 只需要扫描 price 和 volume 两列，其他列根本不用碰。InfluxDB 虽然也是列式，但它的压缩算法更偏向时间序列，QuestDB 则更通用。
适用场景：
- 超高频行情数据（微秒级 tick）
- 实时计算 + 历史回测一体化
- 对查询延迟要求极高的场景（比如盘口分析）
避坑指南：QuestDB 的社区版有一些限制，比如不支持高可用、不支持多节点集群。我在生产环境用过一次，单机跑没问题，但一旦需要容灾就抓瞎了。如果你对稳定性要求高，建议等企业版或者考虑其他方案。
三款数据库的对比总结
| 维度 | InfluxDB | TimescaleDB | QuestDB |
|---|---|---|---|
| 写入性能 | 高 | 中 | 极高 |
| 查询性能 | 中 | 中（依赖 SQL 优化） | 高 |
| SQL 支持 | 弱（InfluxQL/Flux） | 强（标准 SQL） | 中（标准 SQL 子集） |
| 生态成熟度 | 高 | 高（PostgreSQL 生态） | 低 |
| 运维复杂度 | 中 | 低（PG 运维） | 高（单机为主） |
| 适用数据量 | TB 级 | 百 GB ~ TB 级 | TB 级 |
如何选择？我的建议
没有银弹，只有最适合的。我根据不同的场景给几个建议：
- 如果你做高频交易，tick 级数据量巨大：首选 QuestDB。它的写入和查询性能确实能打，但要做好单机运维的准备。
- 如果你需要 SQL 灵活查询，还要兼顾业务数据：TimescaleDB 是稳妥之选。我现在的量化平台就用它，交易记录、风控规则、行情数据全在一个库里，省心。
- 如果你团队小，想快速上手：InfluxDB 最成熟，文档多，社区活跃。我当年入门时序数据库就是从 InfluxDB 开始的，踩坑少。
重要提醒：别只看性能测试数据。实际生产环境里，网络延迟、磁盘 IO、并发连接数都会影响最终表现。我建议你先用真实数据做一次 POC（概念验证），跑一周看看效果再决定。
知识体系总览
下面这张图梳理了本章的核心逻辑，方便你快速回顾：
嗯，时序数据库选型这个话题，一次讲不完。上面这三款是当前最主流的选择，但还有 ClickHouse、TDengine 等也值得关注。我个人建议，先根据你的数据量和查询需求圈定 1-2 个候选，然后做压力测试。别光看宣传数据，自己跑一遍最靠谱。