|
如果你已经完成了自己新的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/OMongoDB不需要共享存储（例如存储区域网络）。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的瓶颈。
MongoDB自动分片和应用程序的透明度 在系统资源变得有限之前实现分片是非常容易的，因此容量规划和主动监控在需要成功地扩展应用程序时是非常重要的元素。 在下面的场景中用户应该考虑部署一个分片的MongoDB集群：
Sharding的目标之一就是在多台服务器之间一致地分发数据。如果服务器资源的利用率并不是近似地相等，那么可能会存在引发调度错误的潜在问题。例如，选择一个糟糕的分片键可能会导致不平衡的数据分发。在这种情况下，即便不是所有的但是大部分查询也会被导向到正在管理数据的那个单独的MongoDB。 另外，MongoDB可能会试图重新分发文档从而在服务器之间实现更加理想的平衡。虽然重新分发最终会实现一种更加令人满意的文档分发，但是有大量与重新平衡数据相关的工作，这些工作本身就有可能会产生影响导致无法实现预期性能的SLA。 通过运行db.currentOp()命令，你将能够了解集群现在正在执行哪些工作，包括跨分片的文档再平衡。 为了确保数据能够在集群中的所有分片间均匀地分发，选择一个优秀的分片键是非常重要的。MongoDB文档中包含了一个关于如何选择优秀分片键的教程。 MongoDB复制集的高可用性MongoDB使用本地复制维护复制集之间的多个数据副本。复制集可以通过发现错误（服务器、网络、OS或者数据库）和自动化故障修复避免停机时间。推荐的做法是：所有的MongoDB部署都应该配置复制。 （单击放大图片）
使用MongoDB复制集自恢复对主节点数据库的修改操作会通过名为oplog的日志被复制到其他二级节点上。oplog包含了一个排序的幂等操作的集合，该集合中的操作会在二级节点上重放。oplog的大小是可配置的，默认是可用磁盘空间的5%。 正如下面的图表所阐述的，可以通过定位副本为服务器、机架、数据中心故障和网络分区提供容错性。 （单击放大图片）
复制延迟是作为正常运行的一部分来监控的。它表示的是将主节点上的一个写操作复制到二级节点上所花费的时间。一定的延迟是正常的，但是如果复制延迟增长，则可能会引发问题。复制延迟产生的典型原因包括网络延迟、连接问题和磁盘延迟（例如二级节点的吞吐量劣于主节点）。 复制状态和复制延迟可以通过replSetGetStatus命令重新恢复。 日志概述作为所有部署的一部分，应该监控应用程序和数据库的日志以便发现错误并查看其他的系统信息。将应用程序和数据库的日志关联起来是非常重要的，因为这样才能决定应用程序中的活动最终是否需要对系统中的其他问题负责。例如，用户写入峰值可能会增加写入MongoDB的容量，这反过来可能会压垮下面的存储系统。如果没有应用程序和数据库日志的关联，那么可能要花费更多的时间才能够确定写入容量的增长是应用程序的问题而不是运行在MongoDB中的某些进程的问题。 MongoDB 监控工具MongoDB包含了各种监控工具，让你能够积极地管理系统的运行和性能。 MongoDB管理服务 (MMS) MongoDB管理服务（MMS）提供了云监控和备份服务，帮助用户优化集群、解决性能问题、减轻运维风险。MMS备份服务将在以后的文章中讨论。 MMS监控支持图表、自定义仪表盘和自定义警告。MMS仅需要最低限度的安装和配置。用户在所有的MongoDB实例上安装一个本地代理，该代理会跟踪与数据库使用情况相关的数百个关键的健康指标，包括：
（单击放大图片）
这些指标会被安全地报告给MMS服务，告诉它它们是在哪里处理、聚合、通知的，并在浏览器中可视化显示。用户能够容易地根据各种性能指标了解他们集群的健康状况。 硬件监控Munin node是一个开源软件程序，它可以监控硬件并报告磁盘和RAM的使用情况这样的指标。MMS能够收集Munin node产生的这些数据，并在MMS仪表盘中将这些数据和其他数据一起展现给用户。因为每一个应用程序和部署都是唯一的，所以用户应该为磁盘利用率的峰值、网络活动的主要变化和平均查询长度/响应时间的增长创建警报。 数据库分析工具MongoDB提供了一个性能分析工具，该工具能够记录数据库操作相关的细粒度信息。分析工具可以记录所有事件的信息，也能够只记录那些持续时间超出了配置阈值的事件的信息。分析数据存储在一个固定集合中，用户能够很容易地从中搜索相关的事件——查询这个集合可能比尝试着去解析日志文件更加容易。 其他的监控工具有各种各样的监控工具让你能够从其他的方面深入理解MongoDB系统。
如果想要获取更多与监控工具和监控内容相关的信息，可以查看MongoDB文档中的监控数据库系统页面。 配置MongoDB用户应该将配置选项存储到MongoDB的配置文件中。sysadmins能够通过这种方式在整个集群之间实现一致性的配置。配置文件支持MongoDB命令行所支持的所有选项。安装和升级应该通过流行的工具（例如Chef和Puppet）自动完成，同时MongoDB社区还提供并维护了这些工具的示例脚本。 一个基础的MongoDB配置文件类似于下面的内容：
你能够通过文档了解到与MongoDB配置选项相关的更多内容。在MongoDB文档产品说明页面上还维护着针对操作系统、文件系统、存储设备和其他系统相关主题特定配置的最新建议。 结论在本文中我们介绍了哪些用于部署关系型数据库的概念、操作和流程可以被直接地应用到MongoDB上，同时还介绍了硬件选择和部署及监控的最佳实践。另外，有关于所有这些主题的详细讨论可以从MongoDB操作指南（一个.pdf文件）中获取。 关于作者
查看英文原文：Preparing for Your First MongoDB Deployment: Capacity Planning and Monitoring (责任编辑：IT) |
