绑定完请刷新页面
取消
刷新

分享好友

×
取消 复制
MONGODB 性能优化 10 个TIPS 来自超级专家的经验
2022-01-19 16:00:45




偶然看到一个视频,关于mongodb 的 10 erformance tuning TIPS , 介绍这与下面的三位是同时期的IT 工作者,下面图中的三位就没有必要介绍了,都是 big  potato,介绍者写过图中的这些书籍。 

据库从业者应该熟悉这个人,并且上面的mongodb performance tuning 是他和他儿子撰写的书籍。(这年月连写数据库的书籍都父子上阵 OMG),不认识这个大爷的可以自己 search ,他是谁。


下面就进入主题 , 10 TIPS  with  MONGODB  performance. 这里他列出了以下10个TIPS 关于mongodb 的优化方面的意见,我们下面一个一个过。



1   Be systematic


这里他提出了两个问题, Methodical  and  Empirical , 对于逻辑清晰方面,他提出的看法是,与传统数据库不同,MONGODB 的版本更迭较快,并且其中引入的新的概念也与传统数据库不同 MONGODB 4.4 与 MONGODB 5.0 之间也有不少的新东西,在使用MONGODB 的时候,要对你使用的解决方案有清晰的了解,而不是在对MONGODB 根本就不懂的情况下,在项目中直接去使用,并且你要理解你现在遇到的问题是什么,根本的问题在哪里,利用你的经验而不是盲目的尝试和试错。并且你要有一些列的传统数据库与MONOGODB 的使用经验,你能辨别出传统数据库与MONGODB 之间的性能差别,那些在你使用MONGODB 后会“好”。


总结:这部分,感觉他在 make him a hero




关于性能问题,他提出了下一个TIPS 就是解决性能的问题,你要清楚的认知问题在哪里,是MONGODB 做聚合的问题,还是性能不足(CPU, MEMORY)根据不同的问题,在不同的层面鉴别现象层面的问题和真正的原因。


对于MOGNODB 我们可以快速的基于MONGODB 的访问体系,这里的 MQL 的意思死 MONGODB  QUERY LANGRAGE,应用访问MONGODB SERVER , 并从WIRETIGER 引擎的内存中寻找数据,如果无法找到则在I/O系统中获取对应的数据。



你要理解你的数据库系统的工作负载,与你当前系统是否能承受这些负载,而不是一味的怪罪你的数据库系统不给力。



总结:数据库系统的工作负载有清晰的认识,是工作负载高的问题,或者是在MOGNODB 数据库中做大量的聚合的问题,自我要有认知。


2 Know your tools


在知道怎么来评判MONGODB 的性能问题的方法后, 你需要有一些工具来去,通过explain 来获取MOGNODB 执行语句底层的过程, 通过profiler 来捕捉慢查询语句和评估工作负载,通过 serverStatus 以及 currentOp 命令来获得当时MONGODB 的状态信息。

 



他们编写了一些工具,如mongotuning 可以快速的分析出执行计划的步骤和顺序以更人性化的方式展现出来。


profiling 针对profiling 他们也有撰写相关的统计分析,可以分析出慢查询语句类似 TOP  系列的慢语句等信息。


总结:对于MONGODB 中的一些常用的观察命令,他们有更细致的研究并且编写了一些工具的集合,更有效的通过原有的命令和信息总结出更多的检测的方法。


3  Design you schema


关于MOGNODB 的设计,这个大爷表达的意思是,在MOGNODB 设计中尤其是SCHEMA 设计中,主要的有两种设计, 这里叫 embedding 嵌入。

1种是将所有的信息都灌入到一个document , 将原有的关系型的设计多表的信息都灌入一个collection 中的一个document,这样的好处就是快,但缺点也很明显,一个document 会比较大, 并且更新数据是一个挑战。

2  第二种设计就是将信息冗余写入到多个collectionS 的多个documents, 但这样也会面临问题,在更新中如何将多个collections 中同样的信息进行更新。(目前MONGODB 已经支持跨库和跨collection的事务,同时更新并不是问题,而性能又变成另一个问题)



另一个问题所谓的外键的问题,在MONGODB中将一个collection的主键信息存储到另一个collection作为外键的形式存在,而在应用程序中来做所谓的JOIN collection的操作,这样的设计快速的UPDATE 也还是一个问题。


这里他提到一些解决方案,如 hybird bucket ,混合模式,以及属性形式的设计还有垂直分割等方式,不过因为时间的问题,这里就不展开了。


总结:MONGODB 的设计也是有很多方式和坑的,通过一些合理的设计可以避免这些问题。


4  index wisely


关于索引的问题,这边也提出了一些建议,并做了一些测试,在有索引,单索引选择,组合索引选择(不同组合)对于性能的影响,所以MONGODB 的索引的建立,并不是一件比传统数据库简单的事情。




同时他也对一个 collection 创建索引的多少,以及性能的问题进行了评估



除此以外还介绍了collection 的数据量与INDEX 之间的关系。 总结:索引的使用对于MONGODB 的作用非常大,但注意控制数据量与质量的关系。


5  Use coding best practices


下面来到第五点,代码对于使用MONGODB 好的经验,这里提到如下一些建议

1  避免将MONGODB 作为cache 使用,频繁查询数据不变动的数据,应该将这些数据加载为缓存,而不是频繁从MONGODB 中查询。


2  针对与节省网络方面的资源的设计,如一次批量提交MONGODB 的数据,

batchSize 的参数调整,并且做了NODEJS 关于调整参数后的性能比较



在MONGODB 中使用事务,而遇到 transaction retry 的情况下,可以考虑如下一些措施, 


1  将多个文档合并成一个文档 

2  将在commit 时容易产生冲突的操作放到事务的后

3  将比较热的collection 拆分成多个documents


总结:代码的优化与使用MONGODB 设计的合理性,是保证MONGODB 良好运行的至关重要的一环,在API 上的一些性能参数的调整有助于提高使用MONGODB 的效率。


6  exploit and tune aggregations




这一段中讲的比较短,总结可以使用 upsert 的对数据进行更新和插入的时候,就不要使用 aggregate 的 merge 的方式, 对于collection 中数据的update 针对大数据量的情况下,应该进行批量循环模式,而不是一条UPDATE 的方式来操作。


7  Tune memory 


根据下图,要有效利用 wiredTiger 的cache 尽量避免I/O 的操作

1  尽量让数据留在cache 中

2  尽量不要做sort 和聚合的操作,这样的操作会使用临时空间,动用I/O操作



内存的大小对于系统运行中的命中率对比的情况,cache的SIZE 达到一定成都后命中率会到达或接近, 数据的吞吐量也会提升。 


针对SORT 参数 internalQueryMaxBlockingSortMemoryUsageBytes ,如果这个设置在使用中超限了, 那么终会导致SORT 操作会走磁盘系统,导致查询或相关的操作缓慢。


8 Tune IO last

 

针对MONGODB 的特性,对MONGODB 使用的硬件有一些建议,分别对本地主机层使用的磁盘系统,以及磁盘阵列的方式,和云上磁盘系统对于NONGODB 的影响进行了分析。





9  Replication set 


 关于MONGODB 使用中大部分都是使用复制集的模式,这里对于两个关键的使用的方式 read preference 和  write concern 进行了分析和比较, 这里他举了一个极端的例子,主节点在 香港, 从节点在  汉城, 东京,和悉尼三个地方,分别采用不同的方式在四个地点进行读操作, 在选择主库读时,香港的读取速度是快的,而选择了secondary 读取的方式,香港是差的,而其他地方都是快的,选择近的方式,就比较平均了,但这里需要有一个提醒,就是这些数据是依赖于,写操作的,下面又对写操作进行了比较


在write concern中,包含了写入不反馈,写入一个节点反馈成功,以此类推,每个方式的write concern 对于写入性能的影响。但他强调 种方式是糟糕的 idea




10   shard only if you must


这里他强调了一个问题,在不同的角度,通过hash shard, rage shard 在每种场景下,如聚合, 查找,或者插入数据的情况下,取平均性能的情况下,都是不做sharding 的性能均衡,选择range 的方式是差的一种选择,基本上在上面的场景都是慢的,没有任何的性能提升。 

对于HASH 的SHARDING ,这样的方式仅仅在查找数据的情况下具有优势,但插入数据时是慢的。



在使用不同的shard key 时每种shard key的方式针对的查询的方式的优势,以及创建索引时的要求。查询中必须带有 shard key ,组合索引中也必须带有shard key


后面讲了一些关于 range shard 和 hash 的性能比对



总结: 如果使用shard  of mongo 必须找一个可以信的需求的原因,因为sharding 后整体的mongo db 的维护包含备份等问题都会出来,承载系统的重要性也会降低,所以如果没有充足的知识和能力,shard  的使用可能是噩梦的开始。


以上就是 10 TIPS OF MONGODB 的大致内容,介绍的比较笼统,但如果从每一个点进入,在去深入的研究,相信会有很多的收获,师傅领进门,修行在个人。


分享好友

分享这个小栈给你的朋友们,一起进步吧。

数据库杂货铺
创建时间:2021-12-10 09:57:47
分享数据库管理,运维,源代码 ,业界感受, 吐槽
展开
订阅须知

• 所有用户可根据关注领域订阅专区或所有专区

• 付费订阅:虚拟交易,一经交易不退款;若特殊情况,可3日内客服咨询

• 专区发布评论属默认订阅所评论专区(除付费小栈外)

栈主、嘉宾

查看更多
  • liuaustin
    栈主

小栈成员

查看更多
  • miemieMIA
  • 578154454
  • ylfxml
戳我,来吐槽~