1. 企业文档数据平台需求分析
企业文档数据平台建设的第一步不是选型，也不是部署集群，而是把“业务到底要什么、数据长什么样、平台要承担哪些责任”这三件事说清楚。需求分析做不扎实，后续无论选 MongoDB 还是其他数据库，都会陷入反复返工：模型改来改去、索引建了又删、容量估算严重偏离。本章围绕业务场景梳理、数据特征识别、平台目标定义与可行性评估四个环节展开，并给出可直接套用的分析框架。
一、业务场景梳理：从“谁在用”到“怎么用”
文档数据平台的业务场景通常不是单一的，而是多条业务线共用一套存储。梳理时建议按“业务域—使用角色—核心动作—数据读写比例”四个维度列表。以一个典型的企业内容中台为例，可能同时存在以下场景：
- 合同与档案管理：法务上传 PDF/Word，按合同编号、签约方、生效日期检索，读多写少，要求字段级权限。
- 工单与客服记录：客服系统高频写入会话记录，按客户 ID、时间范围查询，写入 QPS 高，单条文档小。
- 产品知识库：运营维护富文本与附件，支持全文检索和标签聚合，读多写少但查询模式复杂。
- IoT 设备日志：设备上报 JSON 事件，按设备号和时间窗口聚合，写入量极大，历史数据可归档。
梳理时不要只记录“业务名称”，而要落到可量化的动作上。例如“合同检索”应细化为：按 contractNo 精确查询、按 signParty.name 模糊匹配、按 effectiveDate 范围过滤，并统计各查询的日均调用次数与响应时间要求。这些数字直接决定后续索引策略和分片键选择。
二、数据特征识别：文档模型的“体检表”
MongoDB 是文档型数据库，数据特征识别要回答五个问题：文档结构是否稳定、单文档大小分布、字段嵌套深度、读写比例、以及是否存在多文档事务需求。以下是一份可填写的特征识别表（示例数据为合理假设，用于说明填写方式）：
| 特征项 | 合同档案 | 客服工单 | IoT 日志 |
|---|---|---|---|
| 日均写入量 | 约 2 万条 | 约 80 万条 | 约 1200 万条 |
| 读写比 | 9:1 | 1:3 | 1:20 |
| 单文档平均大小 | 180 KB（含附件引用） | 6 KB | 1.2 KB |
| 嵌套深度 | 3～4 层 | 2 层 | 2 层 |
| 结构稳定性 | 高，字段固定 | 中，标签动态 | 低，事件类型多 |
| 事务需求 | 需要（合同+审批流） | 弱 | 无 |
识别数据特征时，特别要关注“反模式”信号：单文档是否接近 16 MB 上限、是否出现无界数组（如把全部评论塞进一个文档）、是否频繁跨集合 $lookup。这些信号会直接推翻“文档模型一定比关系模型简单”的假设。对于 IoT 日志这类结构不稳定的数据，应允许字段动态扩展，但要在应用层约定必填字段，避免查询时全表扫描。
三、平台目标定义：把需求翻译成可验收指标
平台目标不能停留在“高性能、高可用”这类口号，而要转化为可验收的指标。建议从容量、性能、可用性、一致性、安全五个方面定义：
- 容量：三年内原始数据量约 45 TB，按 1.3 倍副本与索引膨胀估算，实际存储需求约 70 TB。
- 性能：合同精确查询 P95 < 50 ms；工单按客户+时间范围查询 P95 < 120 ms；日志聚合查询 P95 < 2 s。
- 可用性：核心合同库要求 99.95%，允许计划内维护窗口每月不超过 30 分钟。
- 一致性：合同与审批流跨集合操作需多文档事务；日志类允许最终一致。
- 安全：字段级权限、传输加密、审计日志保留 180 天。
这些指标要写进验收标准，而不是停留在需求文档里。例如“P95 < 50 ms”意味着必须为 contractNo 建唯一索引，且查询必须命中索引，不能依赖全集合扫描。
四、可行性评估：技术、成本与组织三线并行
可行性评估不是简单回答“能不能做”，而是评估“在当前约束下是否值得做”。技术可行性关注 MongoDB 版本能力是否覆盖需求，例如是否需要分片、是否需要事务、是否需要 Atlas Search 全文检索。成本可行性要估算服务器、存储、备份和人力成本。组织可行性则要确认是否有团队能维护副本集、处理故障转移、做容量规划。
下面这张图把本节四个环节串成一条从业务输入到平台目标的推导链，并标出每个环节的关键输出物，便于在实际项目中对照检查。
五、从分析到落地：一份可执行的需求分析清单
把上述内容整理成一份可执行清单，团队在项目启动会上逐项确认，可以显著减少后期返工。清单应包含：业务场景清单（含读写比例与响应要求）、数据特征体检表（含文档大小与嵌套深度）、平台目标指标表（容量/性能/可用性/一致性/安全）、可行性结论与风险项。每一项都要有明确的负责人和确认时间。
db.createCollection() 建一个空集合，插入 10 条代表性样例文档，用 db.collection.stats() 观察平均文档大小和索引占用，比纯理论估算更可靠。样例数据应覆盖最大、最小和典型三种情况。完成本章四个环节后，团队应能回答：平台要存哪些数据、数据长什么样、平台要达成什么指标、在当前约束下是否值得做。这四个问题的答案将直接指导第2章的 MongoDB 逻辑模型设计与集合划分。