MongoDB操作最佳实践(五)

工作集

MongoDB广泛使用RAM来加速数据库操作。在MongoDB中，所有数据都是通过数据的内存表示来读取和操作的。WiredTiger存储引擎通过其内部缓存管理数据，但它也受益于保存在文件系统缓存中的页面。MMAPv1使用内存映射的文件。从内存读取数据以纳秒为单位，从磁盘读取数据以毫秒为单位；从内存读取数据比从磁盘读取数据快10万倍。

在正常操作期间访问的数据和索引集称为工作集。最佳实践是在RAM中设置工作集。工作集可能代表整个数据库的一部分，例如在与最近事件或流行产品相关的数据最常被访问的应用程序中。

当MongoDB试图访问尚未加载到RAM中的数据时，会发生页面错误。如果存在空闲内存，那么操作系统可以在磁盘上定位页面，并将其直接加载到内存中。但是，如果没有空闲内存，操作系统必须将内存中的页写入磁盘，然后在应用程序需要时将请求的页读取到内存中。这个过程可能很耗时，并且比访问已经驻留在内存中的数据要慢得多。

一些操作可能无意中从内存中清除了大部分工作集，这会对性能产生不利影响。例如，扫描数据库中所有文档（其中数据库大于服务器上的可用RAM）的查询将导致文档被读入内存，并且可能导致工作集的部分被写入磁盘。其他示例包括各种维护操作，例如压缩或修复数据库，以及重建索引。

如果您的数据库工作集大小超过系统的可用RAM，请考虑增加RAM容量或增加跨其他服务器对数据库的分片。有关此主题的讨论，请参阅“分片最佳实践”一节。在消耗系统资源之前实现分片要容易得多，因此容量规划是项目成功交付的重要因素。

当使用默认WiredTiger存储引擎时，请参阅配置WiredTiger内部缓存大小的文档。

如果MongoDB是用MMAPV1存储引擎配置的，请参考提供如何调整RAM大小的指导的文档。

 

MongoDB安装与配置

安装

MongoDB为.deb和.rpm包提供了用于一致性的安装、升级、系统集成和配置的仓库。这个软件使用了与MongoDB下载页面提供的tarball包相同的二进制文件。MongoDB Windows包可以通过通过其MSI安装的可下载二进制文件获得。在tarball2中还提供了OS X的二进制文件。

数据库配置

用户应该在mongod的配置文件中存储配置选项。这允许系统管理员跨整个集群实现一致的配置。配置文件支持所有mongod命令行输入的所有选项。可以使用诸如Chef和Ppuppet之类的流行工具来提供MongoDB实例。包含副本集和分片集群的复杂拓扑的提供可以由Ops Manager和Cloud Manager平台自动化，本指南稍后将讨论这些平台。

更新

用户应该尽可能频繁地升级软件，以便他们能够利用最新的特性以及任何稳定性更新或bug fies。升级应该在非生产环境中进行测试，以验证正确的应用程序行为。

客户可以在不引起任何停机的情况下部署滚动升级，因为副本集的每个成员都可以单独升级，而不会影响数据库的可用性。副本集合的每个成员都可以在不同的MongoDB版本下运行，并且使用不同的存储引擎运行。作为预防措施，应该参考MongoDB release notes来确定是否需要遵循特定的升级步骤顺序，以及两个指定版本之间是否存在任何不兼容性。升级可以通过Ops Manager和Cloud Manager自动进行。

数据迁移

用户应该评估如何最好地为其应用程序构建数据模型，而不是简单地导入遗留系统的文件。在传统的关系数据库环境中，数据往往使用例如CSV这样的 flat files来在不同系统间转移数据。虽然可以从CSV字段将数据提取到MongoDB中，但实际上这只是数据迁移过程中的第一步。MongoDB的文档数据模型通常提供以下不存在于关系数据模型中的优点和备选方案。

MongoDB提供了Mongoimport和mongoexport工具，用于以JSON或CSV格式简单导入或导出数据。作为初始步骤，这些工具在系统之间移动数据时很有用。其他工具，如mongodump和mongorestore，或者Ops Manager和Cloud Manager备份，对于在不同的MongoDB系统之间移动数据很有用。

有许多选项可以将数据从flat files迁移到丰富的JSON文档中，包括mongoimport、自定义脚本、ETL工具，以及从应用程序本身迁移数据，应用程序本身可以从现有的RDBMS读取数据，然后将文档的JSON版本写回MongoDB。

硬件

以下建议仅旨在为MongoDB部署的硬件提供高级指导。硬件的指定配置将取决于您的数据、查询、性能SLA、可用性要求以及底层硬件基础设施的能力。MongoDB具有丰富的经验，帮助客户选择硬件和调整配置，我们经常与客户一起计划和优化他们的MongoDB系统。健康检查、操作快速启动和生产准备咨询软件包在帮助您为项目选择合适的硬件方面尤其有价值。

MongoDB是专门针对商用硬件设计的，几乎没有硬件要求或限制。一般来说，MongoDB会利用更多的RAM和更快的CPU时钟速度。

内存

MongoDB使用RAM来充分提高性能。理想情况下，工作集适合于RAM。。一般来说，RAM越多越好。当工作负载开始访问不在RAM中的数据时，MongoDB的性能将会下降，就像任何数据库一样。MMAPv1将RAM的管理委托给操作系统。默认WiredTiger存储引擎通过允许用户配置分配给WiredTiger内部高速缓存的RAM数量，提供了对内存的更多控制——默认为RAM的60%减去1GB。WiredTiger还利用了操作系统的文件系统缓存，该缓存将持续增长以利用剩余可用的内存。

存储

MongoDB不需要共享存储（例如，存储区域网络）。MongoDB可以使用本地附加存储以及固态驱动（SSD）。MongoDB中的大多数磁盘访问模式不具有顺序属性，因此，客户可以通过使用SSD来体验显著的性能提升。用SATA SSD和PCIE测试表明了良好的结果和性能价格比。由于MongoDB的非顺序访问模式，商品SATA spinning驱动与成本较高的spinning驱动相当：该预算可以更有效地投资于增加RAM或使用SSD，而不是花费更多在昂贵的spinning驱动上。使用SSD的另一个好处是，如果工作集不再适合内存，则闪存优于硬盘驱动器的性能优势。

虽然数据文件受益于SSD，但MongoDB的日志文件由于具有高的顺序写入效率，非常适合于快速常规磁盘。有关更多信息，请参阅本指南后面关于日志的部分。

大多数MongoDB部署都应该使用RAID-1 0。RAID-5和RAID-6具有局限性，可能不能提供足够的性能。RAID-0提供了良好的读写性能，但是容错性不足。MongoDB的复制集允许部署为数据提供更强的可用性，并且应该考虑RAID和其他因素以满足期望的可用性SLA。

如果使用Amazon EC2，则在配置存储时，为了提供一致的存储性能，使用Provisioned-IOPS选项选择所需的IOPS速率。

联网时，在VM上运行时，对存储使用准虚拟化驱动程序。

压缩

MongoDB本地支持使用默认WiredTiger存储引擎时的压缩。压缩减少了高达80%的存储占用，并且实现了更高的存储I/O可伸缩性，因为从磁盘读取的更少。与任何压缩算法一样，管理员以存储效率换取CPU开销，因此在自己的环境中测试压缩的影响非常重要。

MongoDB为管理员提供了一系列文档、索引和日志的压缩选项。默认的Snapy压缩算法在具有较低CPU开销的文档和日志压缩比（通常取决于数据，大约70%）之间提供了良好的平衡，而可选的zlib库将实现较高的压缩，但是随着数据写入磁盘和从磁盘读取，将导致额外的CPU周期。WiredTiger中的索引使用prefix压缩，用于减少索引存储的内存占用，为频繁访问的文档释放更多的工作集。管理员可以修改所有集合的默认压缩设置。还可以在集合创建期间根据每个集合指定压缩。

CPU

MongoDB将在更快的CPU上提供更好的性能。MongoDB WiredTiger存储引擎比MMAPv1存储引擎更能够饱和多核处理器资源。与WiredTiger相比，Encrypted Storage引擎平均增加了15%的开销，因为一部分可用CPU用于加密/解密——实际的影响将取决于数据集和工作负载。