.png)
MongoDB Search 的数据建模与模式设计 第2部分：用例与模式
内容提要
本文介绍MongoDB Search的搜索数据建模与模式设计，核心原则包括：按最终搜索体验建模，将可搜索实体作为一等文档；同名字段保持类型一致；遵循“一起搜索的数据一起索引”。推荐采用实体模式，将电影、演员、类型等统一存入实体集合，以支持输入即建议、按类型过滤、分面与加权排序，并通过聚合管道从源数据同步生成实体。
延伸解读
实体模式：把“可搜索对象”提升为一等文档
文章以电影搜索为例，指出演员和类型在传统模型中只是电影文档的字段，但若用户希望直接输入“kea”找到基努·里维斯，或输入“doc”直达纪录片类型，它们就应作为独立实体存入专用集合。实体模式通过统一实体集合支持输入即建议、按类型过滤与分面，并允许为每个实体附加计算字段（如演员参演电影数、平均评分）用于加权排序。
属性模式在搜索场景下的隐患
文章明确提醒，常用的属性模式（将键值对存为{k: "key", v: "value"}）不适合直接用于MongoDB Search。因为索引按字段名映射，所有属性共用k和v字段，导致无法单独映射某个属性键，且不同类型值混在同一索引中。建议将需要搜索的属性转换为直接的field_name: value字段，以便按类型敏感的方式处理。
从现有数据同步实体集合的实践
实体集合通常需要从已有源数据同步生成。文章给出电影类型实体的聚合管道示例：展开genres数组、按类型分组计数、拼接唯一_id（如“genre-纪录片”）、设置type和name字段，最后用$merge写入实体集合。$merge会覆盖相同_id的文档，因此实体必须具有稳定且唯一的标识符，以便定期刷新。每个实体类型可有独立的同步流程和附加字段。
索引配置：一个name字段的多重分析策略
实体集合的索引配置核心在于对name字段使用“multi”多路索引，将同一字符串按多种方式分析：左边缘前缀、英文词干、小写、语音、词组shingle及默认分词。查询时对不同分析变体赋予不同权重（如精确匹配boost 10、前缀通配boost 5、语音boost 0.5），再乘以实体自身的weight字段，从而在输入极少字符时也能将最佳匹配排前。type字段则同时以token类型索引，支持精确过滤、加权和分面。
Q&A
MongoDB Search 的数据建模应该从什么角度出发？
应该从最终的搜索体验出发进行建模，将可搜索的实体作为一等文档。设计时要考虑用户期望的查询类型、内容如何组织以便导航和搜索，以及搜索结果呈现时如何帮助用户缩小或扩大搜索范围。
什么是 MongoDB Search 中的实体模式（Entity Pattern）？
实体模式将所有关键领域实体建模为一等文档，存放在一个专门的集合中，并配置针对性的 MongoDB Search 索引，以支持“随处查找任何内容”和“输入即建议”的用例。该模式允许通过多种方式匹配实体，并支持自定义排序因子。
为什么在电影搜索中，演员和类型也应该作为一等文档？
因为演员和类型对于电影搜索应用来说是真正的领域实体，用户可能希望直接通过输入演员名（如“kea”）找到其主演的电影，或通过输入“doc”找到纪录片。将它们作为一等文档可以支持输入即建议、按类型过滤、分面与加权排序等体验。
如何从现有数据集合中生成实体集合？
可以使用聚合管道从源数据中提取嵌套的实体，进行分组和计算，然后格式化并合并到实体集合中。例如，从电影集合中展开 genres 字段，按 genre 分组并计数，然后投影为实体文档格式（_id、type、name、weight），最后使用 $merge 阶段合并到 entities 集合。
实体集合的索引配置如何支持输入即建议？
实体集合的索引配置对 name 字段使用多重索引技术，以多种方式分析字符串（如左边缘、英语词干、小写、语音、shingled 等），从而支持灵活匹配和排序。同时，type 字段被索引为 token 以支持按类型过滤和分面。查询时可以通过 compound 查询组合不同分析方式的权重来提升最佳匹配。
在 MongoDB Search 中，同名字段的数据类型不一致会有什么问题？
同名字段的数据类型不一致会导致查询和分面出现问题。因为 MongoDB Search 基于字段名和数据类型进行索引，如果同名字段混合了不同类型，索引会将所有值混合在一起，可能导致映射错误或无法正确过滤和分面。因此应确保同名字段在所有文档中保持类型一致。
