有同学让我聊一聊量化数据库选择，这里聊一聊。
今天主要聊聊量化交易中几个常用的数据库：SQLite、DuckDB、MySQL、ClickHouse、TimescaleDB 和 InfluxDB，并根据实际场景做出合适的选择。
一、数据库对比
1. SQLite —— 轻量的嵌入式入门之选
SQLite 是进程内数据库，整个数据库就是一个单一文件，无需独立服务器进程。
**优势**：
- 零配置，零管理，直接嵌入 Python 代码
- 事务完整支持 ACID，回测过程中的中间数据安全可靠
- 读取性能足够好，适合亿行以内的只读查询场景
- 文件格式跨平台，一个 `.db` 文件拷到任何电脑都能直接跑策略
**劣势**：
- 写入并发能力弱，不支持多个进程同时写入
- 数据量超过 10GB 后，写入和查询性能明显下降
- 不适合分布式部署，也没有列式存储优化
适合：个人入门学习、小规模回测、策略原型验证。 个人不推荐，有同学在用， 能解决问题就好。
2、 DuckDB —— 为分析查询而生
DuckDB ，专门为 OLAP 场景设计，在量化研究圈中迅速走红。它和 SQLite 一样是零配置嵌入，但性能天差地别。
优势：
- 列式存储 + 向量化执行引擎，分析查询性能惊人，百万行数据聚合毫秒级响应
- 与 Pandas 无缝集成，支持直接在 DataFrame 上执行 SQL，回测代码极其简洁
- 支持 Parquet、CSV 等文件直接查询，无需先导入数据，极大提升研究效率
- 对 10GB~100GB 级别数据量处理能力远超 SQLite
**劣势**：
- 社区相对年轻，生态不如传统数据库成熟
- 写入性能不如行式存储数据库，不适合高频实时写入
- 不支持分布式部署，单机内存限制可能成为瓶颈
适合：量化研究分析、大规模历史回测、因子计算、替代 SQLite 的升级版
3. MySQL —— 成熟稳定的全能型选手
MySQL 作为最流行的开源关系型数据库，成熟稳定是它最大的标签，在量化交易中适合管理非时序类的业务数据。
**优势**：
- 生态极其完善，工具链丰富，出现问题容易找到解决方案
- 读写并发能力强，支持高并发访问，适合实盘环境下的多策略状态管理
- 提供主从复制、读写分离等成熟方案，保障高可用
- ACID 事务完整，订单、账户等关键数据安全有保障
**劣势**：
- 对时间序列数据缺乏专门优化，大表按时间聚合查询性能下降明显
- 存储空间利用率一般，同样数据量占用空间比列式数据库大数倍
- 配置调优需要一定经验，新手容易踩坑
适合：策略账户管理、订单记录、策略配置存储、用户权限系统。K线数据只适合存储日K数据，更细维度请另做选型。 优点程序员几乎都会
4、 ClickHouse —— 海量时序数据的终极武器
ClickHouse 是真正的列式数据库之王，专为海量数据分析而生，头部量化机构几乎都在用。
优势：
- 压缩比极高，金融 tick 数据通常能达到 5-10 倍压缩率，大幅节省存储成本
- 聚合查询速度极快，十亿行数据上计算 VWAP、标准差等指标秒级返回
- 原生支持分布式部署，可横向扩展至 PB 级别，轻松应对全市场 tick 数据
- 专门针对时间序列优化的 MergeTree 引擎，按时间分区和排序效率极高
**劣势**：
- 运维复杂度高，需要集群管理、ZK 协调等知识，小团队难以驾驭
- 不支持完整的事务 ACID，不适合存储订单等强一致性数据
- 单机模式下优势不明显，小数据量反而显得“杀鸡用牛刀”
- 资源消耗较大，内存、CPU 要求较高
适合：海量历史 tick 数据仓库、全市场因子计算、高频策略回测
5. TimescaleDB —— 关系型与时序的完美结合
TimescaleDB 是基于 PostgreSQL 的时间序列扩展，继承了 PG 的完整关系型能力，又添加了时序优化，堪称全能型时序数据库。
优势：
- 100% 支持 PostgreSQL SQL 语法，可以使用所有 PG 生态工具
- 自动分片（chunking）和时间分区，查询性能远超普通 PG
- 支持连续聚合（continuous aggregates），实时维护物化视图，查询分种、小时 K 线秒级响应
- 完整的 ACID 事务支持，时序数据也可以放心读写
- 单机性能优秀，且支持只读副本扩展，运维复杂度低于 ClickHouse
**劣势**：
- 压缩率和查询速度略逊于 ClickHouse（但仍远优于普通 PG）
- 写入吞吐量在高频 tick 场景下需要调优，不如专有时序数据库极致
- 时间分区管理需要一定学习成本
适合：中小团队实盘环境、需要同时做 OLTP 和 OLAP 的混合场景、分钟/秒级 K 线存储
6. InfluxDB —— 专注时序的极致性能派
InfluxDB 是专为时序数据设计的数据库，在监控领域广为人知，但其金融时序能力同样不容小觑。
优势：
- 独特的时间结构化合并树（TSM Tree）引擎，写入吞吐量极高，轻松应对每秒百万级数据点
- 内置丰富的时间窗口函数和降采样能力，计算滚动窗口统计非常方便
- Flux 查询语言（以及 InfluxQL）针对时序场景优化，表达力强
- 提供保留策略（Retention Policy）自动过期旧数据，适合实时策略只关心近期数据
- 开源版本可用，企业版提供集群能力
**劣势**：
- 不支持标准 SQL，学习和迁移成本较高
- 缺乏完整的事务支持，不适合存储关键业务数据
- 社区版单机性能很好，但集群功能需要商业授权
- 对于复杂的多表关联查询能力较弱
适合：高频实时 tick 数据摄入、实时策略信号计算、盘后数据快速清洗
二、实战场景选型建议
场景一：个人量化研究
推荐组合：DuckDB + SQLite（可选，可不用）
绝大多数分析工作可以用 DuckDB 直接查询 Parquet 文件完成，完全无需其他数据库。如果仍想保留一套轻量的事务存储，SQLite 可用。
场景二：小型量化团队实盘
推荐组合：TimescaleDB + MySQL
TimescaleDB 作为主数据存储，负责所有历史 K 线和 tick 数据，利用其连续聚合功能实时维护各种周期的 K 线视图。MySQL 负责策略配置、账户、订单等业务数据。
场景三：专业量化机构
推荐组合：ClickHouse + InfluxDB
InfluxDB 作为实时写入缓冲层，高频 tick 先涌入 InfluxDB，利用其超高写入吞吐和保留策略，供实时策略消费。每天收盘后将数据批量转存到 ClickHouse 集群，供研究人员进行全量历史回测和因子挖掘。需要事务的地方仍然可以配合 MySQL。
三、写在最后
量化交易的核心是策略逻辑和风险控制，数据库只是工具。用最简单的方式跑通策略，让数据驱动你的决策，而不是被技术选型绑架。 简单场景，即使不用数据库也没关系。
最近看到的足球段子，我只是为了练习基本功，没想过射门。 是不是类似 我只是想研究量化技术，没想过在市场上赚钱。
如果你对AI量化感兴趣，可加我wx， shiyang170808。
