Embedding与Linking选型咨询：用户过滤器文档存储方案抉择

N=100时，优先选嵌入方案 #

先算笔账：每组过滤器最大10KB，100组加起来才1MB左右，远低于MongoDB单文档16MB的默认上限。从实际使用场景来看：

• 查起来更快：拿用户数据时能一次性拉取所有过滤器，不用额外做关联查询，少一次数据库交互，性能更优。
• 贴合数据关系：过滤器本来就是用户的附属数据，大多时候会和用户主体信息一起访问，嵌入模式更符合这种关联逻辑。
• 更新成本低：100组过滤器的修改对单文档来说开销很小，不会有明显的性能问题。

适合切换到链接方案的N阈值 #

没有绝对的精确数值，但可以从几个核心角度判断临界范围：

1. 单文档容量上限：MongoDB单文档最大16MB，扣掉用户自身的基础数据（比如账号、个人设置这些，预留2-4MB很有必要），过滤器的可用空间大概是12-14MB，对应1200-1400组。但这是理论上限，实际别用到这么满。
2. 性能损耗临界点：当用户文档超过8MB时，每次查用户都会带大量过滤器数据，哪怕有些场景不需要全部，会徒增网络传输和内存占用的成本。而且频繁更新大量过滤器时，单文档的修改锁开销也会上来。
3. 业务场景特殊性：如果过滤器需要独立查询、共享给其他用户，或者更新频率比用户主体数据高很多，哪怕N没到上面的数，也可以考虑链接方案。

综合下来，当N超过500-800时，就该优先考虑链接方案：把过滤器单独放在Filters集合里，用用户ID关联。这样既能避开单文档过大的坑，也能灵活处理过滤器的独立操作需求。

内容的提问来源于stack exchange，提问作者Bear Bile Farming is Torture