优化MongoDB的4个技巧

在本文中，我们将介绍四种快速优化MongoDB的方法。

你有没有MongoDB数据库的性能问题？常见的情况是运行查询时突然出现性能问题。显而易见的第一个解决方案是，“让我们创建一个索引！” 虽然这在某些情况下有效，但在尝试优化MongoDB时还需要考虑其他选项。

性能不是因为拥有非常昂贵的磁盘和千兆网络的大型机器。事实上，这些并不一定是良好表现的关键。

MongoDB性能来自良好的概念，组织和数据分发。我们将列出一些良好的MongoDB优化的最佳实践。这不是一个详尽或完整的指南，因为有许多变量。但这是一个好的开始。

1.保持文件简单

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

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

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

2.硬件很重要，但......

使用具有多个处理器和大量内存的良好硬件肯定有助于获得良好的性能。

WiredTiger利用多个处理器来提供良好的性能。此存储引擎具有按文档锁定算法，因此可以同时运行尽可能多的处理器和尽可能多的操作（存在票证限制，但这超出了本文的范围）。但是，MMAPv1存储引擎必须锁定每个集合，有时无法利用多个处理器进行写入。

但是当一个实例死亡时，在有三台大机器（32个CPU，128个RAM和2TB磁盘）的环境中会发生什么？答案是它将进行故障转移 - 并且驱动程序足够智能以读取运行状况实例并编写新主数据库。但是，您的表现将不尽相同。

这并非总是如此，但在分布式环境中拥有多台小型/中型机器可以确保中断仅影响分片的几个部分，而应用程序很少或根本没有感知。但与此同时，更多的机器很有可能发生故障。在设计环境时考虑这种权衡。正确的选择会影响性能。

3.阅读Preference和writeConcern

read preference和writeConcern根据公司的要求而有所不同。但请记住，新的MongoDB版本（3.6）使用writeConcern：“ most ”和readConcern：“primary”。

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

请确保您使用最合适的阅读偏好并在您的公司中写下问题。驱动程序始终从主数据库读取，但如果它不是您的环境的要求，请考虑在其他实例之间分发查询。如果不这样做，则实例仅用于故障转移，不会在常规操作中使用。

4.工作集

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

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

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

希望你发现这篇关于如何优化MongoDB的文章很有帮助。

原文标题《4 Tips to Optimize MongoDB》

作者：Adamo Tonete

译者：February

不代表云加社区观点，更多详情请查看原文链接