mongodb天然支持非结构化数据存储，无需预定义schema；推荐用聚合管道替代已弃用的mapreduce，因其性能更优、调试更易、支持分片；字段命名规范比后期转换更重要。
非结构化数据在MongoDB里不用特殊处理，直接存就行
MongoDB 的文档模型天然适配非结构化数据——比如日志片段、用户行为快照、爬虫抓取的 HTML 片段、带嵌套字段的 JSON 报文。你不需要预定义 schema，也不用为缺失字段建空值占位。insertOne 或 insertMany 接收任意形状的 BSON 文档，字段可多可少、类型可变（String 和 Date 混在同一个字段名下也行，只要应用层能接受）。
但要注意：字段名不一致（比如 user_id / userId / UID）会导致索引失效、聚合难对齐；深度嵌套（超过 100 层）可能触发 BSON 16MB 限制或影响查询性能；二进制大对象（如 base64 图片）建议用 GridFS 分离存储，别硬塞进文档。
MapReduce 在 MongoDB 里已不推荐用于常规转换
从 MongoDB 4.4 开始，mapReduce 命令被标记为 deprecated；5.0 起官方文档明确建议迁移到 $group + $sum 等聚合管道操作符。原因很实际：
-
mapReduce必须把中间结果写入临时集合，IO 开销大，且不能利用内存排序和流水线优化 - JavaScript 引擎（SpiderMonkey）执行 map/reduce 函数比原生 C++ 聚合引擎慢 3–10 倍，尤其数据量过百万时
- 不支持分片集群上的并行 reduce（除非手写
out: { sharded: true }，但维护成本高） - 调试困难：错误堆栈指向 JS 函数内部，而聚合管道的每个阶段都能用
$facet或$addFields逐步验证
如果你正在维护老项目里的 mapReduce 脚本，优先考虑用聚合重写。例如统计每类用户的平均订单金额：
db.orders.mapReduce(
function() { emit(this.userType, this.amount); },
function(key, values) { return Array.sum(values) / values.length; },
{ out: "avg_by_type" }
)
等价于更简洁、更快、可 pipeline 复用的写法：
db.orders.aggregate([
{ $group: { _id: "$userType", avgAmount: { $avg: "$amount" } } }
])
真要用 MapReduce？只在三类场景下考虑
不是完全不能用，而是得清楚它存在的合理边界：
- 需要在 map 阶段做复杂正则解析或调用外部 JS 库（如自然语言分词），且无法用
$regex或$function（>= 4.4）替代 - 输出目标是磁盘文件（
out: { inline: 0 }配合file选项），而非数据库集合——比如导出清洗后的 CSV 原始数据 - 存量系统已重度依赖
mapReduce，且升级聚合逻辑的成本 > 运维风险（这时至少把jsMode: true加上，避免 BSON↔JS 类型反复转换）
注意：scope 参数传入的变量在分片环境下不可靠；finalize 函数无法访问原始文档字段，只能处理 reduce 输出；所有 JS 函数里禁止使用 print()、sleep() 等阻塞调用，否则会卡住整个 mongod 实例。
读写非结构化数据时，聚合管道比 MapReduce 更灵活
面对字段缺失、类型混杂、嵌套不规则的文档，聚合阶段能边读边修，无需预处理：
- 用
$ifNull或$coerce（5.0+）统一字段类型，比如把"123"和123都转成数字 - 用
$cond+$type判断字段是否存在或类型是否匹配，再分支处理 - 用
$objectToArray动态展开未知 key 的子文档，配合$filter提取特定模式字段 - 用
$merge直接把聚合结果写回原集合（指定on: "_id"可实现 upsert）
比如清洗一批含错别字字段名的日志：user_id、uid、U_ID 都要归一为 userId，用一条聚合就能搞定：
db.logs.aggregate([
{
$addFields: {
userId: {
$cond: {
if: { $gt: [{ $strLenCP: "$user_id" }, 0] },
then: "$user_id",
else: {
$cond: {
if: { $gt: [{ $strLenCP: "$uid" }, 0] },
then: "$uid",
else: "$U_ID"
}
}
}
}
}
}
])
这种动态字段映射能力，是 MapReduce 做不到的——它要求 map 函数里硬编码所有可能字段名。
真正棘手的从来不是“能不能存”，而是“字段语义是否稳定”和“下游消费方能否容忍结构漂移”。MapReduce 解决不了语义问题，聚合管道也只是工具。设计阶段就约定好字段命名规范，比任何后期转换都管用。
