4. 数据库选型与设计：时序数据库（InfluxDB）介绍、表结构设计、数据写入与查询优化
好，咱们进入数据库环节。说实话，风场监控这个场景，用传统的关系型数据库（比如 MySQL）来做，不是不行，但你会很痛苦。为什么？因为风机的数据是源源不断的——每台风机每秒钟都在上报风速、功率、温度……一天下来几千万条记录很正常。MySQL 在这种写入压力下，索引会膨胀，查询会变慢，最后你连看个实时曲线都要等半天。
所以，我们需要一个专门为时间序列数据设计的数据库。我个人最常用的就是 InfluxDB。今天咱们就把它聊透。
4.1 为什么是 InfluxDB？
InfluxDB 是开源的时序数据库，专为处理带时间戳的高频数据而生。我在项目中遇到过好几次，用 MySQL 存风机数据，三个月后查询就慢得像蜗牛。换成 InfluxDB 后，同样的数据量，查询速度提升了 10 倍以上。
它的核心优势其实就三点：
- 写入快：每秒能处理百万级数据点，而且不需要建索引
- 压缩率高：时序数据天然有规律，InfluxDB 的压缩算法能把存储空间压缩到原来的 1/10
- 查询快：内置了针对时间范围的聚合函数，比如
MEAN()、MAX()、PERCENTILE()，一条 SQL 就能搞定
一句话总结：如果你的数据是“时间 + 数值”这种结构，而且写入频率高、查询以时间范围为主，那就选 InfluxDB，别犹豫。
4.2 表结构设计：别用关系型数据库的思维
嗯，这里要注意。很多从 MySQL 转过来的同学，第一反应就是建一堆表，然后搞外键关联。但在 InfluxDB 里，你千万别这么干。
InfluxDB 的数据模型只有三个核心概念：
- Measurement：相当于关系型数据库里的“表”
- Tag：标签，用于索引和分组，比如风机编号、机组型号
- Field：字段，存储实际数值，比如风速、功率
我建议你这样设计风场监控的表结构：
| 概念 | 示例 | 说明 |
|---|---|---|
| Measurement | wind_turbine_metrics |
所有风机指标都放在这一个表里 |
| Tag | turbine_id, farm_id |
用于过滤和分组，会被索引 |
| Field | wind_speed, power_output, temperature |
实际数值，不会被索引 |
| Time | 自动生成的时间戳 | 每条记录的核心 |
举个例子，一条数据写入后长这样：
INSERT INTO wind_turbine_metrics
(turbine_id='WT-001', farm_id='FARM-A')
wind_speed=12.5, power_output=1500.0, temperature=45.2
你看，没有复杂的表结构，没有外键，就是“时间 + 标签 + 数值”。简单粗暴，但效率极高。
小技巧：Tag 的取值不要太多，比如 turbine_id 最多几千个就够。如果 Tag 的基数太大（比如几百万个），会影响写入性能。我一般把 Tag 控制在 10 个以内。
4.3 数据写入：批量才是王道
写入 InfluxDB 时，最忌讳的就是一条一条地写。你想想看，每写一条数据就要建立一次 HTTP 连接，那效率得多低？
正确的做法是批量写入。我一般每 10 秒攒一批数据，一次性发过去。比如用 Python 的 influxdb_client 库：
from influxdb_client import InfluxDBClient, Point
from influxdb_client.client.write_api import SYNCHRONOUS
client = InfluxDBClient(url="http://localhost:8086", token="my-token", org="my-org")
write_api = client.write_api(write_options=SYNCHRONOUS)
# 批量构造数据点
points = []
for i in range(100):
point = Point("wind_turbine_metrics") \
.tag("turbine_id", f"WT-{i:03d}") \
.field("wind_speed", 10.5 + i * 0.1) \
.field("power_output", 1400.0 + i * 5) \
.time(datetime.utcnow())
points.append(point)
# 一次性写入
write_api.write(bucket="wind_farm", record=points)
我曾经在项目里遇到过一个问题：写入速度上不去，查了半天发现是每次只写 10 条数据。后来改成每次写 5000 条，吞吐量直接翻了 8 倍。所以，记住：批量越大，性能越好，但也不要太大，一般 5000-10000 条一批比较合适。
避坑指南：我曾经因为 Tag 值里带了空格和特殊字符，导致查询时死活查不到数据。后来才发现 InfluxDB 的 Tag 值需要用双引号括起来。所以，写入前最好做一下转义处理。
4.4 查询优化：别让查询拖垮你的看板
查询优化这块，我踩过的坑最多。刚开始做风场看板时，我写了一条查询：
SELECT * FROM wind_turbine_metrics
WHERE time > now() - 7d
结果呢？页面加载了 30 秒还没出来。为什么？因为 SELECT * 会返回所有字段，包括那些你根本不需要的 Tag 和 Field。数据量一大，网络传输就成了瓶颈。
优化后的写法是这样的：
SELECT MEAN("wind_speed"), MAX("power_output")
FROM "wind_turbine_metrics"
WHERE "turbine_id" = 'WT-001'
AND time > now() - 1h
GROUP BY time(5m)
你看，我只查了需要的字段，加了时间范围限制，还用了聚合函数。这样查询速度能快 10 倍以上。
再分享几个我常用的优化技巧：
- 限制时间范围：永远不要查全量数据，加上
time > now() - 1h这样的条件 - 使用聚合函数：前端看板一般不需要原始数据，用
MEAN()、MAX()聚合一下，数据量能减少 90% - 合理设置 Retention Policy：原始数据保留 7 天就够了，历史数据可以降采样后存到另一个表里
核心原则：查询时只拿你需要的，别贪多。你想想看，前端看板展示的是一张曲线图，你查 100 万个数据点和查 1000 个聚合后的数据点，效果是一样的，但速度天差地别。
4.5 本章知识体系
下面这张图帮你梳理了本章的核心逻辑：
好了，数据库这块咱们就聊到这儿。记住，选对工具、设计好结构、优化好写入和查询，你的风场看板才能跑得又快又稳。