Zendure（征拓）的设备接入量从数千台涨到117万台，数据规模从千万级冲到数千亿条。支撑这套系统的时序数据库，也从TDengine开源版换成了企业版集群。结果：存储成本降了约80%，单设备查询回到毫秒级，集群连续跑了9个多月没出可用性事故。
这篇文章拆解他们踩过的坑和最终落地的方案。
先看业务：数据从哪来，为什么涨得这么快
Zendure是广州疆海科技旗下的家庭能源管理品牌，主打即插即用。产品线从单一储能扩到9大品类，用户覆盖欧洲、北美、亚太60多个国家和地区。
核心场景有两个。
阳台光伏储能：欧洲大量公寓没法装屋顶光伏，方案是在阳台栏杆挂2到4块光伏板，接Solar Flow逆变器和电池，插家用插座就能用。白天发电存电池，晚上放电，App里看能源流向和省下的电费。
屋顶光伏加装储能：已有屋顶光伏的独栋住宅，用Mix AC+系列在不改动原系统的前提下加储能，提高自用率。
每台设备持续上报功率、电流、输入输出电能等时序数据。App还跑AI调度：按天气预报估发电量、按动态电价（比如法国EDF Tempo）挑低价时段充电、按用户习惯做充放电。
这些数据的特点是：设备多、频率高、保留久。
四个绕不过去的坎
接入设备从数千台涨到117万台后，压力集中爆发。
写入扛不住。太阳能流控、智慧CT、智能插座多条产品线同时上量，每台设备高频上报。以太阳能流控功率表为例，单表累计行数接近千亿级，高峰期每秒写入数十万个数据点。原来的单机部署直接顶到天花板。
存储烧钱。系统跑在AWS上，EBS按月计费。117万台设备乘高频采集乘约10年保留期，总量数千亿条。按老方案存，总存储需求7到8 TB，年开销超过20万美元。对一家全球化创业公司来说，这不是小数目。
查询变慢。数据量涨上来后，用户在App里看功率曲线，加载时间从几百毫秒变成好几秒，大跨度查询直接超时。“App变卡了”的反馈越来越多。
高可用不能断。用户跨多个时区，系统必须7×24小时在线。曾经一次单机故障，导致欧洲用户2小时看不到App数据，投诉量很大。从那以后，高可用成了硬指标。
选型：为什么最后是TDengine
开源版撞墙后，他们组了选型小组，从写入吞吐、查询性能、压缩能力、集群高可用几个维度横向比。
| 对比维度 | MySQL | InfluxDB | TDengine |
|---|---|---|---|
| 写入能力 | 分表后勉强支撑，运维复杂 | 开源版不支持集群 | 原生分布式集群，线性扩展 |
| 压缩率 | 无原生压缩 | 约3:1~5:1 | 约6:1~60:1 |
| 查询性能 | 大表查询分钟级 | 聚合查询秒级 | 单设备毫秒级，跨设备秒级 |
| 集群高可用 | 需主从+读写分离 | 集群版闭源收费 | 原生3副本集群 |
| SQL兼容性 | 完整SQL | 类SQL（非标准） | 标准SQL |
| 运维成本 | 高（分表+索引维护） | 中 | 低（自动化运维） |
InfluxDB在IoT场景本身不差，但开源版不支持集群，集群版是商业闭源产品，压缩率也不如TDengine。MySQL的问题是数据量一大，分表和索引维护的成本直线上升。
结论：TDengine在写入、压缩、集群能力、SQL兼容性上综合最优，而且团队已有开源版使用经验，迁移成本可控。
这里有个选型上的通用判断：IoT场景别只看单机benchmark，集群能力和压缩率才是决定长期账单的两个变量。前者影响可用性，后者直接影响存储费用。
数据建模：超级表加子表怎么切
架构采用分层设计。数据模型用的是TDengine的“超级表+子表”模式，核心思路一句话：超级表按场景品类切，子表按设备拆，标签按查询维度设。
一共建了16张超级表，其中11张有数据，5张为新场景预留。按产品线归类：
| 场景线 | 超级表 | 设备数 | 说明 |
|---|---|---|---|
| 太阳能流控 | power / electric / inout | 各约19万台 | 核心场景，数据量最大 |
| 智慧互感器 | power / inout | 各约9万台 | 精确电流计量 |
| 智能插座 | power / inout | 各约6万台 | 家庭用电管理 |
| 预估功率 | predic_power | 4万台 | AI功率预测 |
| 收益拆解 | hems_profit | 7.6万台 | 投资回报展示 |
| 用户能耗 | consumer_energy | 10.2万台 | 用户能耗画像 |
| Tesla整合 | tesla_inout | 1268台 | 第三方储能对接 |
以太阳能流控功率表为例，超级表这样建：
-- 太阳能流控功率超级表CREATE STABLE st_device_solar_flow_power (
ts TIMESTAMP, -- 采集时间戳
power INT, -- 实时功率值（W）
type INT, -- 功率类型（充电/放电/光伏等）
hems_id BIGINT -- 所属家庭能源管理系统ID) TAGS (
device_id BIGINT -- 设备唯一标识);
同一台Solar Flow逆变器，在功率表、电流表、输入输出电能表下各有一张子表。TAG字段P0标识设备，场景层通过P0关联到家庭维度。
典型查询长这样：
-- 1. 单台设备最新功率（App实时展示）SELECT last_row(*) FROM st_device_solar_flow_power
WHERE device_id = 100048;-- 响应时间：< 10ms-- 2. 某设备过去24小时功率趋势（App功率曲线）SELECT _irowts, AVG(power), MAX(power), MIN(power)
FROM st_device_solar_flow_powerWHERE ts >= NOW() - 1d AND device_id = 100048INTERVAL(5m);-- 响应时间：< 100ms-- 3. 统计所有设备本月每日总发电量（运营分析）SELECT _irowts, SUM(energy)
FROM st_device_solar_flow_inoutWHERE ts >= '2026-07-01'INTERVAL(1d);-- 响应时间：~2秒（覆盖18万+设备）-- 4. 按家庭维度聚合平均功率（HEMS分析）SELECT hems_id, AVG(power)
FROM st_device_solar_flow_powerWHERE ts >= NOW() - 1dPARTITION BY hems_id;-- 响应时间：~3秒
这种建模的好处很直接：新增产品线时只需定义新的超级表，不会动到已有场景。
落地效果：数字说话
| 指标 | 调优前（开源版/MySQL） | 优化后（TDengine企业版） | 变化 |
|---|---|---|---|
| 写入 | 单机瓶颈，高峰期延迟 | 3节点集群，稳定高吞吐 | 质的提升 |
| 查询 | 大跨度查询分钟级 | 单设备<10ms，跨设备约2秒 | 百倍以上 |
| 压缩 | MySQL无压缩/开源版5-9% | 压缩率15%~31% | 约1:6~1:60 |
| 存储开销 | 约$200,000+/年（估算） | 约$35,000/年 | 降低约80% |
| 高可用 | 单机无冗余 | 3节点+3副本，零故障运行9个月+ | 从0到1 |
| 数据保留 | 无法长期保留 | 约10年（KEEP 3650d） | 满足合规 |
太阳能流控是绝对的数据大户，仅功率数据就有近千亿条记录，占总数据量的60%以上。
迁移与运维：几个实操层面的经验
迁移用的是taos X数据迁移工具，实现了零停机平滑切换。这是从开源版升级到企业版时最省心的一环，但前提是提前把超级表结构和TAG设计对齐，否则迁移后查询性能会打折。
关于高可用，3节点3副本是他们的配置。这里有个坑：副本数不是越多越好，3副本已经能容忍单节点故障，再往上加只会放大写入延迟和存储开销。生产环境建议先按3副本起步，根据实际故障率再调。
关于数据保留，KEEP 3650d对应约10年。如果业务不需要那么久，缩短KEEP能直接省存储。冷热分层是他们下一步要做的方向。
后续计划
Zendure接下来会研究冷热数据分层存储，进一步压成本，同时深化智能拆解能力。
回头看，这次升级解决的不只是写入和存储的问题，更关键的是把成本控制在了可接受范围内，同时保住了全球用户7×24小时的数据可用性。对做IoT出海的公司来说，这两件事缺一不可。
