0e82fd6ed7b1088791d8ae646823e2d7.png

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

bce6302c7b0a51c0622e6b1649dc2c79.png

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

15d2bb96462408864497757d752fe85f.png

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

2f699aa83c6fbf728ea708fbb7b48e2b.png

1   Be systematic

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

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

3c66e87116be0c7f8b0c28e619fc2d59.png

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

285fe4f94de26bd45ce50189822fb5c8.png

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

4a87fda5598acd15e271f43b70c4a0f5.png

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

2b49de8c6f4a823087ec20dc7878683f.png

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

2 Know your tools

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

9f455ff1011fdcdbaffdaf579375aba0.png

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

1796873257e0770a1973261e4fa17a4f.png

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

f27c9946ada424835e7c62dea96cce3f.png

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

3  Design you schema

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

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

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

c6ef5467e787c7ce420c8e959e2adf9b.png

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

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

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

4  index wisely

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

fd1dd3babb63ad0146edc052aaf5ffef.png

7e9f64db6a69e30bd4146e86c36ad3cd.png

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

f77695f919ebee73d6d2fc40f9d82eac.png

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

5  Use coding best practices

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

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

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

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

91ae2bcdd62e1a1a5fd5d59c6a3664e9.png

61dc5d32bd9f17c77b996ab5aa330a16.png

23dfa651c0168322dd52a32a538d4f52.png

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

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

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

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

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

154617b57c3ea00755c3862a4bed5475.png

6  exploit and tune aggregations

93c6c6f9053845f83541956eeeded373.png

052109dd435c91e95ddb5e53e89b23b6.png

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

7  Tune memory 

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

1  尽量让数据留在cache 中

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

482be6d6ec990c5ddd6305e36adf0c94.png

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

c5a8fde3de2546482f6ddc4de94a32ed.png

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

5251cc44b50fa0067a592a9165d1069f.png

8 Tune IO last

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

3992e126a3087cfea1af77625047602b.png

0e090390f2a309f88140f42531c0e7ee.png

9  Replication set 

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

12fcfdf39b5e7126966583f64872e25f.png

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

ef7e17ca05704166210770f851cc6368.png

10   shard only if you must

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

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

21941e6612352e18929611b30bfcf6a5.png

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

a6f5f57e8b26fc00df9d89806a12980a.png

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

61b598277741a5d84099fa131dbe8192.png

ea10477aee69978724b702188c6ce9b8.png

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

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

9ce29fc4d5de22c374c571a0131d5baa.png

Logo

华为开发者空间,是为全球开发者打造的专属开发空间,汇聚了华为优质开发资源及工具,致力于让每一位开发者拥有一台云主机,基于华为根生态开发、创新。

更多推荐