预测性维护中的时序数据存储方案：TDengine vs InfluxDB

去年Q3我们接了唐山一家钢铁厂的项目，8000多个测点，振动传感器采样率25.6kHz，温度和压力信号1Hz轮询。客户IT部门一开始大手一挥："都存到我们现有的MySQL里。"我当时就笑了。说实话，这种数据量往MySQL里塞，不出一个礼拜磁盘就得炸。

8亿条数据之后，MySQL查询一条历史曲线要40多秒。那天下午客户的运维经理脸色相当难看。

我劝他们上专业的时序数据库。市面上主流的两个选择：InfluxDB 2.7 和 TDengine 3.x。我把两家都拉到测试环境里跑了一遍，今天就把这笔账摊开说说。

先看写入吞吐：差距比想象中大

我们用Python起了一个多进程写入的压测脚本，模拟8000测点、批量写入，每批5000条。硬件是一台32核64G、SSD的Dell R740。

python 复制代码

# 压测脚本核心逻辑（简化版）
import multiprocessing as mp
from taos import connect  # TDengine Python连接器

def writer(worker_id, batch_count=20000):
    conn = connect(host="localhost", user="root", password="taosdata")
    # 超级表：一个厂一个库，每个测点一张子表
    sql = "INSERT INTO d_node001 USING vibration TAGS('线切机', 'z轴') VALUES "
    sql += ",".join(f"({ts+i}, {amp})" for i, (ts, amp) in enumerate(batch))
    conn.execute(sql)
    # 别一条一条插，批量才是王道

# 起了16个进程同时写

结果有点出乎意料。TDengine单机写入能干到每秒90万条左右，InfluxDB 2.7用同样的批量策略大概在40万条上下。当然这里面有个细节：TDengine要求你建表时就想清楚子表结构，一个测点一张子表，它的"一个采集点一张表"设计对这种场景天然友好；InfluxDB是tag+field的扁平模型，测点多起来以后series基数暴涨，写入和查询都会受拖累。

踩坑提醒：InfluxDB的tag组合数超过百万级时，TSM引擎的内存占用会变得很难看，我们实测series到120万时RSS从4G直接飙到11G，后来是砍掉了station_id这个高基数tag才缓过来。

压缩比：这是TDengine的主场

振动数据是重头。25.6kHz采样意味着一个测点一天光原始波形就是二十多亿个点（我们后来改成事件触发式存储，正常状态降频到10分钟存一段，这个后面有机会细说）。存储成本是客户财务总监亲自过问的事。

同样一批800GB的原始数据：

TDengine存下来87GB，压缩比大概9.5:1。它对时间戳做了差分+二阶编码，浮点值用Gorilla类的压缩，波动平缓的信号压得特别狠。
InfluxDB 2.7存下来210GB左右，压缩比4:1上下。

一年下来，这两个方案的磁盘账能差出一台存储服务器。有意思的是，客户后来算完这笔账，把原本准备买两台数据库服务器的预算砍掉了一台。

查询体验：SQL党会站TDengine

InfluxDB 2.x主推Flux语言。说实话，我用了半年Flux还是觉得别扭，管道套管道，写个"查每分钟振动RMS的移动平均，排除周末数据"得嵌套四层。而且Flux的执行性能一直是社区吐槽的重灾区，InfluxDB官方后来自己都转向了Flux→SQL的策略（IOx那套列存方案），等于变相承认了方向。

TDengine就是标准SQL，窗口函数、降采样、最后值查询都齐活。给Grafana 10.x配数据源的时候，写一个超表按10分钟窗口聚合的看板查询，SQL五分钟搞定。

sql 复制代码

-- 每个测点10分钟窗口的振动RMS趋势，一条SQL的事
SELECT _wstart, tbname, RMS(vibration)
FROM vibration_super
WHERE _wend > NOW - 1d
PARTITION BY tbname
INTERVAL(10m);

注意这里有个细节：PARTITION BY tbname是TDengine的方言写法，按子表分组再开窗，这个写法在处理几千个子表时依然很稳。

我也得替InfluxDB说两句公道话

反过来想，如果你们的数据量没那么变态------比如几百个测点、秒级采样、主要做慢趋势监控------InfluxDB的生态成熟度是真香。Telegraf采集器开箱即用，Grafana的InfluxDB数据源文档一搜一大把，市面上运维监控的方案基本都围着它转。我们另一个水务项目用的就是InfluxDB，300个测点跑了两年，啥毛病没有。

还有一点：TDengine的社区版有些功能是阉割的，流计算这些得企业版。预算紧的项目要提前评估。

最后说两句

选型这事没有银弹，我的判断标准就一条：高频原始波形数据（10kHz以上采样）+ 测点数上千，闭着眼睛选TDengine，存储和写入的优势是碾压级的；如果是低频过程量监控，团队又熟悉Influx生态，没必要折腾迁移。

对了，那个钢铁厂项目最后上了TDengine，三个月跑了11亿条数据，磁盘占用还没超过300GB。上个月客户IT还专门发消息说Grafana看板加载速度"跟换了台服务器似的"。

一点碎碎念：数据库选型会上，最容易坏事的不是技术分歧，而是"我们一直用XX所以继续用XX"这种惯性。数据还没开始存，先算算一年后的账，很多答案就自己浮出来了。