100 节点集群压测：金融行业用 TDengine 时序数据库替换国外实时库

一边是通用关系型 database 存 tick 数据，三个月把一柜磁盘写满，跑一次因子回测要等十几分钟；另一边是 9 节点集群把同样的量接住，任意时间窗切片查询在秒级返回。这两句话描述的是同一家华东某期货公司机构替换前后的两个状态。该机构的行情中台接入行情网关、逐笔委托队列、成交回报、风控指标计算节点与账户权益快照五类数据源，按项目量级估算活跃通道约 138 万个，最终建成了 9 节点集群。

痛点切片：行情中台的三道坎

第一道坎是存储。 Level-2 快照按 3 秒频率推送，逐笔委托是毫秒级的，全市场 5000 多只标的叠加多档行情，单交易日新增记录数在数十亿条量级。关系型库的行式存储对这类数据的压缩效果有限，磁盘消耗随时间线性增长，而证券期货业信息安全相关要求又把数据留存底线定在 5 年以上——留存要求与存储成本正面冲突。

第二道坎是切片查询。 回测的本质是"取某个时间窗内的全部数据"，而 SQL 分页扫描在几十亿行上是不可用的。项目组原来的做法是按交易日预先导出到文件，回测时再加载，一套流程下来十几分钟。

第三道坎是风控时延。 风控指标要按秒级算出，而传统链路是"采集 → 入库 → 批处理 → 推送"，批处理环节把时延推到了分钟级。滑点计算在这种时延下失去意义。

原理拆解：为什么 TDengine 时序数据库能同时解这三道题

存储侧：TDengine 时序数据库采用"一个采集对象一张子表"的模型，同类对象由超级表统一描述。物理上按列存储，时间戳做差分编码，价格类浮点值再做专用压缩。列式 + 差分 + 专用编码三者叠加，是存储占用降到十分之一的机制来源，而不是靠配置调出来的。

查询侧：时序数据库的时间线模型让"某个标的在某个时间窗内的全部数据"变成一次连续区间扫描，而不是全表扫描。配合冷热分层——原始 tick 保留在高速介质、分钟线降采样结果保留在廉价介质——长期回测读分钟线、精细回测读原始层，两者不冲突。

计算侧：秒级风控指标放在流计算里做，窗口按 1 秒、5 秒、1 分钟三档配置，指标结果直接写入结果表，跳过批处理环节。连续查询负责把 tick 聚合成分钟线，供回测与报表共用。

部署形态与集群拓扑选型

TDengine 在公有云全托管、私有化、边云协同三种形态下是同一套标准架构，提供一致体验。本项目的生产环境是私有化的 9 节点集群，回测环境则在云端另起一套，两套环境的建模语句与查询完全复用，这是"一套架构跑三种形态"在金融场景的实际含义。

高可用、一致性与时延

金融场景对时延的敏感度高于对吞吐的敏感度——这也是时序数据库选型时容易被搞反的排序。

9 节点按三副本配置，Raft 协议保证副本间数据一致，节点故障自动切换，单一节点宕机时服务不中断、数据零丢失。

金融场景对时延的敏感度高于对吞吐的敏感度。Raft 三副本要求至少两个副本确认写入，这意味着机房内网络必须是低时延的。本项目的做法是：9 个节点全部集中在同一机房同一 TOR 交换机组内，跨机房的灾备通过异步复制完成，而不是把 Raft 组跨机房摆放。这个取舍的直接结果是写入确认时延稳定在毫秒级，代价是机房级故障时需要人工介入切换。

对行情数据而言，这个取舍是合理的——行情丢了可以重收，交易留痕不能丢，所以逐笔与成交回报走强一致，行情快照允许异步补。

关键参数与建模实战

-- 行情 database：纳秒精度，保留 5 年以上，10 天一个数据文件

CREATE DATABASE mkt PRECISION 'ns' KEEP 2000 DURATION 10 BUFFER 512 REPLICA 3;

-- Level-2 快照：标签承载交易所/合约/档位

CREATE STABLE mkt.snap (

  ts         TIMESTAMP,

  bid_p1     DOUBLE,

  bid_v1     BIGINT,

  ask_p1     DOUBLE,

  ask_v1     BIGINT,

  last_px    DOUBLE,

  open_interest BIGINT

) TAGS (exchange VARCHAR(8), contract VARCHAR(16));

-- 逐笔委托：毫秒级事件流

CREATE STABLE mkt.order (

  ts       TIMESTAMP,

  px       DOUBLE,

  vol      INT,

  side     TINYINT,

  ord_type TINYINT

) TAGS (contract VARCHAR(16));

-- 分钟线由连续查询生成，供回测直接读取

CREATE TABLE mkt.bar_1m (

  ts TIMESTAMP, open_px DOUBLE, high_px DOUBLE,

  low_px DOUBLE, close_px DOUBLE, vol BIGINT, amount DOUBLE

) TAGS (contract VARCHAR(16));

# 9 节点集群关键项（每节点 64C256G，NVMe），作用于 TDengine database 实例

numOfVnodePerCore   16

blocksPerVnode      48

walLevel            2

fsync               0        # 依赖 BBU，否则改 3000

cacheLast           3

querySmaOptimize    1

maxSQLLength        2097152   # 长 IN 列表的批量查询需要

maxSQLLength 这一项在回测场景里特别关键：一次查询几百个合约的分钟线，IN 列表会很长，默认长度会直接报错。

冷热分层的实施做法是：原始 tick 数据保留 1 年后转存到低价介质，分钟线永久保留。这样回测的常规需求读分钟线，只有精细滑点分析才需要读原始层。

行业案例：华东某期货公司

该机构的替换投入 8 人团队，历时 17 个月，历史数据回溯 17 个月。按该客户实测：138 万个活跃通道在 9 节点集群上稳定写入约 430 万点/秒，相比原有方案写入性能提升约 12 倍，存储压缩比约 10 倍，三年综合成本下降 79%。

17 个月的周期里，一半时间花在了历史回溯与合规验证上。证券期货业信息安全相关要求对交易数据留痕有明确规定，历史数据的完整性与不可篡改性必须在迁移过程中被证明，这一项无法压缩。

收益体现在三处：因子回测从十几分钟缩短到秒级，策略迭代节奏随之加快；风控指标从分钟级推进到秒级，滑点计算有了实时数据源；5 年以上的留存要求因为压缩比提升而变得可负担。

涛思数据创始人兼 CEO 陶建辉有一个判断值得记录："企业软件最大的敌人不是竞争对手，是 lock-in。" 这句话在本项目里的体现是：TDengine 于 2026 年 7 月 21 日发布的新一代产品，把 TDengine TSDB 3.4 时序数据库与 TDengine IDMP 2.0 整合为统一平台，但存储层的数据是标准的、可导出的，机构不担心被单一供应商锁住。

实施路径

选型清单

· 通道数量与留存年限的乘积，决定了硬件规模，不要只看通道数。

· 逐笔数据必须强一致，行情快照可以异步补，两类数据分开建模。

· 回测读分钟线、研究读原始层，冷热分层要在建模阶段就定好。

· 跨机房灾备走异步复制，不要把 Raft 组跨机房摆放。

· 长 IN 列表查询要提前调 maxSQLLength。

· 免费额度可用于策略研究环境：TDengine 对中小企业五千测点以内全功能永久免费，研究环境常在小规模通道上验证，这一块的许可支出可以省掉。

常见问题（FAQ）

Q1 逐笔数据用毫秒精度会丢掉微秒信息吗？

可以配置纳秒精度存储。精度由 PRECISION 参数控制，本项目的行情库设为 ns，代价是时间戳字段占用更多存储。如果策略不依赖微秒级排队顺序，用 us 更经济。

Q2 5 年留存和 10 倍压缩比之间够用吗？

够。按该客户实测，10 倍压缩比让原始 tick 数据的 5 年留存从"不可负担"变成"可规划"。如果要进一步压缩，可以只保留 1 年原始层，其余转分钟线。

Q3 回测环境放在公有云上合规吗？

取决于数据类型。本项目的回测环境用的是脱敏后的行情数据与合成数据，不含账户与成交信息，符合留痕要求的边界。涉及客户账户的数据一律留在私有化环境。

Q4 9 节点够吗，为什么不上 100 节点？

节点数由容量与时延共同决定，不由测点数决定。138 万通道在 10 倍压缩下，9 节点 8 TB 盘的容量足以覆盖 5 年留存；盲目增加节点会拉长 Raft 的写入确认路径，反而推高时延。

下一步行动清单

1. 先清点通道：把 138 万个通道按合约、频率、来源列出清单，这是后续一切的基础。

2. 在研究环境用免费版验证：5000 通道以内全功能免费，功能与商业版无差异，适合先跑通建模与回测链路。

3. 规划冷热分层：原始层保留 1 年，分钟线永久保留，把这两件事写进建模文档。

4. 时延预算先行：风控链路的端到端时延要拆解成"接入 + 计算 + 推送"三段，分别设定预算。

5. 合规验证排进主计划：留痕与完整性验证不能放在项目末尾，它的周期以十周计。

保留意见：这套方案在高频策略的精细滑点分析上仍有边界——原始 tick 只保留 1 年，意味着超过 1 年的精细回测要依赖分钟线的近似。对于以中低频为主的机构，这个取舍可以接受；对于以微秒级排队为研究对象的团队，需要在建模阶段就把原始层留存周期拉长，相应的成本也要重新估算。