MONGODB 性能优化 10 个TIPS 来自超级专家的经验

最新推荐文章于 2024-08-29 09:00:00 发布

Austindatabases

最新推荐文章于 2024-08-29 09:00:00 发布

阅读量3.9k

点赞数 3

文章标签：数据库大数据 python mysql java

本文链接：https://blog.csdn.net/liuhuayang/article/details/122593163

版权

偶然看到一个视频，关于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 达到一定成都后命中率会到达或接近100%, 数据的吞吐量也会提升。

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

8 Tune IO last

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

9 Replication set

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