如果面试官问怎么直接整合成一个文档呢?
采用的是懒惰的、渐进式的整合方案。如果我先查询A文档之后发现A文档还没有嵌入B文档,那么就查询B文档,嵌入进A文档之后,直接更新A文档。在更新A文档的时候,要采用乐观锁策略,也就是在更新的条件里,加上A文档不包含B文档这个条件。
这个业务有一个好处是,没有直接更新B文档的场景,都是通过A来操作B文档,所以不需要考虑其他的并发问题
这种懒惰更新策略里的最后一步更新动作,实际上就是一个乐观锁。所以也可以尝试把话题引导到乐观锁上。
不过,嵌入整个文档是很罕见的优化手段。更加常见的是嵌入部分字段,也叫做冗余字段。这种优化手段在关系型数据库里也很常见,比如A经常使用B的某几个字段,那么就可以在A里面冗余一份。但是这种冗余的方案会有比较严重的数据一致性问题,只有在你能够容忍这种数据不一致的时候,才可以应用这个方案。
在现实中最常见的场景就是在别的模块的文档里冗余用户的昵称、头像,这样可以避免再次去用户文档里查询昵称或头像。毕竟这两个在很多时候都不是什么关键字段。
操作系统优化
前面基本都是查询本身的优化,也可以准备一些操作系统优化的点。
内存优化
在MongoDB里,索引对性能的影响很大,所以应该尽可能保证有足够的物理内存来放所有的索引。
swap
同样需要避免触发交换,可以调小vm.swappiness 这个参数