拆分大文档
很常见的一种优化手段,在一些特定的业务场景中,会有一些很大的文档,这些文档有很多字段,而且有一些特定的字段还特别的大。可以考虑拆分这些文档
大文档对MongoDB的性能影响还是很大的,就我个人经验而言,认为可以考虑从两个角度出发拆分大文档:
- 按照字段的访问频率拆分: 访问频繁的放一个文档,访问不频繁的拆出去作为另一个文档
- 按照字段的大小来划分: 小字段放一个文档,大字段拆除去作为另外一个文档
之前拆分过一个文档,非常庞大。而且在业务中,有一些庞大的字段根本用不上,在这种情况下,一次拆除了三个文档。
- 访问频繁的小字段放在一起,作为一个文档
- 把访问不频繁的大字段拆出去作为一个文档。可以进一步优化为特定的巨大的字段可以直接作为一个文档
- 剩余的合并在一起作为一个文档
这样做的优点很明显,比较多的业务查询其实只需要第一种文档,极少数会需要第二种文档;但是缺点也很明显,如果调用者需要整个文档,也就意味着需要查询三次,再合并组成一个业务上完整的文档。
也可以升华一下:这种拆分终究是下策,最好还是在一开始使用MongoDB的时候就约束住文档的大小。
不过还有一个和这种策略完全相反的优化手段:嵌入文档
嵌入文档
如果A文档和B文档有关联关系,那么就在A文档里面嵌入B文档,做成一个大文档。
相当于原本A文档和B文档都是单独存储的,可能A文档里面有一个B文档的ID字段,又或者B文档里有A文档的ID字段,可以考虑合并这两个文档
可以这么介绍你的方案:
早期有一个过度设计的场景,就是有两个文档A和B,其中A里面有一个B的文档ID,建立了一对一的映射关系。但是实际上,业务查询的时候,基本上是分两次查询的,先把A查询出来,再根据A里面的文档ID也把B查出来。
后来这个地方慢慢成为了性能瓶颈,我就尝试优化了这个地方。我的想法是既然A和B在业务上联系那么紧密,我可以直接把他们整合成一个文档。整合之后,一次查询就能拿到所有需要的数据了,直接节约了一个MongoDB查询,提高了业务的响应时间,而且MongoDB的压力也变小了。
如果面试官问怎么直接整合成一个文档呢?
采用的是懒惰的、渐进式的整合方案。如果我先查询A文档之后发现A文档还没有嵌入B文档,那么就查询B文档,嵌入进A文档之后,直接更新A文档。在更新A文档的时候,要采用乐观锁策略,也就是在更新的条件里,加上A文档不包含B文档这个条件。
这个业务有一个好处是,没有直接更新B文档的场景,都是通过A来操作B文档,所以不需要考虑其他的并发问题
这种懒惰更新策略里的最后一步更新动作,实际上就是一个乐观锁。所以也可以尝试把话题引导到乐观锁上。
不过,嵌入整个文档是很罕见的优化手段。更加常见的是嵌入部分字段,也叫做冗余字段。这种优化手段在关系型数据库里也很常见,比如A经常使用B的某几个字段,那么就可以在A里面冗余一份。但是这种冗余的方案会有比较严重的数据一致性问题,只有在你能够容忍这种数据不一致的时候,才可以应用这个方案。
在现实中最常见的场景就是在别的模块的文档里冗余用户的昵称、头像,这样可以避免再次去用户文档里查询昵称或头像。毕竟这两个在很多时候都不是什么关键字段。
操作系统优化
前面基本都是查询本身的优化,也可以准备一些操作系统优化的点。
内存优化
在MongoDB里,索引对性能的影响很大,所以应该尽可能保证有足够的物理内存来放所有的索引。
swap
同样需要避免触发交换,可以调小vm.swappiness 这个参数
标签:面试题,嵌入,NoSQL,MongoDB,中间件,查询,文档,拆分,优化 From: https://blog.csdn.net/LightOfNight/article/details/140233224