第4章 日志数据特点分析：写入多、顺序、不可变
做审计日志存储优化，第一步不是看数据库，而是看日志本身。我经手过好几个日志系统，发现很多人一上来就讨论用什么引擎，却忽略了数据特点。其实日志数据的写入模式非常特殊，你只要理解它的脾气，存储设计就成功了一半。
核心结论：审计日志是典型的「写多读少、追加顺序、几乎不可变」数据集。这些特点决定了它最适合用 LSM-Tree 或预写日志（WAL）风格的存储方案，而不是传统 B+ 树。
写入密集型：数量大、频率高、峰值陡
想想看，一个中等规模的微服务集群，每天产生几亿条审计日志很正常。每条日志几十到几百字节，综合起来写入吞吐量可以轻松破百 MB/s。
我遇到过最极端的情况：某电商大促期间，日志写入峰值冲到 300MB/s，持续了 2 小时。当时用的 MySQL 直接扛不住，幸好我们提前做了缓冲池和批量写入。
- 写占比极高：读操作通常只占 5%~10%，其余全是写入。
- 写入不可预测：业务流量波动会直接反应到日志量上，凌晨低峰可能只有 10MB/s，中午高峰能翻 30 倍。
- 对延迟敏感但能接受微小的批量延迟：审计日志允许几百毫秒的落盘缓冲，这给了我们优化空间。
我曾经踩过的坑：早期我直接让每条日志都 fsync 一次，结果 20 条并发就把磁盘打满了。后来改成 1 秒批量 fsync，写入吞吐提升了 50 倍，而且审计合规要求完全满足（多实例副本保证）。
顺序写入：磁盘的天生好搭档
日志数据本身是追加写入的，每条新日志都只追加到文件末尾。这意味着大部分写操作都是顺序 IO。你想想看，顺序写有多快？一块普通 SSD 随机写不到 50MB/s，但顺序写可以跑到 500MB/s 以上。机械盘差距更夸张——随机写可能只有 1MB/s，顺序写能到 150MB/s。
所以，我习惯把日志落地在独立磁盘上，并且预先分配大文件（比如每个 256MB），避免频繁触发文件系统元数据操作。另外，缓存策略也要倾斜向写缓冲，而不是读缓存。
| 存储介质 | 随机写（4KB） | 顺序写（1MB） | 日志场景推荐 |
|---|---|---|---|
| HDD | ~1 MB/s | ~150 MB/s | 不合适，除非做日志冷备 |
| SATA SSD | ~30 MB/s | ~500 MB/s | 中低成本可选，注意写寿命 |
| NVMe SSD | ~100 MB/s | ~3000 MB/s | 强烈推荐，兼顾性能与寿命 |
| Optane/PMem | ~300 MB/s | ~6000 MB/s | 极端高性能，成本高 |
一个小技巧：如果磁盘支持，把日志文件的块对齐到 4KB 或 1MB（取决于你的平均日志大小），可以减少读-改-写惩罚，这在大批量刷盘时尤其明显。
不可变性：省掉锁、版本控制、回滚等一切复杂操作
审计日志一旦写入就不允许修改。这意味着没有更新操作、没有事务冲突、没有 MVCC。存储层可以极度简化。
举个例子，传统数据库里你要考虑行锁、间隙锁、死锁检测等等。但对于日志，你只需要保证「先写入，再读一致」就行。我自己在写用户态日志存储库时，直接抛弃了所有锁，只用 CAS（compare-and-swap）更新写入偏移量，性能极好。
- 无随机更新：不需要支持 UPDATE，文件或 SSTable 不再被修改。
- 无事务回滚：审计日志只有 COMMIT 没有 ROLLBACK。如果真的写错了，要么忽略，要么补一条修正日志。
- 压缩合并更简单：因为数据不会过期修改，压缩只需要做「合并已删除或过期段」这一件事。
我个人的经验：不可变性带来的最大好处是「读一致性」变得极其简单。任何时间点，你只要定位到文件 offset 就能读到当时的完整记录。配合日志序列号，可以做到近乎零开销的快照。
利用数据特点做存储优化
理解了以上三点，我们就能针对性地设计存储结构。下面这个表格列出了常见存储引擎与日志特点的匹配度：
| 存储引擎 | 写密集型支持 | 顺序写适配 | 不可变优化 | 综合评价 |
|---|---|---|---|---|
| B+ Tree（InnoDB） | 中等（受限于 B+ 树分裂） | 差（数据页随机分布） | 差（需要 undo log） | 不适合大规模日志 |
| LSM-Tree（LevelDB/RocksDB） | 优秀（批量刷 SST） | 优秀（顺序写 SST） | 优秀（SST 不可变） | 非常推荐 |
| WAL-only（Kafka/BookKeeper） | 极佳（纯追加） | 极佳（完全顺序） | 极佳（分段不可变） | 最适合流式审计日志 |
| 纯文本文件 + 按天轮转 | 好（简单可靠） | 优秀（同一文件追加） | 自然满足 | 适合中小规模 |
我建议中小团队先用「按天轮转 + zstd 压缩」的文本方案，每天几百 GB 以内的量完全够用。如果每天上 TB 级，再上 LSM-Tree 或 Kafka 集群。不要一开始就上分布式系统，分布式带来的复杂性往往超过日志本身。
嗯，这里还要注意一下：不可变性不代表数据永远不删除。审计日志通常有保留期限，比如 90 天或 1 年。处理过期数据时，不要做「删除单条记录」，而是直接删除整个文件或 SSTable 段——这就是不可变性带来的另一个好处：删除也是批量顺序的，成本极低。
一个小细节：我做过期清理时，喜欢在文件名里埋上起始时间戳和结束时间戳。这样只需扫描文件名就能确定哪些文件可以删除，省掉了遍历内容的开销。
一张图看懂日志数据特点
下面是审计日志的数据特点与优化主线，我画成了流程图，方便你对照自己系统的各个环节：
从图里可以清楚看到：日志的三大特点分别对应着不同的优化手段。写入多驱动我们做批量缓冲，顺序追加方便我们做预分配和块对齐，不可变则允许我们采用 SST 或分段结构做零锁压缩。把这些策略组合起来，最后落地的方案无非是 LSM-Tree 风格引擎或简单的日志轮转——看你的规模选。
总结一下我的习惯：每次新接一个审计日志项目，我第一件事就是去机器上跑一周的写入 IO 采样，看看平均大小、峰值吞吐、文件增长曲线。拿到这些数据，再对照上面的表格，选型就八九不离十了。