MongoDB中字段值的大小是否会影响对应索引的存储空间大小？

结论 #

优先选择将ID重编号为1 - 300,000的连续序号，收益极高，完全值得投入工作量；转换为更短的字母数字编码收益极低，没必要做。

具体原因分析 #

• 存储开销差异极大
  • 原有8-11位数字ID最大值接近100亿，超过32位整型上限，只能以64位整型存储（占8字节/个），如果之前存的是字符串格式，占用空间会达到8-11字节/个，还有字符串索引的额外开销。
  • 转换为字母数字编码（比如Base62）最多能把单ID长度压缩到6位左右，相比64位整型仅节省25%的空间，加上字符串索引的额外开销，实际索引压缩率大概率不足20%，完全解决不了内存不足的问题。
  • 重编号后的连续序号最大值仅30万，完全可以用32位整型存储（仅占4字节/个），相比原有64位整型直接省一半空间，如果原有ID是字符串格式，压缩率能达到60%-70%，再加上数据库对整型索引的存储优化，上亿条索引能轻松节省几十上百GB的空间，完全可以适配你的集群内存容量。
• 维护成本极低
  总共只有30万条原始ID，映射关系直接存在collection A的新增字段里即可，哪怕全量放到内存缓存也仅占用几MB空间，查询转换几乎没有性能损耗。数据迁移可以在低峰期分批处理collection B的条目，不需要停服，整体工作量很小。

额外优化建议 #

如果使用的是支持索引压缩的数据库，可以同时开启索引前缀压缩，连续整型ID的前缀重复度极高，配合压缩功能还能再降低30%左右的索引体积。如果数组内存在重复ID，存储前先去重也能进一步减少索引条目数。

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