第4章日志存储方案

4. 日志存储方案：本地文件存储、数据库存储、Elasticsearch存储、分布式存储对比

聊到日志存储，很多刚入行的朋友会觉得——不就是找个地方把日志塞进去吗？

嗯，我以前也这么想。直到有一次，某条线路的PIS系统出了故障，我需要从几十GB的文本日志里找一条关键报错。那个下午，我对着命令行里的grep命令，等得都快睡着了。从那以后，我彻底明白了：存储方案选不对，运维两行泪。

说白了，就是把日志写成文本文件，按日期或小时切分。这是最原始的方式，也是很多老旧PIS系统的标配。

优点：

缺点：

我在项目中遇到过这样的情况：某车站的PIS工控机，日志文件一天能写2GB。运维人员没注意，三个月后磁盘满了，系统直接卡死。嗯，这就是本地存储的典型坑。

我的建议：本地文件存储只适合做临时缓存或调试用。千万别把它当主力存储方案。

把日志写进关系型数据库，听起来很合理。结构化、可查询、有权限控制。但实际用起来，你会发现事情没那么简单。

我曾经在一个项目中，把PIS系统的操作日志全部写进MySQL。刚开始还好，每天几万条。半年后，表里攒了上千万条记录。查询一次历史记录，动不动就十几秒。更可怕的是，频繁的INSERT操作导致表锁，影响了正常的业务写入。

避坑指南：我曾经把日志表设计成单表不分区，结果数据量上来后，DELETE旧数据都成了噩梦。一定要按时间分区，定期归档或清理。

说到日志分析，Elasticsearch几乎是绕不开的名字。它天生就是为了处理海量日志而生的。

为什么推荐它？你想想看，PIS系统的日志里，经常需要搜「某台设备在某个时间段的错误码」。用传统数据库，你得写一堆LIKE语句，慢得要命。但ES的倒排索引，几毫秒就能给你结果。

ES存储的核心优势：

不过，ES也不是银弹。我记得有一次，团队没控制好索引分片数，结果集群负载过高，查询响应时间飙升到几十秒。后来我们调整了分片策略，才稳定下来。

我的经验：ES适合做热数据的存储和检索。比如最近30天的日志。更早的数据，建议冷热分离，存到廉价存储里。

当PIS系统覆盖整条线路、甚至整个城市的地铁网络时，日志量会大到惊人。这时候，单机方案根本扛不住。分布式存储就派上用场了。

常见的分布式存储方案包括：

我个人习惯，在大型PIS项目中，采用分层存储架构：

注意：分布式存储的运维复杂度远高于单机方案。网络分区、节点故障、数据一致性，都是需要重点关注的。我曾经因为没配置好副本数，导致一个节点挂了后数据丢失——嗯，那次教训很深刻。

维度	本地文件	MySQL/PG	Elasticsearch	分布式存储
写入性能	★★★★★	★★★☆☆	★★★★☆	★★★★☆
检索性能	★☆☆☆☆	★★★☆☆	★★★★★	★★☆☆☆
扩展性	★☆☆☆☆	★★☆☆☆	★★★★☆	★★★★★
运维成本	★☆☆☆☆	★★★☆☆	★★★★☆	★★★★★
适用规模	单机/小站	中等规模	大规模实时检索	超大规模归档

我的最终建议：没有最好的方案，只有最合适的。小站点用本地文件+定期清理就够了。中等规模上MySQL或PG。大规模PIS系统，ES是标配。如果日志量到了PB级，那就必须上分布式存储了。

记住一点：日志存储不是存了就完事，你得想好怎么查、怎么管、怎么删。