MongoDB搜索的数据建模与模式设计 第一部分：实践考量
内容提要
本文是MongoDB搜索模式设计指南第一部分，聚焦物理约束与基础概念。核心观点：文档分组由工作负载决定。$search须为聚合管道首阶段，通过mongot调用Lucene，返回按相关性排序的批量结果，应限制结果并分页。每个索引最多约20亿个索引对象，嵌套文档映射会成倍增加对象数。设计要点：字段名与类型须一致，避免混用；建议用typeSet精简字符串索引以减小体积；可用视图实现部分索引、字段扁平化、向量降维和文本化。
延伸解读
物理约束决定搜索模式设计
MongoDB Search 的架构决定了模式设计必须考虑物理限制：$search 必须是聚合管道首阶段，且每个索引最多约20亿个索引对象。嵌套文档映射会成倍增加对象数，例如2亿文档每篇10个嵌入文档就会产生22亿对象，超出限制。因此设计时需评估嵌入文档数量，必要时改用扁平结构或分片。
字段一致性与typeSet优化
字段名和类型必须一致，混用类型会导致查询和分面只能匹配特定类型。默认动态映射会为所有字符串字段开启高开销选项，建议使用typeSet精简配置，如设置store:false和indexOptions:'positions'，可大幅减小索引体积。若需精确值查询，可将字符串映射为token类型。
视图实现索引前转换
视图可在索引前对文档进行过滤或变形，适用于部分索引、字段扁平化、向量降维和文本化等场景。例如用$match排除归档文档，用$set移除敏感字段，或用$addFields生成计算字段。视图管道受限但灵活，能帮助实现“按查询方式索引”的原则。
嵌入文档映射的权衡
嵌入文档映射为独立索引对象可实现子文档级匹配和分面，但每次更新会重新索引整个块，增加开销。是否使用取决于是否需要精确的子文档匹配及规模是否可控。若子文档需要独立返回，可考虑将其作为一级文档，而非嵌套结构。
Q&A
MongoDB Search 的 $search 阶段在聚合管道中有什么位置限制？
$search 必须是聚合管道的第一阶段（或 $unionWith 阶段），因为它没有输入文档集，直接调用 mongot 服务查询 Lucene 索引并返回按相关性排序的文档列表。
MongoDB Search 索引对文档数量有什么限制？嵌套文档会如何影响这个限制？
每个 MongoDB Search 索引最多约 20 亿个索引对象。每个集合文档至少对应一个索引对象，如果映射了嵌套文档（embeddedDocuments），每个嵌套文档也会成为一个独立的索引对象，从而成倍增加对象数量，可能触及上限。
在 MongoDB Search 中设计 schema 时，为什么字段名和类型必须保持一致？
因为 MongoDB Search 根据字段名和数据类型将文档字段映射到 Lucene 索引对象，字段名和类型决定了哪些内容可搜索以及如何搜索。如果同一字段名在不同文档中使用不同类型（如数字和字符串），查询和分面将只能匹配对应类型的数据，导致搜索结果不完整或错误。
什么是 typeSet？它如何帮助优化 MongoDB Search 索引大小？
typeSet 是索引配置中用于控制动态映射行为的机制，可以指定哪些类型被索引以及如何索引。默认的动态映射会为所有字符串字段启用高开销设置（如存储高亮所需的值和词偏移），而通过定义精简的 typeSet（例如设置 store: false 和 indexOptions: "positions"），可以显著减小索引体积。
如何使用视图（View）在 MongoDB Search 中实现部分索引或字段转换？
可以创建一个与搜索索引兼容的视图，其管道包含 $match 来排除不需要索引的文档（如已归档文档），或使用 $addFields、$set 等阶段转换文档结构（如计算数组长度、扁平化属性、降维向量、拼接文本字段）。然后在该视图上创建搜索索引，索引作业会使用视图输出的文档进行映射和索引。
在 MongoDB Search 中，嵌套文档应该使用 document 映射还是 embeddedDocuments 映射？各有什么优缺点？
document 映射（默认）将嵌套字段扁平化为根文档上的数组，查询会丢失嵌套文档内部的关联性（例如无法匹配“名为 Kid2 且年龄为 5 岁的孩子”）。embeddedDocuments 映射为每个嵌套文档创建独立的索引对象，支持精确的嵌套匹配和独立返回/分面，但会增加索引对象数量，且更新文档时会重新索引整个块，带来性能开销。应根据是否需要精确嵌套匹配以及规模是否可控来选择。
