硬件
你可以在任何地方运行 MongoDB –从ARM（64位）处理器到商用x86 CPU，再到IBM POWER和zSeries平台。
大多数用户通过使用多个服务器组成集群来扩展其系统。 MongoDB提供本机复制以确保可用性；自动分片以在服务器之间均匀分布数据；内存计算可在不依靠单独的缓存层的情况下提供高性能。以下注意事项将帮助您优化MongoDB系统的硬件:
确保您的工作集适合RAM。与大多数数据库一样，当工作集（索引和最常访问的数据）适合RAM时，MongoDB的性能最佳。 RAM大小是硬件最重要的因素。如果没有足够的RAM，其他优化可能不会显着提高系统性能。如果您的工作集超过单个服务器的RAM，请考虑在多个服务器之间共享数据库。使用db.serverStatus() 命令来查看当前工作集大小的估计值。
使用SSD来服务写入量大的应用。 MongoDB中的大多数磁盘访问模式都没有顺序属性，因此，使用SSD可以使客户获得实质性的性能提升。使用SATA，PCIe和NVMe SSD可以观察到良好的结果和极高的性价比。由于MongoDB的随机访问模式，商品SATA旋转驱动器可与成本更高的旋转驱动器相媲美：与其花更多钱购买昂贵的旋转驱动器，不如将钱花在更多RAM或SSD上。使用SSD的另一个好处是，如果工作集不再适合内存，则闪存比硬盘具有更高的性能。
尽管数据文件受益于SSD，但由于MongoDB的日志文件具有较高的顺序写入配置文件，因此它们是快速常规磁盘的理想选择。
大多数MongoDB部署应使用RAID-10。 RAID-5和RAID-6有局限性，可能无法提供足够的性能。 RAID-0提供良好的读写性能，但容错能力不足。 MongoDB的副本集允许部署为数据提供更强的可用性，并应考虑RAID和其他因素来满足所需的可用性SLA。
对存储和I/O密集型工作负载进行统一压缩。当使用WiredTiger和加密的存储引擎时，MongoDB本机支持压缩。压缩最多可减少80％的存储空间，并且由于从磁盘读取的位数更少，因此可以实现更高的IOP。与任何压缩算法一样，管理员用存储效率来换取CPU开销，因此测试压缩在您自己的环境中的影响非常重要。
MongoDB为管理员提供了一系列针对文档和索引的压缩选项。默认的Snappy压缩算法在较高的文档和日记压缩率（通常为70％，取决于数据类型）之间实现平衡，且CPU开销较低，而可选的zlib库将实现更高的压缩率，但是在写入数据时会产生额外的CPU周期并从磁盘读取。索引默认使用前缀压缩，这可以减少索引存储的内存占用，从而为经常访问的文档释放更多的RAM。尽管建议用户使用自己的数据集进行测试，但测试显示使用前缀算法的典型压缩率为50％。管理员可以修改所有集合和索引的默认压缩设置。还可以在收集和索引创建期间按每个集合和每个索引配置压缩。
结合多种存储和压缩类型。 MongoDB提供的功能可简化数据生命周期的管理，包括生存时间索引和上限集合。此外，通过使用MongoDB区域，管理员可以构建高效的分层存储模型来支持数据生命周期。通过将分区分配给区域，管理员可以通过基于时间戳等值将数据集分配给特定的存储设备来平衡查询延迟与存储密度和成本：
可以将启用了Snappy压缩的近期频繁访问数据分配给高性能SSD。
将访问频率较低的较旧数据标记到吞吐量较低的硬盘驱动器上，并在其中使用zlib对其进行压缩，从而以较低的每位成本获得最大的存储密度。
随着数据的老化，MongoDB会自动在存储层之间迁移它，而管理员不必构建工具或ETL流程来管理数据移动。
分配CPU硬件预算以获得更快的CPU。利用WiredTiger存储引擎，MongoDB将在更快的CPU上提供更好的性能，从而能够饱和多核处理器资源。
将每个服务器专用于系统中的单个角色。为了获得最佳性能，用户应在每个主机上运行一个mongod进程。通过使用虚拟化或容器技术进行适当的大小调整和资源分配，多个MongoDB进程可以在单个服务器上运行而无需争用资源。如果使用WiredTiger存储引擎，管理员将需要通过评估每个实例应使用的总RAM的哪个部分，并在每个实例之间分配默认的cache_size，来为每个实例计算适当的缓存大小。
WiredTiger缓存的大小可通过storage.wiredTiger.engineConfig.cacheSizeGB设置，并且应该足够大以容纳整个工作集。如果缓存没有足够的空间来加载其他数据，则WiredTiger会将页面从缓存中逐出以释放空间。默认情况下，storage.wiredTiger.engineConfig.cacheSizeGB设置为可用RAM的60％-1 GB；如果增加该值会引起注意，因为它会占用OS的资源，并且WiredTiger的性能实际上可能会由于文件系统缓存的效率降低而降低。
为了提高可用性，同一副本集的多个成员不应位于同一物理硬件上，也不应共享任何单点故障（例如电源）。
使用多个查询路由器。使用跨多个服务器的多个mongos进程。常见的部署是将mongos进程共定位在应用程序服务器上，这允许在应用程序和mongos进程之间进行本地通信。 mongos进程的适当数量将取决于应用程序和部署的性质。
Last updated