尽管使用SSD可以获取高性能，MongoDB中的日志功能由于其连续写入机制，可以为系统提供更快更方便的硬盘体验。本文档中后续关于日志的章节会有更多的介绍
建议MongoDB部署时使用RAID10。RAID5和RAID6由于其本身显示提供不了足够的性能。RAID0可以提供良好的读写性能，但是系统冗余性不足。MongoDB的复制集可以为数据提供高可用性，要满足系统的高可用，应该考虑复制集、RAID机制以及其他因素。
压缩使用默认的WiredTiger存储引擎时，MongoDB本身就支持压缩功能。压缩机制能大概减少80%的存储占用，由于从硬盘中读取的数据字节少，能提供更高的存储I/O扩展性。与其他压缩算法一样，管理员使用压缩功能，虽然提供了存储能力，同时带来了较高的CPU负载，因此在你自己的环境中对压缩带来的影响进行测试是非常重要重要的。
MongoDB为文档、索引、日志提供了丰富的压缩选项。默认的Snappy压缩算法在较高的文档以及日志压缩比率（一般是70%，具体要看数据）和较低的CPU负载之间提供了很好的平衡性，zlib算法虽然压缩比率高，但是当数据写入硬盘以及从硬盘中读取时也会导致较高的CPU周期。WiredTiger的索引使用前缀压缩，减少内存中的索引存储的占比，为那些经常访问的数据腾出空间。管理员可以修改默认的压缩设置。压缩机制也可以根据集合的创建指定在特定的集合上使用。
CPUMongoDB在更快的CPU上能提供更好的性能。MongoDB的WiredTiger存储引擎比MMAPv1能更丰富的利用多核处理器资源。Encrypted存储引擎由于一部分CPU要用来进行加密和解密的工作，会比WiredTiger多平均15%的系统负载，具体的数量还要看你的数据集大小。
每个主机的进程要获取***性能，建议用户在每个主机上单独运行一个mongod。使用虚拟化和容器技术为系统分配合理的容量和资源，这样在单个服务器上就可以运行多个MongoDB进程且不存在资源争夺。使用WiredTiger存储引擎时，管理员需要估算每个实例使用总RAM的比例，并为每个实例分配合理的缓存大小。
为了系统可用性，同一个复制集的多个成员不应该部署在同一个硬件设备上，也不应该共用任何单一的故障资源，比如电源。如果系统部署在云上，确保虚拟化厂商的跨可用性部署能力，以保证每个复制集的成员在物理上是隔离的，不会共用一个电源、应用程序或者网络。
虚拟化以及IaaS在虚拟化以及云环境中，用户可以把MongoDB部署在裸机之上。一般来说，部署在裸机上的系统其性能表现是***的，尽管很多MongoDB用户会考虑IaaS平台，比如AmazonWeb Services\' Elastic Compute Cloud (AWS EC2), Google Compute Engine, Microsoft Azure, Rackspace以及其他的。
调整mongos和配置服务器进程对于分片系统，除了数据存储进程，还需要另外部署两个系统：mongos查询路由以及配置服务器。分片服务器是物理隔离的多个服务器。关于分片的更多信息，详见水平扩展相关的章节。所有查询操作会被一个叫做mongos的路由进程路由到合适的分片服务器上。Mongos决定一个查询怎么路由，配置服务器维护的是元数据。Mongos和配置服务器是同样重要的，但是两个都有不同的尺寸要求。
分片中，MongoDB会把文档分成块。MongoDB把块与分片服务器之间的关系当做元数据存放在配置服务器中。每个分片部署中，最少有单个配置服务器以保证任何时候元数据的可用性。分片的元数据访问频率比较大：每个mongos维护一部分缓存数据，这些缓存数据会周期性在后台进行更新，一般是由集群扩张引起的数据平衡操作时。因此配置服务器的硬件配置就尤其需要考虑可用性使用冗余电源、冗余RAID控制器以及冗余存储。配置服务器可以部署成复制集，但是最多只能有50个成员。
一般MongoDB分片系统中会有多个mongos实例。很少有用户为每个应用部署一个mongos实例。Mongos服务器的***数量取决于应用的具体负载：有些场合下mongos只是查询路由到合适的分片上，有些场合下mongos除了路由查询还需要把结果集进行合并。评估每个mongos的内存需求时，需要考虑如下几个方面：
l 在mongos中缓存的分片元数据的总大小
l 每个应用链接会消耗1MB
Mongos进程使用的RAM是有限的，CPU越快或者网速越快mongos的表现越好。
操作系统和文件系统 Linux的配置