1. 项目背景与需求解析
智慧办公场景下的物联网设备每天产生海量时序数据，极企科技原有架构面临三大痛点：首先是写入性能瓶颈，单节点数据库在峰值时段出现明显延迟；其次是存储成本激增，传统关系型数据库的压缩效率不足；最后是实时分析能力缺失，业务部门需要分钟级响应的设备状态报表。
我们最终选择TDengine作为核心时序数据库，主要基于三个技术特性：独创的"一个设备一张表"数据模型，将同类设备的标签与采集数据分离存储；列式存储配合自适应压缩算法，实测字符串字段压缩比达5:1；内置流式计算引擎，支持在数据写入阶段完成预聚合。
2. 集群架构设计与部署
2.1 硬件资源配置
采用3台阿里云ecs.g7ne.16xlarge实例组成集群，每节点配置：
- 64核AMD EPYC处理器
- 256GB内存
- 2块1.6TB ESSD PL3云盘（RAID 0）
- 25Gbps网络带宽
关键经验：ESSD云盘的预配置IOPS需设置为160万，避免突发流量时出现磁盘队列堆积。我们曾因默认配置导致写入延迟飙升到2秒，调整后稳定在15毫秒内。
2.2 软件拓扑规划
- dnode1：同时运行mnode和vnode角色，承担元数据管理+数据分片双重职责
- dnode2/dnode3：纯vnode节点，通过FQDN实现节点间通信
- 负载均衡：使用HAProxy实现写请求的轮询分发，配置TCP健康检查间隔为10秒
# 典型节点配置参数 maxTablesPerVnode = 1000000 maxVgroupsPerDb = 100 comp = 2 # LZ4压缩算法 walLevel = 2 # 保证数据可靠性3. 性能调优实战
3.1 写入优化方案
通过批量提交将5000条记录合并为一个请求，配合以下参数调整：
ALTER DATABASE telemetry SET BUFFER 256 SET PAGES 4096 SET PAGESIZE 32实测效果：
| 优化前 | 优化后 |
|---|---|
| 12万点/秒 | 83万点/秒 |
| CPU占用75% | CPU占用42% |
3.2 查询加速技巧
针对高频查询场景建立预计算视图：
CREATE STABLE dev_stats ( ts TIMESTAMP, avg_val DOUBLE, max_val DOUBLE, min_val DOUBLE ) TAGS (dev_type BINARY(20)); CREATE MATERIALIZED VIEW dev_1min REFRESH EVERY 1m AS SELECT _wstart AS ts, dev_type, AVG(val) AS avg_val, MAX(val) AS max_val, MIN(val) AS min_val FROM raw_data INTERVAL(1m) GROUP BY dev_type;4. 典型问题排查实录
4.1 内存溢出异常
现象：节点频繁重启，日志显示"out of memory" 根因：默认的查询内存限制（2GB）被复杂聚合查询突破 解决方案：
ALTER DATABASE telemetry SET QUERY_MEM_LIMIT 8G;4.2 热点分片不均
现象：dnode1持续高负载而其他节点闲置 处理步骤：
- 执行
SHOW VGROUPS确认分片分布 - 通过
BALANCE VGROUP手动迁移分片 - 设置自动均衡参数：
ALTER DNODE dnode1 SET balance_interval 300;5. 生产环境表现
当前集群承载着187,542台办公设备的实时数据，关键指标：
- 写入吞吐：稳定处理92万数据点/秒
- 存储效率：原始数据1.2TB/日，压缩后仅占用312GB
- 查询性能：设备历史轨迹查询P99耗时<800ms
- 可用性：运行6个月零计划外中断
这套架构特别适合具有以下特征的场景：设备数量超过5万台、采样频率高于1分钟、需要实时监控与离线分析并重的智慧办公系统。实际部署时建议预留20%的性能余量应对业务增长，我们正在测试通过增加2个vnode节点将容量扩展到200万台设备。
