如果你已经完成了自己新的MongoDB应用程序的开发，并且现在正准备将它部 署进产品中，那么你和你的运营团队需要讨论一些关键的问题：
最佳部署实践是什么？
为了确保应用程序满足它所必须的服务层次我们需要监控哪些关键指标？
如何能够确定添加分片的时机？
有哪些工具可以对数据库进行备份和恢复？
怎样才能安全地访问所有新的实时大数据？
本文介绍了硬件选择、扩展、HA和监控。在查看详细信息之前，首先让我们处 理一个最常见的问题：
部署MongoDB和部署RDBMS有什么不同？
你会发现MongoDB作为一个文档数据库，它和你已经熟悉的关系型数据库分享 了很多同样的概念、操作、策略和过程。监控、索引、调整和备份等内容的流程 和最佳实践可以应用到MongoDB。同时如果你想要开始自己的培训，那么可以从 MongoDB大学中获取到来自于开发者和DBA的免费在线课程。
系统性能和容量规划是两个重要的主题，任何部署都需要处理这两个问题，无 论是RDBMS还是NoSQL数据库都是如此。作为规划的一部分我们应该对数据卷 （volume）、系统负载、性能（吞吐量及延迟时间）和容量利用建立基线。这些 基线应该反映你对数据库在产品环境中执行的工作负载的期望，它们应该随着用 户数、应用程序功能、性能SLA或者其他因素的变化定期地调整。
基线将帮助你理解系统哪些时候是按照设计运行的，哪些时候可能会影响用户 体验质量或者其他决定性系统因素的问题开始浮现。
下面将会讨论关键的部署要素，包括硬件、扩展和HA，同时还会讨论为了维持 最佳的系统性能你应该监控哪些内容。
清楚自己的工作集
在为部署MongoDB优化硬件预算的时候，RAM应该是或者接近于列表的第一位。
为了实现低延迟的数据库操作MongoDB中广泛使用了RAM。在MongoDB中，所有 的数据都是通过内存映射文件读取和操作的。从内存中读取数据是使用纳秒来度 量的，而从磁盘中读取数据则是使用毫秒度量的，所以从内存中读取数据几乎比 从磁盘中读取要快了十万倍。
在正常操作期间最频繁访问的数据和索引的集合称为工作集，在理想的情况下 它们应该在RAM中。工作集可能是整个数据库的一小部分，例如最近的事件所关联 的应用程序数据或者最常访问的热门产品。
MongoDB试图访问数据时发生的页面错误并不会被加载到RAM中。如果有空闲内 存，那么操作系统将定位到磁盘上的页面并将它们直接加载到内存中。但是如果 没有空闲内存，那么操作系统必须将内存中的一个页面写入磁盘，然后将被请求 的页面读取到内存中。这个流程比访问已经存在于内存中的数据要慢。
有些操作可能会在不经意间从内存中清除大量的工作集，这样会对性能产生严 重影响。例如，对于一个浏览数据库中所有文档的查询而言，如果数据库比服务 器上的RAM大，那么将会导致文档被读入内存而工作集被写出到磁盘。在项目的模 式设计阶段为自己的查询定义合适的索引将会极大地降低这种风险发生的可能性 。MongoDB说明操作能够为查询计划和索引的使用提供信息。
MongoDB服务状态命令中包含了一个有用的输出：工作集文档，它提供了一个 MongoDB实例工作集的估算大小。运营团队可以按照给定的时间跟踪实例访问的页 面数，包括工作集中最旧的文档到最新的文档之间的运行时间。通过跟踪这些指 标我们能够发现什么时候工作集会接近现在的RAM限制从而积极地采取行动确保系 统是可扩展的。
MongoDB管理服务和mongostat能够帮助用户监控内存的使用情况，下面我们将 会对此进行详细地讨论。
存储和磁盘I/O
MongoDB不需要共享存储（例如存储区域网络）。MongoDB能够使用本地附加的 存储和固态硬盘（SSD）。
MongoDB中的大部分磁盘访问模式并没有顺序属性，这样做的结果便是客户可 以通过使用SSD获得巨大的性能收益。我们已经观察到使用SATA SSD和PCI获得的 良好结果和强大的性能。商业SATA旋转驱动器可以媲美成本更高的旋转驱动器， 这得益于MongoDB的非顺序访问模式：应该更有效地使用预算将其用于更多的RAM 或者SSD上，而不是更多地用于昂贵的旋转驱动器上。
在数据文件受益于SSD的同时，MongoDB的日记文件由于其自身的高顺序的写属 性成为了快速常规磁盘的一个很好的候选。
大多数MongoDB部署应该使用RAID-10。RAID-5和RAID-6没有提供足够的性能。 RAID-0提供了很好的写性能，但是读性能有限，容错能力也不足。部署的MongoDB 可以通过副本集（下面将会讨论）提供很强的数据可用性，同时用户应该考虑使 用RAID和其他因素满足想要的SLA可用性。
虽然我们应该设计MongoDB系统让它的工作集适合于内存，但是磁盘I/O依然是 一个关键的性能考虑。MongoDB会定期地将写操作刷新到磁盘并提交到日记，所以 在写负载较重的时候基础的磁盘子系统可能会变得不堪重负。iostat命令可以用 于显示高磁盘利用率和过多的写队列。
CPU选择——速度还是内核？
MongoDB的性能通常不会绑定到CPU上。因为MongoDB很少会遇需要利用大量内 核的工作负载，比起时钟速度较慢的多核服务器最好的选择是有更快的时钟速度 。
无论是什么系统，测量CPU的利用率都是非常重要的。如果观察到CPU的利用率 很高但是并没有出现磁盘饱和或者页面错误这样的其他问题，那么系统中可能会 存在不寻常的问题。例如，一个存在无限循环的MapReduce工作或者一个没有建立 良好索引就对工作集中的大量文档进行排序和过滤的查询都可能会导致CPU利用率 的飙升，但是它们却不会引发磁盘系统问题或者页面错误。用于监控CPU利用率的 工具将在下面介绍。
扩展数据库——何时扩展和如何扩展？
MongoDB通过一种称为Sharding的技术提供了水平扩展能力。Sharding能够在 多个物理分区（称为片）之间分发数据。Sharding可以让MongoDB的部署解决单个 服务器的硬件限制而不需要增加应用程序的复杂性，解决的硬件限制包括RAM和磁 盘I/O的瓶颈。
