日志是大多数系统里写入量最大的数据类型之一：一次请求可能产生访问日志、错误日志、性能埋点等多条记录，高峰期每秒写入几万条并不罕见。与业务数据不同，日志有三个鲜明特点：写多读少、查询条件相对固定、有明确的时效性。如果直接把日志一条一个文档地塞进MongoDB，时间一长就会发现磁盘被吃满、索引膨胀、写入延迟上升。数据建模在日志场景里不是可选项，而是决定这套存储能不能长期稳定运行的关键。本文介绍几种常见的日志建模思路，包括平铺存储、字段归纳、分桶存储以及TTL自动过期，并分析各自的适用边界。
方案一：一条日志一个文档的平铺存储
最直接的做法是每条日志对应一个文档，字段包括时间戳、级别、模块、消息体等。这种建模与关系型数据库的行式存储思维一致，理解成本低，插入逻辑简单，而且任何维度的查询都天然支持——想按模块过滤就建模块索引，想按时间范围查就建时间索引。
它的优点是查询灵活、代码简单，适合日志量中等（每天百万级以内）、查询维度不固定的场景。但缺点也很明显：每条日志都要存储一次完整的文档头和字段名开销，磁盘占用偏高；集合文档数量增长极快，索引体积随之膨胀，写入时索引维护成本上升；单条日志通常几十字节到几百字节，远低于MongoDB文档的理想大小，存储引擎的空间利用率不理想。
示例结构如下：
{
_id: ObjectId(),
ts: ISODate("2024-06-01T10:23:45Z"),
level: "error",
module: "payment",
traceId: "a1b2c3d4",
msg: "下游接口超时",
cost: 820
}
如果你的日志量每天只有几十万条，保留周期一个月，这种平铺方案完全可以胜任，不必过度设计。但当日写入量达到千万级甚至亿级时，就必须考虑下面的方案了。
方案二：按字段归纳减少文档数量
第二种思路是在写入端做一层轻量聚合：同一个请求或同一个traceId产生的多条日志，合并进一个文档，用数组字段承载明细。这样文档数量会成倍减少，按traceId查询时一次就能拿到完整调用链，也不用额外建索引。
{
traceId: "a1b2c3d4",
startTime: ISODate("2024-06-01T10:23:40Z"),
entries: [
{ ts: ISODate("2024-06-01T10:23:41Z"), level: "info", msg: "收到请求" },
{ ts: ISODate("2024-06-01T10:23:45Z"), level: "error", msg: "下游接口超时" }
]
}
这种建模的代价是失去了逐条日志的独立查询能力：想查所有error级别的日志，MongoDB需要扫描数组字段，即使建了多键索引，效果也不如平铺方案里的单字段索引。另外数组会持续增长，如果一条trace的日志条数不可控，文档可能逼近16MB的限制，写 入端还得处理文档拆分逻辑。它适合调用链追踪这类“按ID取全量”的读取模式，不适合做全局统计分析。
方案三：分桶建模，日志场景的主流选择
分桶（bucketing）是时序类数据建模的经典手法，日志本质上也是一种时序数据。核心思想是：把固定时间窗口（比如一分钟）内、同一来源的日志合并到一个文档里，明细存入数组，同时维护桶级别的统计字段。写入时先尝试更新当前桶，桶不存在或已满就新开一个。
{
moduleId: "payment",
bucketTs: ISODate("2024-06-01T10:23:00Z"), // 桶的起始时间
count: 156,
minTs: ISODate("2024-06-01T10:23:01Z"),
maxTs: ISODate("2024-06-01T10:23:59Z"),
logs: [
{ ts: ISODate("..."), level: "error", msg: "下游接口超时", cost: 820 },
// ... 更多日志
]
}
分桶带来的收益是多方面的。文档数量从“每条日志一个”降到“每分钟每模块一个”，索引体积大幅缩小；一次插入一批日志相当于一次update，写放大明显降低；桶级统计字段（如count、maxTs）可以直接支撑“每分钟错误数”这类聚合查询，不必解开数组。在配合WiredTiger的snappy或zstd压缩时，同类日志合并存储的压缩率也显著高于散落文档。
桶的大小需要权衡：桶太大，文档逼近限制且并发更新冲突频繁；桶太小，文档数量回升，分桶收益减弱。实践中常以单桶500到1000条日志或一分钟窗口为上限，超过即封桶开新桶。查询方面，按时间范围查日志时先定位桶再过滤数组明细，如果明细内的字段需要精确检索，可以借助多键索引，或者干脆把高频检索字段冗余到桶级别。
用TTL索引自动清理过期日志
无论采用哪种建模，日志都不能无限保留。MongoDB提供了TTL索引，在时间字段上建立带expireAfterSeconds参数的索引后，后台任务会定期删除超期文档，无需手工编写清理脚本。
// 日志保留30天
db.logs.createIndex(
{ ts: 1 },
{ expireAfterSeconds: 60 * 60 * 24 * 30 }
)
使用TTL有几点必须注意：TTL字段必须是BSON日期类型；删除由后台任务每60秒左右批量执行，不是精确到秒的定时清除；TTL索引不能建在复合索引上，只能是单字段索引；对于分桶文档，TTL应建在桶的时间字段上，删除时整桶一起过期，这也意味着桶边缘的日志保留时间会有细微偏差，对日志场景通常可以接受。
另外TTL删除本质上是删除操作，高写入量下删除速度可能跟不上产生速度，导致磁盘持续增长。这种情况下可以改用按天或按周预分集合的方案，到期直接drop整个集合，drop操作几乎瞬间完成，比逐条删除高效得多。这也是很多大规模日志平台采用“时间分集合+定期drop”而非TTL的原因。
方案对比与选型建议
下表 summarizes 三种建模的核心差异：
| 维度 | 平铺存储 | 字段归纳 | 分桶存储 |
|---|---|---|---|
| 写入吞吐 | 一般 | 较好 | 好 |
| 查询灵活性 | 高，任意字段 | 低，仅按聚合键 | 中，按桶维度和明细过滤 |
| 存储成本 | 高 | 低 | 较低，压缩友好 |
| 实现复杂度 | 低 | 中 | 较高 |
选型时可以按这个顺序判断：日志量小、查询维度多变，用平铺存储加TTL即可；以调用链查询为主，选按traceId归纳；日志量大且查询以时间范围和模块维度为主，分桶是最优解，再叠加按时间分集合配合drop来控制生命周期。同时别忘了写入端使用批量insert或bulkWrite、合理设置writeConcern为w:1、关闭不必要的索引，这些与建模配合起来，才能真正撑起海量日志的稳定写入。
MongoDB数据建模日志存储TTL索引修改时间：2026-08-31 07:22:51