第2章 审计日志的存储模型：关系型 vs 非关系型
说到审计日志的存储，我这些年踩过的坑还真不少。一开始接手审计系统时，觉得直接用关系型数据库建个表就完了，简单粗暴。后来才发现，这玩意儿的写入量和查询压力，跟普通业务数据完全是两码事。
你想想看，一个中等规模的企业，每天可能产生几百万条审计日志条目。这些日志需要存储很久，少则半年，多则五年甚至更久。是老老实实用关系型数据库，还是拥抱非关系型？咱们得先搞清楚各自的脾气。
2.1 关系型数据库：结构化审计日志的基石
关系型数据库（比如 PostgreSQL、MySQL）的最大优势是什么？结构化查询能力。审计日志经常要按时间范围、用户、操作类型、IP地址等等条件组合查询。用 SQL 写起来很自然，索引优化也成熟。
我记得之前在一个金融项目里，甲方要求审计日志必须支持任意维度的实时检索。我们当时选了 PostgreSQL，配合 B-tree 索引和部分表达式索引，性能还算够用。
但关系型数据库的短板也很明显——写入压力。每插入一条日志，就要写 WAL、更新索引、刷新缓冲池，这堆开销相当可观。一旦 QPS 超过几千，IO 就成瓶颈了。我曾经见过一个团队把审计日志直接往 MySQL 单表里灌，每天几百万条，三个月后单表超过 2 亿行……嗯，查询慢到令人发指，分区表也救不回来。
| 特性 | 关系型数据库（如 PostgreSQL） | 个人建议 |
|---|---|---|
| 写入吞吐 | 中低（单节点 QPS 通常 2k~10k） | 写入是瓶颈，别硬扛 |
| 查询灵活性 | 极高（任意组合查询、聚合、排序） | 审计日志的强需求 |
| 数据一致性 | 强一致性（ACID） | 合规审计必须 |
| 扩展性 | 主要靠垂直扩展，分片慢 | 数据量大了头疼 |
| 运维成本 | 中等（需要 DBA） | 小团队慎用 |
2.2 非关系型数据库：灵活扩展的日志农场
非关系型数据库的崛起，很大程度就是为了解决「写得多、查询简单」的场景。审计日志恰好是这样的业务——每条日志结构相对固定，写入量巨大，但查询模式通常也固定（比如按时间+用户ID查）。
我做过的一个 SaaS 平台，每天日志量接近 5000 万条，用的是 MongoDB。写入轻松扛住，配合 TTL 索引自动老化旧数据，省心很多。但这里有个坑：非关系型数据库的查询能力有限。你没法像 SQL 那样做复杂的 join 或多层嵌套的 where 条件。如果审计要求「找出过去一个月所有来自境外 IP、操作失败、且涉及金额大于 1 万的日志」，用 NoSQL 实现起来……说实话很痛苦。
- 文档存储（MongoDB）：写得好，查得一般，适合日志归档
- 搜索引擎（Elasticsearch）：全文检索能力强，但写入抖动大，适合日志聚合
- 时间序列（InfluxDB）：针对时间范围查询优化，但不擅长多维度筛选
- 宽列存储（Cassandra）：写入量极大，但查询按主键设计，不灵活
说白了，选非关系型之前，你得想清楚业务到底要查什么。如果查询模式固定且简单，NoSQL 是非常棒的选择。如果查询需求还在「不断进化」的阶段，嗯，建议留一手。
2.3 核心对比维度
我习惯从四个维度来比较：写入性能、查询灵活性、一致性要求、扩展能力。下面这张表能帮你快速决策。
| 对比维度 | 关系型数据库 | 非关系型数据库 |
|---|---|---|
| 写入吞吐（单节点） | 2k~10k QPS | 10k~100k QPS |
| 写入扩展 | 垂直扩展为主，分片麻烦 | 水平扩展天然支持 |
| 查询灵活性 | ★★★★★ | ★★☆☆☆（按场景定） |
| 索引能力 | 丰富（B-tree、hash、GIN、GiST） | 有限（B-tree、倒排、空间） |
| 一致性 | 强一致 | 最终一致或可调一致 |
| 事务支持 | 完整 ACID | 大多不支持或弱支持 |
| 数据建模 | 严格 Schema，需提前设计 | 灵活 Schema，可动态扩展 |
| 运维复杂度 | 较高，需专业 DBA | 较低，自动故障恢复 |
| 典型审计场景 | 合规审计、多维度查询 | 海量日志接收、固定模式检索 |
2.4 实战选型建议
选型没有银弹。我自己的做法是画决策树：
- 先看写入量：日均千万以下，关系型完全能扛住；亿万级别，必须上 NoSQL 或混合。
- 再看查询复杂度：如果经常需要「任意字段组合搜索」，那关系型是亲爹；如果只是按时间+固定维度查，NoSQL 省力。
- 然后看一致性：金融合规要求强一致，别纠结，上关系型；其他行业可以用最终一致。
- 最后看预算：关系型对硬件要求高（IO、内存），NoSQL 可以堆廉价 SSD。
还有一种常见做法是分层存储：新鲜日志先写入 NoSQL 做快速入库，然后通过 ETL 定期同步到关系型数据库做强一致归档和查询。这种混合架构虽然复杂，但在大型审计系统中非常常见。我参与的一个政务审计平台就是这么做的，效果不错。
这张图我当年给客户讲课时用了很多次，大伙儿反应挺直观。核心就一句话：别把审计日志当普通业务表来设计，它的写入压力和数据体积是另一个量级的。想清楚再动手，后面能少熬夜。嗯，这就是我对存储模型选型的一点实战心得。