凯士比数字工厂（KiPlant）用了 TDEngine，凯泵智联（KiCloud）用了 TrendDB。不是随便选的，也不是"哪个新用哪个"——两个项目的数据特征和业务需求有本质差异，选型过程中的每一个权衡都值得记录。
一、两个项目的数据画像
在做选型之前，我先梳理了两个项目的数据特征，这是选型决策的基础。
1.1 凯泵智联（KiCloud）
凯泵智联是一个旋转类设备的远程监测云平台，服务 120+ 家企业客户，监测对象是泵和电机。
数据特征：
数据来源以振动信号为主。单台设备的振动传感器每秒采样 1000-5000 个数据点（高频振动波形），一个轴承上可能有 3-4 个传感器。平台监测的设备总量约 5000 台，但并非所有设备都实时上报，通常有 30% 的设备在线。
数据量级：日增约 50GB 原始振动数据，历史数据需要保留 3-5 年（用于趋势分析和故障回溯）。总存储量在 50-80TB 级别。
查询模式：核心场景是单设备的历史波形回放和趋势分析——选中一台泵，查看过去 7 天的振动幅值变化曲线。查询通常是单设备、长时间跨度、原始精度或降采样。聚合分析（跨设备对比）相对较少。
1.2 凯士比数字工厂（KiPlant）
KiPlant 是一个覆盖全工厂的数字孪生平台，数据来源不只是设备，还包括产线、能耗、环境等多种维度。
数据特征：
数据来源多样：PLC 控制器每秒上报设备运行状态（开/停/故障/待机），传感器上报温度、压力、流量等模拟量，电表上报实时功率和累计电量，MES 系统推送工单状态变更事件。
数据量级：单个工厂日增约 2-5GB，20 个租户合计日增约 50-80GB。但每条数据的体积远小于振动波形，更多的是"大量小数据点"。
查询模式：核心场景是多设备聚合分析——全厂 OEE（设备综合效率）看板需要同时聚合几百台设备的状态数据；能耗分析需要按产线、车间、工厂层级进行汇总对比。查询通常是多设备、多维度、聚合计算密集。
二、候选数据库对比评估
基于上述数据画像，我将候选范围缩小到了三个：TrendDB、TDEngine、InfluxDB。
2.1 评估维度与对比
2.2 关键差异分析
数据模型的差异是最核心的。 TDEngine 的"超级表"概念非常契合工业场景：创建一个超级表 device_metric，每台设备自动对应一张子表，子表以设备 ID 为标识。写入时数据直接写入对应设备的子表，查询单设备历史直接查子表，聚合时通过超级表做跨子表查询。
-- TDEngine：创建超级表（类似模板）
CREATE STABLE device_metric (
ts TIMESTAMP,
temperature FLOAT,
pressure FLOAT,
vibration FLOAT
) TAGS (
device_id BIGINT,
device_type NCHAR(32),
factory_id BIGINT
);
-- 每台设备自动一张子表
CREATE TABLE device_1001 USING device_metric TAGS (1001, 'PUMP', 100);
-- 聚合查询：通过超级表跨设备聚合
SELECT factory_id, AVG(temperature), MAX(pressure)
FROM device_metric
WHERE ts > NOW - 1h
GROUP BY factory_id;TrendDB 则采用传统的 metric+tag 模型，没有"超级表"这层抽象，跨设备聚合需要通过 tag 过滤，在设备数量大（几千台）时查询效率不如 TDEngine。
三、最终选型决策
3.1 凯泵智联选 TrendDB 的理由
凯泵智联最早启动（2021 年），当时 TDEngine 的 Java 生态还不够成熟（JDBC 驱动存在连接泄漏的 bug，社区反馈修复周期长）。而 TrendDB 在公司内部已有成功案例（KSB 德国总部的另一个项目在用），技术支持和运维经验有保障。
更关键的是凯泵智联的核心场景是单设备的高频振动波形存储与回放，查询模式以单设备为主，跨设备聚合需求较少。TrendDB 在单设备高频数据的写入和时间范围查询上表现稳定，满足业务需求。
选型决策的核心考量：技术成熟度 > 极致性能。对于一个需要长期稳定运行的工业监控平台，选一个团队有经验、有支持的数据库，比选一个纸面性能更优但团队没踩过坑的数据库更安全。
3.2 数字工厂选 TDEngine 的理由
KiPlant 在 2022 年底启动时，TDEngine 已经发展到 3.x 版本，Java 生态成熟，JDBC 驱动稳定，并且提供了与 MyBatis 兼容的集成方案。早期的坑已经被社区填平了。
但选择 TDEngine 的核心原因不是"它变成熟了"，而是数字工厂的数据模型和查询模式天然适合超级表：
第一，多维度聚合是刚需。数字工厂的核心价值在于全厂级的数据分析——OEE 看板、能耗对比、产能分析，都需要跨设备、跨产线、跨车间的聚合计算。TDEngine 的超级表 + TAG 机制让这类查询非常自然高效。
第二，多租户隔离天然支持。TDEngine 支持按数据库做租户隔离（每个租户一个 database），不同 database 之间数据完全隔离，且可以独立配置数据保留策略。这比在 TrendDB 中通过 tag 做租户隔离要干净得多。
-- 每个租户一个数据库，独立配置保留策略
CREATE DATABASE factory_1001 KEEP 365 DAYS 30 BLOCKS 8;
CREATE DATABASE factory_1002 KEEP 180 DAYS 15 BLOCKS 4;第三，内置的降采样能力。数字工厂需要在不同时间粒度展示数据：实时大屏用秒级数据，日报表用分钟级聚合，月报表用小时级聚合。TDEngine 的连续查询和窗口函数可以自动完成降采样：
-- 每5分钟自动聚合一次，结果存入降采样表
CREATE TABLE device_metric_5min AS
SELECT _wstart as ts, AVG(temperature), MAX(pressure), AVG(vibration)
FROM device_metric
INTERVAL(5m)
SLIDING(5m);四、数据保留与降采样策略
4.1 凯泵智联的策略
振动波形数据体积大，但越久远的数据越少被访问。我设计了三级存储策略：
降采样由后台定时任务执行，将原始波形数据提取出关键特征值（峰值、均方根、峭度等），存入温/冷层，原始数据归档到 MinIO。需要回溯原始波形时从 MinIO 加载。
4.2 数字工厂的策略
利用 TDEngine 的原生能力，配置更加简洁：
-- 原始数据保留90天（KEEP参数）
CREATE DATABASE factory_1001 KEEP 90 DAYS 10;
-- 5分钟聚合数据保留1年
CREATE DATABASE factory_1001_5min KEEP 365 DAYS 30;
-- 1小时聚合数据保留3年
CREATE DATABASE factory_1001_1hour KEEP 1095 DAYS 30;TDEngine 的 KEEP 参数会自动清理过期数据，不需要额外的定时清理任务。数据压缩率实测约 10:1（相比原始 CSV 格式），50GB/天的原始数据实际只占用约 5GB 磁盘空间。
五、踩过的坑
5.1 TrendDB：时区陷阱
凯泵智联服务海外客户（KSB 是德国企业），设备分布在不同时区。TrendDB 内部统一使用 UTC 存储，但 JDBC 驱动在读取时会按 JVM 默认时区转换。有一次客户反馈"设备数据时间偏移了 8 小时"，排查发现是某台服务器的 JVM 时区配置被运维误改了。
解决方案：在应用启动参数中强制指定 UTC 时区（-Duser.timezone=UTC），所有时间转换在应用层显式处理，不依赖 JVM 默认配置。
5.2 TDEngine：超级表 TAG 变更的代价
TDEngine 的超级表 TAG 一旦创建，修改 TAG 列的结构（加列、改类型）代价很高，需要重建超级表。早期设计时 TAG 列设计得不够充分，后来需要加 workshop（车间）这个维度做聚合，不得不做了一次数据迁移。
教训：设计超级表 TAG 时要充分考虑未来可能的聚合维度，宁可多设几个 TAG 列（空间代价很小），也不要后续加列。
5.3 TDEngine：连接数管理
TDEngine 的单个连接不是线程安全的，在 Spring Boot 应用中需要配合连接池使用。早期直接用 DriverManager.getConnection() 创建连接，在高并发场景下频繁创建销毁连接导致 TDEngine 服务端连接数耗尽。
解决方案：引入 HikariCP 连接池管理 TDEngine 连接，与管理 MySQL 连接的方式一致。
六、总结：选型方法论
技术选型不是选"最好的"，而是选"最适合的"。回顾两次选型，我总结出一套工业物联网场景下时序数据库的选型方法论：
第一步：画数据画像。 弄清楚数据量、写入频率、单条数据大小、保留周期——这些决定了存储引擎的选择。
第二步：分析查询模式。 单设备查询为主，还是跨设备聚合为主？读写比是多少？这决定了数据模型（超级表 vs 传统时序模型）的选择。
第三步：评估生态成熟度。 数据库本身的性能是一方面，Java SDK 是否稳定、社区是否活跃、团队是否有经验——这些"软实力"在实际项目中往往比性能跑分更重要。
第四步：设计数据保留策略。 工业场景的数据量增长是确定性的（设备数量 × 采集频率 × 时间），不做数据分层和降采样，再大的存储也会被填满。
最后一句话总结：凯泵智联选 TrendDB 是因为"稳"，数字工厂选 TDEngine 是因为"合"。 两个决策在各自的上下文中都是正确的。
如果这篇文章对你有帮助，欢迎访问我的博客 robinzhu.top 获取更多实战分享。