3、风电数据存储技术：关系型数据库与非关系型数据库对比、时序数据库（InfluxDB、TimescaleDB）介绍、数据分区与存储策略

聊到风电数据存储，我得先跟你交个底——选错数据库，后面全白干。

我在早期的一个风场项目中，团队图省事，把所有数据都塞进了MySQL。结果呢？单台风机每秒产生几十个测点数据，100台风机跑起来，写入直接崩了。那时候我盯着监控面板，心里只有一个念头：这锅，得数据库来背。

后来我花了整整两周，把关系型、非关系型、时序数据库全捋了一遍。今天就把这些经验掰开揉碎讲给你听。

3.1 关系型数据库 vs 非关系型数据库：你该怎么选？

先说关系型数据库。MySQL、PostgreSQL这些，大家都很熟。它们用表来存数据，支持ACID事务，查询用SQL。说白了，适合存那些结构固定、关系复杂的数据。

比如风机的台账信息：风机编号、型号、安装日期、经纬度。这些数据很少变，但经常要关联查询。用关系型数据库，一个JOIN就能搞定。

但问题来了——风电的时序数据，每秒都在产生。你想想看，一台风机有几十个传感器：风速、转速、桨距角、发电机温度……每个传感器每秒一条记录。100台风机，一天就是几亿条数据。

关系型数据库面对这种写入压力，表现很糟糕。我见过一个项目，用MySQL存时序数据，写入延迟从2毫秒飙升到2秒。最后不得不做分库分表，运维成本直接翻倍。

非关系型数据库呢？MongoDB、Cassandra这些，天生为海量数据而生。它们支持水平扩展，写入性能好，但牺牲了事务和复杂查询。

我个人的习惯是：台账数据用关系型，时序数据用非关系型。别想着一个库打天下，那是不现实的。

3.2 时序数据库：专为时间序列数据而生

说到时序数据，就不得不提时序数据库（TSDB）。它跟普通数据库最大的区别是：一切以时间为中心。

普通数据库存一条记录，你得指定主键。时序数据库呢？时间戳就是天然的主键。写入、查询、聚合，全都围绕时间轴展开。

我最早接触时序数据库是在2017年，那时候InfluxDB刚火起来。我记得第一次用它存风电数据，写入速度比MySQL快了整整一个数量级。当时我就知道，这玩意儿才是风电数据的正确打开方式。

3.2.1 InfluxDB：轻量级时序数据库的代表

InfluxDB的特点很鲜明：简单、快速、易用。它有自己的查询语言InfluxQL，跟SQL很像，但专门为时序数据优化过。

举个例子，你想查某台风机过去24小时的平均风速：

SELECT MEAN(wind_speed) 
FROM wind_turbine_metrics 
WHERE turbine_id = 'WT001' 
AND time > now() - 24h 
GROUP BY time(10m)

你看，语法很直观。GROUP BY time(10m) 直接按10分钟窗口聚合，不用自己写复杂的日期函数。

InfluxDB的存储引擎叫TSM（Time-Structured Merge Tree），专门针对时序数据做了优化。写入是追加模式，几乎不需要随机IO。所以写入性能特别好。

但InfluxDB也有短板：集群版是收费的。开源版只能单机部署，数据量大了之后，扩容是个问题。我有个朋友在50台风机的小场站用InfluxDB，跑了两年，数据量到了TB级，单机扛不住了，最后只能迁移。

3.2.2 TimescaleDB：PostgreSQL的时序扩展

TimescaleDB的思路跟InfluxDB完全不同。它不是一个独立的数据库，而是PostgreSQL的一个扩展。你装好PostgreSQL，再装个TimescaleDB插件，就能拥有时序数据库的能力。

这样做的好处很明显：你依然可以用SQL。所有PostgreSQL的特性，比如JOIN、窗口函数、CTE，TimescaleDB都支持。

我更喜欢TimescaleDB的一点是，它把时序数据自动分区成chunk（数据块）。每个chunk按时间范围划分，比如一天一个chunk。查询时只扫描相关chunk，性能自然就上去了。

创建一张时序表的语法也很简单：

CREATE TABLE wind_turbine_metrics (
    time        TIMESTAMPTZ NOT NULL,
    turbine_id  TEXT NOT NULL,
    wind_speed  DOUBLE PRECISION,
    power_output DOUBLE PRECISION,
    temperature DOUBLE PRECISION
);

SELECT create_hypertable('wind_turbine_metrics', 'time');

create_hypertable 这行代码，就是把普通表变成超表（hypertable）。TimescaleDB会自动按时间分区，你什么都不用管。

我曾经在一个项目中，用TimescaleDB存了200台风机、3年的数据，总量超过10TB。查询过去24小时的聚合数据，响应时间在1秒以内。这个表现，让我很满意。

3.3 数据分区与存储策略：别让数据变成垃圾山

数据库选好了，数据存进去了，然后呢？如果不做分区和策略管理，数据迟早会变成一座垃圾山。

我见过最夸张的一个案例：某风场把所有原始数据都存着，一年下来数据量超过50TB。查询一次历史数据要等几分钟，运维人员直接崩溃。

为什么会这样？因为没有做数据生命周期管理。

3.3.1 数据分区：按时间切分是王道

时序数据最自然的分区方式就是按时间分区。比如按天、按周、按月。每个分区独立存储，查询时只扫描相关分区，性能提升立竿见影。

在TimescaleDB中，分区是自动的。你只需要设置chunk的时间间隔：

SELECT set_chunk_time_interval('wind_turbine_metrics', INTERVAL '1 day');

InfluxDB也有类似机制，它叫shard。默认按7天一个shard，你可以根据数据量调整。

我个人的习惯是：数据量在每天100GB以内，按天分区；超过100GB，按小时分区。分区太细会导致元数据膨胀，太粗又起不到优化效果。这个度，得根据实际情况调。

3.3.2 存储策略：热数据、温数据、冷数据

不是所有数据都需要存在高性能存储上。我通常把数据分为三层：

• 热数据：最近7天的数据。需要实时查询，存在SSD上，用高性能数据库。
• 温数据：7天到3个月的数据。偶尔查询，存在普通SATA盘上，可以压缩存储。
• 冷数据：3个月以上的数据。几乎不查，归档到对象存储（如MinIO、S3）或HDFS上。

InfluxDB有内置的Retention Policy（保留策略），可以自动删除过期数据：

CREATE RETENTION POLICY "one_year" 
ON "wind_data" 
DURATION 365d 
REPLICATION 1 
DEFAULT

TimescaleDB则通过数据压缩和连续聚合来实现类似效果。你可以创建物化视图，按小时、天、月预聚合数据，原始数据则可以压缩或删除。

3.3.3 压缩：省空间就是省钱

风电数据有很多冗余。比如风速，在1秒内变化很小。时序数据库通常支持各种压缩算法，可以大幅减少存储空间。

InfluxDB默认使用浮点压缩算法，压缩比能达到10:1。TimescaleDB支持多种压缩算法，包括delta-delta、gorilla等。我实测过，TimescaleDB的压缩比通常在5:1到8:1之间。

你想想看，10TB的原始数据，压缩后可能只有1-2TB。存储成本直接降低80%。这笔账，怎么算都划算。

3.4 知识体系总览

下面这张图，是我梳理的风电数据存储技术核心逻辑。你可以把它当作一张地图，随时回来对照。

这张图把整个存储体系串起来了。你从上往下看：先选数据库类型，再选具体产品，然后匹配场景，最后用策略管起来。每一步都有讲究，每一步都影响最终效果。

好了，关于风电数据存储技术，我就讲这么多。记住一句话：没有最好的数据库，只有最合适的存储方案。选型的时候，多想想你的数据长什么样，查询模式是什么，预算有多少。想清楚了，再动手。

---

公众号:蓝海资料掘金营，微信deep3321