几种快速优化MongoDB的方法，从此优化不再难！

互联网的发展和电子商务平台的崛起，催生了大数据时代的来临，作为大数据典型开发框架的MongoDB成为了No-sql数据库的典型代表。

那么，在使用过程中你有没有遇到MongoDB数据库的性能问题？本文就给大家讲解几个MongoDB性能优化技巧。

1、保持文件简单

MongoDB是一个无架构的数据库。这意味着默认情况下没有预定义的架构。我们可以在较新的版本中添加预定义的架构，但它不是必需的。请注意使用嵌入式文档和数组时遇到的困难，因为在应用程序端/ ETL过程中解析数据会变得非常复杂。此外，数组可能会损害复制性能：对于数组中的每个更改，都会复制所有数组值！

在MMAPv1中，选择正确的字段名称非常重要，因为数据库需要保存每个文档的字段名称。这与在关系数据库中保存模式不同。让我们想象一下 ，如果你有一百万个文件，一个名为lastmessage的字段从传感器中获取的数据会花费你多少：大约28 MB只是为了保存这个字段名称！十个字段的集合将需要280MB（仅用于保存空文档）。

几乎达到此文档大小的文档是不可取的，因为数据库需要大量页面才能处理单个文档。这需要更多的CPU周期来完成任何操作。

2、阅读Preference和writeConcern

读取首选项和writeConcern根据公司的要求而有所不同。但请记住，新的MongoDB版本（3.6）使用writeConcern：“多数”和readConcern：“主要”。

这意味着它必须承认至少在所有写入（（N / 0.5）+1）的写入，其中N是副本集中实例的数量。这可能会很慢。然而，这对于速度的一致性来说是一个公平的权衡。

请确保你使用的是最适合您的阅读偏好，并在你的公司中撰写关注。驱动程序始终从主服务器读取，但如果它不是你的环境要求，请考虑将查询分发到其他实例中。如果不这样做，这些实例仅用于故障转移，并且不会在常规操作中使用。

3、工作集

工作集有多大？通常，应用程序不使用所有数据。有些数据经常更新，而其他数据则没有。

您的工作数据集是否适合RAM？当所有工作数据集都在RAM中时，会出现最佳性能。像页面错误一样，Wome的慢度可能会影响性能，具体取决于您使用的内容。

读取（例如备份，ETL或初级报告）可能会严重影响性能，因为存在缓存中页面的竞争。大型报告或聚合也是如此。将多个集合用于多种用途并将特定机器用于特定目的（例如使用区域来保存将不再使用的文档）将有助于实现简单和预期的工作集。

4、监控

mongodb可以通过profile来监控数据，进行优化。

查看当前是否开启profile功能用命令：db.getProfilingLevel()返回level等级，值为0|1|2，分别代表意思：0代表关闭，1代表记录慢命令，2代表全部。

开始profile功能为db.setProfilingLevel(level);

level为1的时候，慢命令默认值为100ms，更改为db.setProfilingLevel(level,slowms)如db.setProfilingLevel(1,50)这样就更改为50毫秒

通过db.system.profile.find() 查看当前的监控日志。

通过执行db.system.profile.find({millis:{$gt:500}})能够返回查询时间在500毫秒以上的查询命令。

5、千万不要让磁盘满了

80%的时候就要开始注意从集拆分片，如果你的数据增长特别快，很可能你还没有拆分磁盘就满了导致MongoDB挂掉了。如果数据量很大，尽量使用分片，不要使用副本集，做好磁盘容量规划，就是使用分片了也提前扩容，毕竟chunk迁移还是那么的慢。

6、其他方法

热数据法

可能你的数据集非常大，但是这并不那么重要，重要的是你的热数据集有多大，你经常访问的数据有多大(包括经常访问的数据和所有索引数据)。使用MongoDB，你最好保证你的热数据在你机器的内存大小之下，保证内存能容纳所有热数据。

文件系统法

MongoDB的数据文件是采用的预分配模式，并且在Replication里面，Master和Replica Sets的非Arbiter节点都是会预先创建足够的空文件用以存储操作日志。这些文件分配操作在一些文件系统上可能会非常慢，导致进程被Block。所以我们应该选择那些空间分配快速的文件系统。这里的结论是尽量不要用ext3，用ext4或者xfs。

硬件法

这里的选择包括了对磁盘RAID的选择，也包括了磁盘与SSD的对比选择。

以上就是我们为你整理的MongoDB优化技巧了，希望能对你有所帮助。