117万台设备同时在线，单表近千亿行，高峰期每秒数十万数据点——这是一家阳台光伏储能公司的真实数据规模。Zendure（征拓）用一年多时间，把底层时序数据库从开源版换到企业版集群，存储开销从每年20万美元压到3.5万美元，单设备查询回到10毫秒以内。这篇文章拆解他们的选型逻辑、数据建模和踩过的坑。
业务长什么样：阳台上的逆变器，屋顶上的加装储能
Zendure是广州疆海科技深圳分公司旗下的全球能源管控品牌，主打即插即用家庭能源管理系统。核心产品是Solar Flow系列智能储能逆变器，从轻量级阳台光伏Solar Flow 800，到专业级屋顶储能Solar Flow 2400 Pro、4000 Mix AC+。配套还有可扩展电池模块AB系列、智慧电表Smart Meter CT、智能插座Smart Plug Pro和电力枢纽Power Hub。
用户覆盖欧洲、北美、亚太60多个国家和地区，接入设备超过117万台。仅2024年，用户通过太阳能累计发电13,172 MWh。
业务场景分两类。
阳台光伏储能：欧洲大量公寓住户没法装屋顶光伏，方案是在阳台栏杆挂2到4块光伏板，接上Solar Flow逆变器和电池，插家中插座即插即用。白天发电存电池，晚上放电使用，App里实时看能源流向和节省的电费。
屋顶光伏加装储能：已有屋顶光伏的独栋住宅业主，用Mix AC+系列在不改动原有系统的前提下加装储能，提升光伏自用率。
这两类场景里，每台设备持续上报功率、电流、输入输出电能等时序数据。App还基于AI做智慧充放电调度：按天气预报预测发电量，按动态电价（比如法国EDF Tempo）在低价时段充电，按用户用电习惯智能调度。
四个痛点，逼着换数据库
一开始只有3张超级表、数千台设备。一年多后场景规模涨了百倍，压力全来了。
写入压力。多条产品线同时上量，设备从数千台涨到117万台。以太阳能流控功率表为例，单表累计行数接近千亿级，高峰期每秒写入量达到数十万数据点。原来的单机架构扛不住。
存储成本。系统跑在亚马逊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兼容性上综合最优，加上团队已有开源版使用经验，最终选定企业版。
这里补充一个工程常识：从开源版迁到企业版，不是简单换个二进制。开源版和企业版的集群能力、副本机制、运维接口差异较大，迁移前必须确认业务依赖的SQL语法、写入协议、数据保留策略在目标版本全部支持，否则会出现”迁到一半发现某条查询跑不通”的情况。
数据建模：超级表按业务切，子表按设备拆
架构采用分层设计。数据模型上，用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数据迁移工具，实现了零停机平滑迁移。
超级表+子表模型带来的另一个好处：新增产品线时只需定义新表，不影响已有业务。开发和运维开销都压下来了。
后续规划有两块：冷热数据分层存储，进一步优化成本；深化智慧拆解能力。
最后给同样在选型的人一句实在话：时序库选型别只看benchmark数字。先盘清楚自己的写入峰值、保留周期、查询模式和高可用要求，再对照产品能力。Zendure的路径——开源版验证、遇到瓶颈后升级企业版集群——对多数从零起步的IoT团队是可复制的稳妥打法。
广州疆海科技有限公司深圳分公司（Zendure 征拓） 运维部门 马伟雄
