MongoDB广告点击追踪如何建模_点击事件聚合与去重记录

不该直接存成大文档；应将每次点击作为独立文档存储，精简字段、建合理索引，并用唯一复合索引实现去重，配合覆盖索引优化聚合查询，按需预聚合。点击事件该不该直接存成大文档？别把每次点击都塞进一个嵌套数组里——这是最典型的“日志当文档”误用。MongoDB 单文档上限 64MB，但更现实的瓶颈是：一旦 clicks 数组涨到几千条，$push 写入会变慢，$elemMatch 查询变卡，连 db.collection.stats() 都可能因文档膨胀而失真。真正该做的，是把「点击」当作原子事件独立建模：每个点击事件存为一条独立文档，字段精简： { ad_id: ObjectId, user_id: "u_123", timestamp: ISODate("..."), ip: "192.168.1.1", ua_hash: "a1b2c3..." }去掉冗余字段（如完整 user_agent 字符串），改用哈希值 + 索引，省空间也提速避免在广告文档里用 clicks: [...] 嵌入——这会让广告文档随时间不可控膨胀，且无法对“过去24小时所有点击”做高效聚合如何低成本实现点击去重？去重不是靠应用层查一遍再写，而是靠 MongoDB 原生约束和结构设计。核心思路：把“用户 × 广告 × 时间窗口”变成唯一键，让数据库自己拦住重复。实操上分两步走：定义自然去重粒度，比如“同一用户 15 分钟内对同一广告的多次点击只记一次”，那么复合唯一索引就是：db.clicks.createIndex({ ad_id: 1, user_id: 1, window_start: 1 }, { unique: true })，其中 window_start 是 timestamp 向下取整到最近 15 分钟（如 new Date(Math.floor(ts.getTime() / 900000) * 900000)）写入时用 insertOne 而非 updateOne + upsert，配合 writeConcern: "majority"，失败即说明已存在，无需额外查切忌用 find().count() 判断是否存在——高并发下必然漏判，且性能崩盘聚合查询慢？先检查索引覆盖和时间范围广告后台最常跑的是“某广告近7天点击量”或“某渠道各广告 CTR”，这类聚合慢，90% 不是管道写得差，而是没让索引扛住过滤和排序。 跃问 跃问是由阶跃星辰开发的免费AI智能问答助手，随时帮你智能搜索、高效阅读、识图理解、和你畅聊感兴趣的话题。