MongoDB多投影性能内存影响及多语言文档结构优化咨询

• 唯一的优势是网络传输开销更低：服务端不需要把全量150种语言的翻译结果返回给客户端，只返回你指定的1-2种语言内容，这部分的收益是确定的。
• 但服务端的内存、磁盘IO开销几乎和全量返回没有差异：MongoDB的WiredTiger存储引擎是以完整页为单位读取数据的，就算你只需要单个语言的字段，也必须把包含完整文档的整个数据页从磁盘加载到内存缓存中。你当前的单份文档包含150种语言的翻译，体积是仅存单语言的100倍以上，这会导致内存缓存能容纳的文档数量大幅减少，频繁查询时缓存命中率下降，反而会触发更多随机磁盘IO，整体性能会很差。
• 额外的小开销：每次查询需要指定20+属性的对应语言字段，查询语句解析、服务端字段过滤的开销也会比直接查询单语言结构高一点，不过这部分影响不大。

下面是几种落地成本和收益不同的方案，可根据业务场景选择：

方案1：低改造成本的结构调整 #

把原来每个属性下嵌语言的结构，改成语言作为顶层键，同一语言的所有属性聚合在一起：

{
    "_id": "61a8cbb19a398cd2531b515e",
    "eng-us": {
        "property1": "translation text",
        "property2": "translation text",
        // 剩余20+属性
    },
    "eng-uk": {
        "property1": "translation text",
        "property2": "translation text"
    },
    // 剩余148种语言
}

改造成本极低，查询时投影只需要写{"eng-us": 1, "_id": 1}即可，不需要再写20+属性的投影规则，能降低查询语句解析和服务端字段过滤的开销，但还是解决不了完整文档加载进内存的问题，适合文档整体体积不大、访问量不高的场景。

方案2：读性能最优的按语言拆分集合 #

把不同语言的翻译数据拆成独立集合，比如集合名后缀加语言编码content_eng_us、content_fra_fr，每个集合内的文档只存对应语言的内容：

// content_eng_us集合内的文档结构
{
    "_id": "61a8cbb19a398cd2531b515e",
    "property1": "translation text",
    "property2": "translation text",
    // 剩余20+属性
}

这个方案的性能提升是最大的：单份文档的体积只有原来的1/150，相同内存空间能缓存的文档数量是原来的100倍以上，缓存命中率大幅提升，磁盘IO开销直接下降一个量级，查询也不需要做任何投影，读写性能都是最优的。唯一的缺点是写入时需要同时操作多个语言的集合，适合绝大多数本地化场景（读多写少）。

方案3：不拆分集合的覆盖索引优化 #

如果不想拆分集合，可以把翻译字段改成数组结构，配合覆盖索引实现不需要加载完整文档即可返回结果：

{
    "_id": "61a8cbb19a398cd2531b515e",
    "translations": [
        {
            "lang": "eng-us",
            "property1": "translation text",
            "property2": "translation text"
        },
        {
            "lang": "eng-uk",
            "property1": "translation text",
            "property2": "translation text"
        }
        // 剩余148种语言
    ]
}

给这个集合建覆盖索引：

db.collection.createIndex(
  { "_id": 1, "translations.lang": 1 },
  { include: ["translations.property1", "translations.property2" /* 剩余需要返回的属性 */] }
)

查询时直接通过索引就能拿到所有需要的字段，不需要加载完整文档到内存，也能大幅降低内存和IO开销，缺点是索引维护成本高，属性变动时需要修改索引，适合属性固定、写入频率低的场景。

内容的提问来源于stack exchange，提问作者Axel