本周评审版

Iemail MongoDB 发送记录磁盘占用优化方案

目标是在明显降低 Iemail MongoDB 磁盘成本的同时,不明显影响客户运营体验。方案覆盖历史数据下载、报表查询、问题排查和容量治理。

方案日期
2026-05-18
需求来源
内部成本优化
覆盖项目
DMTX + Iemail
建议策略
热数据 3 个月,在线明细 6 个月,冷库默认 24 个月

1. 需求澄清

本需求不是客户直接提出的功能诉求,而是 DMTX/Iemail 内部成本优化诉求:当前 Iemail 使用阿里云 MongoDB 单独存储邮件发送数据,发送记录占用大量磁盘,后续仅通过扩容无法长期满足 DMD 全部客户增长。

用户关注点方案影响
客户运营报表可看、近期明细可下载、老数据有解释近期体验保持不变,超期明细变为申请/异步下载
DMTX 客服/实施能排查客户问题,有明确数据可用范围提供热/冷数据状态和查询路径
研发运维降低 MongoDB 磁盘和备份压力建立归档、校验、清理、回滚机制
财务/管理降本可量化按集合空间和保留周期估算节省

2. 现状与容量分析

DMTX 报告下载入口主要从本地 PG 的 contact_dmd_log 导出;Iemail 的磁盘大头在 MongoDB 的 send_record_*,其中保存发送记录、状态、供应商响应、收件人和邮件内容等大字段。

384.32 GB当前 CSV 统计总集合空间
342.04 GBsend_record_* 集合空间
89.00%send_record_* 占总集合空间比例
85.93 GBsend_record_* 可回收空间
分类集合数集合空间占总集合空间可回收空间
send_record_*62342.04 GB89.00%85.93 GB
events_*6211.69 GB3.04%0.15 GB
open_report560.35 GB0.09%0.05 GB
mail_link530.64 GB0.17%0.02 GB
rtjourney_log_*22117.50 GB4.55%0.70 GB

结论:磁盘治理主目标应是 send_record_*,尤其是大字段瘦身、历史归档、字段裁剪、物理空间释放;events_* 虽占比较低,但支撑报表和 DMTX 回收,不能粗暴删除。

3. 竞品调研

产品近期明细长期统计明细留存口径导出策略
Mailchimp Marketing支持 campaign email activity 查询支持报告统计campaign 明细官方未明确;list activity 聚合最多 180 天支持报告下载
Mailchimp Transactional支持 outbound activity/search/export总体统计永久邮件正文 30 天,bounce 详情 90 天导出链接 7 天过期
Brevo支持 event/log/report支持统计报告超过 1000 万事件后,24 个月以上事件删除;企业可 10 年建议定期导出/API 导出
ActiveCampaign支持 campaign report 明细导出支持 campaigns performancearchived contact 历史互动数据一年后自动删除CSV 导出用于内部留档

DMTX 不建议直接采用“超过 6 个月完全不可查”的硬删除体验。建议采用三层策略:0-3 个月热数据保持现有体验;3-6 个月温数据仍可查但导出异步化;6 个月以上默认不提供在线逐条明细,改为归档异步下载和聚合统计。

4. 用户体验设计

数据年龄页面报表明细列表原始数据下载用户提示
0-3 个月实时/准实时可查可立即/异步下载无特殊提示
3-6 个月可查可查但可能较慢异步下载历史数据正在生成,完成后邮件通知
6-24 个月聚合统计可查默认不展示逐条明细申请后异步下载超过 6 个月的逐条明细将从归档数据生成
24 个月以上默认仅保留聚合摘要不提供企业服务单独处理超长期明细需联系客户成功确认保留范围

核心流程

  1. 客户在报告下载页选择活动、数据类型、时间范围。
  2. 系统自动判断热库、冷库或混合范围;如包含归档数据,提示生成时间较长。
  3. 客户点击导出/申请导出,文件生成后通过邮件通知,下载链接默认 7 天有效。

默认值

热数据保留3 个月保证近期体验
明细在线保留6 个月超过 6 个月默认不提供逐条在线明细
冷库归档保留24 个月对齐 Brevo 高事件量策略,可评审调整
企业延长保留可配置,最长 10 年对标 Brevo Enterprise
归档观察期7-14 天归档完成后不立即删除热库,便于回退

5. 技术方案

阿里云 MongoDB 热库
  ├─ send_record_*    0-3/6个月热明细
  ├─ events_*         事件明细,供 DMTX 回收和报表
  ├─ mail_link        链接字典
  └─ open_report      聚合报表
        │ DTS/归档任务同步
        ▼
扬州机房冷库/归档存储
  ├─ iemail_archive.send_record_yyyyMM
  ├─ iemail_archive.events_yyyyMM
  ├─ iemail_archive.mail_link_snapshot
  ├─ iemail_archive.open_report_snapshot
  └─ archive_manifest / archive_job
        │ 历史导出服务
        ▼
DMTX/Iemail 下载任务
  ├─ 热数据:走现有 DMTX contact_dmd_log 或 Iemail Mongo 查询
  ├─ 冷数据:走扬州冷库生成文件
  └─ 混合范围:热冷拆分后合并 zip/CSV

方案一:减少发送记录热库存储

方案二:历史数据冷处理

6. 数据模型与 API

核心数据模型

表/模型关键字段用途
iemail_archive_jobcompany_sn, database_name, collection_name, collection_type, archive_month, source_count, archive_count, status记录归档任务状态和清理水位
iemail_archive_manifestarchive_job_id, archive_path, min_object_id, max_object_id, min_event_ts, max_event_ts, retention_until保证每批归档可审计、可追溯
iemail_retention_policyhot_retention_days, online_detail_days, archive_retention_months, content_hot_days, cleanup_grace_days支持全局和租户级保留策略
iemail_export_requestcompany_sn, send_task_ids, event_types, start_time, end_time, source_mode, status, file_url管理历史导出任务

核心 API

GET /inner-api/iemail/v1/data-availability
POST /inner-api/iemail/v1/archive-export-requests
GET /inner-api/iemail/v1/archive-export-requests/{requestId}
POST /inner-api/iemail/v1/archive-jobs
POST /inner-api/iemail/v1/archive-jobs/{jobId}/cleanup

7. 边界情况

边界情况风险处理策略
DTS 延迟或中断冷库数据不完整,误删热库清理必须依赖 archive manifest 校验通过,不能只看 DTS 状态
归档期间有迟到事件events_* 迟到写入导致冷库缺数据归档窗口增加 7 天 safety lag;按 eventTs + consumedAt 双条件校验
混合时间范围导出热冷数据重复或漏数按时间边界拆分,使用 sendId/eventId 去重
mail_link 缺失点击导出无法还原链接标题跟随 sendTaskId 快照,缺失时退化展示 URL/linkId
Mongo 删除后空间不下降成本没有立刻降低需要 compact、集合重建或实例迁移释放物理空间
客户合同要求长期明细默认策略不满足支持租户级 retention policy 和企业延长保留

8. DMTX 报告下载事实源边界

DMTX 报告下载默认继续以 contact_dmd_log 为事实源。本次 Iemail send_record_* 磁盘治理不应默认改变 DMTX 现有原始数据导出口径,否则会引入字段映射、事件去重、统计口径和导出列不一致风险。

  • 纯 DMTX 可用范围:继续从 contact_dmd_log 导出。
  • Iemail 冷库:仅作为 contact_dmd_log 不可用、已归档或需要补齐 Iemail 原始发送明细时的补充/兜底路径。
  • 混合范围:默认打包为独立 CSV,明确标注“DMTX 原始数据”和“Iemail 归档补充数据”,不静默合并。
  • 上线前必须完成 events_*/send_record_*contact_dmd_log 导出字段的映射、去重规则和抽样对账。

9. 实施计划与工作量

阶段时间工作内容预期收益
阶段 0:评审与数据确认本周确认客户承诺、DTS 网络权限、冷库形态、Top 字段采样形成可落地范围
阶段 1:快速止血1-2 周释放可回收空间、开启新写入瘦身、增加容量日报控制新增膨胀
阶段 2:冷归档 MVP3-5 周DTS 链路、归档模型、单客户单月份试点、校验证明冷库可下载可排查
阶段 3:热库清理与下载路由5-8 周DMTX 接入 data availability,Iemail hot/cold/mixed reader,字段裁剪和物理释放显著降低热库空间
阶段 4:产品化后续租户级策略、企业延长保留、客服后台、自动审计长期治理闭环

从 MVP 到可灰度预计 44-67 人日

10. 本周评审决策点

决策点建议结论不确认的风险
客户/合同是否承诺长期逐条明细默认不承诺 6 个月以上在线逐条明细,提供异步归档导出清理后可能违反客户承诺
contact_dmd_log 保留周期先确认 PG 现有归档策略,再决定是否单独冷归档DMTX 下载和 Iemail 冷库口径冲突
冷库形态MVP 优先 MongoDB/兼容 Mongo,后续评估 Parquet/对象存储查询与导出改造成本不可控
DTS 到扬州机房可行性本周确认网络、权限、延迟、费用和失败告警归档链路无法落地
content 正文保留允许 30 天后从热库删除或对象存储化send_record_* 新增空间继续膨胀
默认冷库保留期默认 24 个月,企业客户可配置更长保留周期无产品边界,成本不可控

11. 推荐结论

推荐采用“两条线同时推进”的组合方案:

  1. 产品策略线:0-3 个月热明细、3-6 个月温明细、6 个月以上归档异步下载,长期保统计摘要。
  2. 技术治理线:以 send_record_* 为主目标,先归档再裁剪/删除,配合 compact/集合重建释放物理空间。
  3. 体验保护线:DMTX 报告下载保持现有入口,系统自动判断热/冷数据,客户只感知“历史数据生成较慢”。
  4. 商业弹性线:默认冷库保留 24 个月,企业客户可购买或配置更长留存。

12. 质量自检

检查项得分说明
需求背景清晰3/3明确内部成本优化、本周评审、全场景覆盖
竞品调研充分4/4调研 Mailchimp、Brevo、ActiveCampaign,区分明细和统计
用户体验设计4/4给出 0-3/3-6/6+ 月用户路径、提示、默认值
技术架构可落地4/4基于现有 DMTX/Iemail 源码链路设计热冷路由
数据模型与 API6/6字段级模型和接口出入参明确
边界、工作量、回退10/10覆盖 DTS 延迟、迟到事件、混合导出、物理释放、观察期回退
总分31/31通过,超过 20 分提交标准

13. 参考来源