3、日志存储与管理：数据库选型、数据生命周期与备份恢复
日志存哪儿？怎么管？丢了怎么办？
这三个问题，几乎是每个厂务运维团队都会遇到的灵魂拷问。我见过不少项目，前期只顾着采集日志，结果半年后数据库爆了，查个历史数据慢得像蜗牛爬。今天咱们就聊聊这块儿。
3.1 数据库选型：时序数据库 vs 关系型数据库
先说结论：厂务日志，首选时序数据库。
为什么？因为厂务数据天生就是时间序列数据——温度、湿度、压力、流量、电压……每一条记录都带着时间戳，而且数据量巨大，写入频繁。关系型数据库（比如 MySQL、PostgreSQL）不是不能用，但用起来你会很痛苦。
我举个例子。你想想看，一个中等规模的工厂，光温度传感器就有 500 个，每 5 秒采集一次。一天下来就是 864 万条记录。用 MySQL 存？嗯，查询的时候加个索引还能撑一阵子，但一旦数据量上亿，查询速度直接崩盘。而且关系型数据库的存储膨胀率很高，同样的数据量，时序数据库可能只占 1/3 的空间。
时序数据库为「写多读少、按时间范围查询」的场景做了极致优化。
关系型数据库为「事务一致性、复杂关联查询」的场景设计。
3.1.1 主流时序数据库对比
| 数据库 | 特点 | 适用场景 | 我的评价 |
|---|---|---|---|
| InfluxDB | 写入快、查询语法类 SQL、自带降采样 | 中小规模厂务系统（< 100 万点/天） | 上手简单，我第一个项目用的就是它 |
| TimescaleDB | 基于 PostgreSQL，支持 SQL 全特性 | 需要与业务数据联查的场景 | 适合老系统迁移，兼容性好 |
| TDengine | 国产、超级表设计、压缩率高 | 大规模工业物联网（千万级测点） | 我在一个光伏厂用过，压缩比惊人 |
| ClickHouse | 列式存储、分析性能极强 | 日志分析、报表统计 | 不适合高频写入，适合做分析层 |
我个人习惯是：采集层用 TDengine 或 InfluxDB，分析层用 ClickHouse。 这样既能保证写入性能，又能满足复杂分析需求。
我曾经在一个项目中，直接用 MySQL 存了半年的温湿度日志。结果到了第 4 个月，单表数据量超过 2 亿行，查询一条历史曲线要等 30 秒。最后不得不连夜迁移到 TimescaleDB，折腾了一周。所以，一开始就选对数据库，能省很多事。
3.2 数据生命周期管理
日志数据不是越久越好。你想想看，3 年前的某个传感器数据，除了审计需要，谁还会去查？但如果你不管理，它就会一直占着磁盘空间，拖慢查询速度。
数据生命周期管理，说白了就是：热数据快速访问，温数据压缩存储，冷数据归档或删除。
3.2.1 分级存储策略
我一般把厂务日志分为三级：
- 热数据（最近 7 天）：原始精度，全量存储。用于实时监控和近期故障排查。
- 温数据（7 天 ~ 6 个月）：降采样存储。比如原来 5 秒一条的数据，聚合为 1 分钟一条的平均值、最大值、最小值。
- 冷数据（6 个月以上）：压缩归档到廉价存储（如 HDFS、对象存储），只保留关键统计值。
具体怎么做？以 InfluxDB 为例，可以用连续查询（Continuous Query）自动降采样：
-- 创建 1 分钟聚合的保留策略
CREATE CONTINUOUS QUERY "cq_1m" ON "factory_db"
BEGIN
SELECT mean("temperature") AS "temp_avg",
max("temperature") AS "temp_max",
min("temperature") AS "temp_min"
INTO "factory_db"."autogen"."temp_1m"
FROM "factory_db"."autogen"."temperature"
GROUP BY time(1m), *
END嗯，这里要注意：降采样不是简单的取平均。对于报警相关的数据，我建议保留最大值和最小值，否则可能会漏掉异常尖峰。
数据生命周期策略一定要在系统上线前就设计好。我见过有人上线后忘了配置数据过期策略，结果半年后磁盘写满，整个采集系统崩溃。那场面，真是欲哭无泪。
3.3 备份与恢复策略
日志数据丢了，比没有日志更可怕。为什么？因为出了事故你想查根因，结果发现数据没了，那真是百口莫辩。
备份策略，我总结为三个字：全、异、验。
- 全：全量备份 + 增量备份结合。每周一次全量，每天一次增量。
- 异：异地备份。别把鸡蛋放在一个篮子里，机房着火了怎么办？
- 验：定期验证备份文件的可恢复性。备份了不能恢复，等于没备份。
3.3.1 备份方案示例
以 TDengine 为例，我常用的备份脚本：
#!/bin/bash
# 全量备份：每周日凌晨 2 点执行
BACKUP_DIR="/data/backup/taos"
DATE=$(date +%Y%m%d)
taosdump -o ${BACKUP_DIR}/full_${DATE} \
-u root -p your_password \
--all-databases
# 增量备份：每天凌晨 3 点执行
# 使用 taosdump 的 --start-time 参数
taosdump -o ${BACKUP_DIR}/incr_${DATE} \
-u root -p your_password \
--start-time "$(date -d 'yesterday' +%Y-%m-%d)" \
--end-time "$(date +%Y-%m-%d)" \
--all-databases恢复的时候，先恢复全量，再按时间顺序恢复增量。我建议每个月做一次恢复演练，别等到真出事了才手忙脚乱。
备份文件一定要加密。厂务数据虽然不像财务数据那么敏感，但温度曲线、设备运行参数这些，其实能反推出生产线的运行状态。我曾经帮一个客户做审计，发现他们的备份文件直接明文存在 FTP 上，谁都能下载。这要是被竞争对手拿到，后果不堪设想。
3.4 知识体系总览
下面这张图，是我梳理的日志存储与管理核心逻辑。你可以把它当作一个检查清单，看看自己的系统覆盖了哪些环节。
说白了，日志存储与管理就这三板斧：选对库、管好生命周期、做好备份恢复。每一步都不难，但每一步都容易踩坑。我见过太多人栽在「先跑起来再说」这个想法上，结果后面补课补得痛不欲生。
记住一句话：日志系统设计时多花一天，运维时能省一个月。