MongoDB的容量规划及硬件配置

mongo是基于内存的数据库，应尽量将工作集中的数据全部加载到内存中，即内存应大于工作集

本文译自Chad Tindel的英文博客： http://www.mongodb.com/blog/post/capacity-planning-and-hardware-provisioning-mongodb-ten-minutes 。

大部分MongoDB部署都运行于多台服务器的集群中，相对于传统数据库，这增加了容量规划及配置方面的复杂性。系统架构师 Chad Tindel 在MongoDB 世界大会上的硬件配置演讲 中为实施团队提供了规划MongoDB部署大小的最佳实践。

这里有两个与MongoDB架构相关的重要概念能够帮助理解该演讲：

• 分片。 分片即MongoDB在服务器之间划分数据的一项技术。MongoDB能够自动在分片之间平衡数据，并且能够在不需要数据库离线的情况下增加和删除分片。
• 复制。 为了保证高可用性，MongoDB维护了许多数据的冗余备份。复制被嵌入于MongoDB，并且在不需要专业网络的情况下就可以在广域网内工作。

Chad在演讲开始的时候提到了一些需要记住的重要建议，然后提到了一些用户案例：

• 预先列出你的性能需求。 确定你需要存储的数据量。通过分析查询来估计你一次需要读取的数据量，从而确定工作集的大小。计算生产环境中你希望在每秒时间内发送的请求数目，设置好要求的正常运行时间百分比，确定你可以忍受的延迟时间。
• 计划一个PoC概念验证测试。

  MongoDB的可扩展性允许你在10%-20%的硬件上使用10%-20%的数据运行应用。通过使用这个方法，你可以进行模式、索引设计并且了解查询模式，然后重新定义你估计的工作集大小。在一台机器上检测性能，然后在必要的情况下增加复制和分片。将这种配置作为一个沙盒，用于测试该应用的连续修订版本。

  你可以通过在MongoDB中执行下面的命令来估计您的工作集大小

  db.runCommand( { serverStatus: 1, workingSet: 1 } )

• 使用真实的工作负载进行测试。 向上拓展概念验证测试，但是直到使用真实世界的数据以及性能要求进行大量测试之后才开始部署。
• 基于新的需求不断监测和调整。 用户数量的增加经常会带来更多查询以及一个更大的工作集，新索引也会促使一个更大的工作集。应用可能会随着时间的变化而改变它的读写比例。像MongoDB管理服务（MMS）以及mongoperf之类的工具帮助你监测系统性能参数的改变。需求改变的同时，你可以调整你的硬件配置。请注意：通过使用MongoDB，你可以不必关闭数据库而增加和删除分片或复制集。

Chad接着在演讲中展示了两个真实的用户案例。

案例 #1 ：某西班牙银行

该银行希望存储6个月的日志。每个月的数据需要3TB的空间。那么6个月的数据需要使用6 x 3 = 18 TB的空间。他们知道他们希望分析上个月的日志，因此工作集的大小被设为：1个月的数据（3TB）加上索引（1TB），即一个4TB的工作集。

在概念验证环境中，他们选择使用约10%的数据（2TB）。生产需求需要一个4TB大小的工作集，4TB/18TB数据再乘上我们2TB的概念验证数据，从而得到444GB的概念验证工作集大小。用户最多只能提供每台128GB容量的服务器，因此在概念验证环境中，他们选择采用4个分片，每个分片有128G存储。4 x 128GB = 512GB能够满足444GB的要求。每个分片上用于读取可用性及冗余的3个复制集成员为我们提供了4 x 3 = 12台物理机器。两台应用服务器运行mongos，虚拟机上的三台配置服务器进行概念验证配置。

为满足在128GB的服务器中存放4TB部署工作集及18TB数据，他们选择分割成36个分片，每个分片有128GB的内存（RAM）及512GB的可用存储。总的看来：一共有36 * 128GB = 4.6TB内存（RAM）， 36* 512GB =18TB的可用存储。和上面的概念验证系统一样，他们用2台应用服务器上运行mongos，在虚拟机上运行3台配置服务器。同上，每个分片有一个三节点的复制集，那么36 分片* 3 复制集节点= 108 台物理机。

注意：MongoDB允许概念验证及生产配置使用相同的、配置有128GB内存（RAM）及512GB可用存储的标准硬件结构单元。这样就允许用户在将真实的生产节点添加进生产集群之前在概念验证集群中进行测试。

案例 #2 ：大型在线零售商

该零售商希望将他们的产品目录从SQL Server中迁移到MongoDB中。MongoDB在存储目录信息方面有很大的优势。不像SQL数据库，MongoDB的动态模式可以为每个产品存储不同的属性，并且不需要在那些不存储相同信息的其它产品信息中强制放置一个空白的字段占位符。

该零售商希望分别为东、西海岸的顾客建立自己的数据中心，因此他们选择运行一个主动/主动配置。他们只在晚上最空闲的时间批量写入新的或者被修改的目录。在使用的峰值只执行读取操作。

他们有4,000,000产品库存单位，每一个都有平均30KB大小的JSON文档。他们需要为一个特定产品通过_id或者像“桌子”或“硬件驱动”之类的类别提供搜索查询服务。大多数类别请求将会检索平均大概72个文档。一个追踪该类别树所有链接的搜索引擎爬虫将会检索200个文档。

计算结果显示：平均每个产品都会出现在2个类别中。该零售商最初想根据类别进行分片，在多个类别中同时出现的产品进行重复存储。平均属于两个类别的4,000,000产品乘上30KB每库存单位为：8,000,000 乘上 30KB 等于240GB加上30GB索引，一共270GB数据。

MongoDB咨询工程师建议该零售商使用不分片的复制集，因为该应用需要很高的读取性能，但是只需要在空闲时间进行单独的批量写操作。整个270GB的工作集适合存放于该零售商希望使用的大型思科UCS服务器的384GB可用内存中，不需要在分片之间分割内存工作集，因此简化了他们的部署架构。

MongoDB工程师推荐 使用一个4节点的复制集横跨2个数据中心，在一个第三方位置建立一个投票机作为从节点以防主服务器出现故障。这样就会允许每个数据中心的任一服务器都可以关机维护或者出现故障的情况下，其它服务器还能够正常运行。Mongos的“最近读取”查询调节器将会基于最近延迟选择最近的服务器。

然而，令人吃惊的是，该零售商决定在他们公司的VMWare云平台上而不是他们的大型思科服务器上部署该系统。他们的IT部门不会提供任何一个内存（RAM）超过64GB的VMWare节点。为了解决64GB的限制，他们部署了3个分片，每个分片上部署4个节点（两个东海岸、两个西海岸加上投票机）：64GB x 3 = 192GB。尽管这样不能够维持270GB的工作集，他们仍然决定承担插拔所带来的任何后果。他们保留了增加第四个分片以维持内存中更多工作集的可能性。

从这些案例学到的硬件配置教程

1. 对于读密集型应用，规划好服务器大小以保证在内存中能支撑整个工作集并且进行复制以得到更高的可用性。
2. 如果你服务器的内存（RAM）不能够保证在内存中容纳工作集，进行分片以从多个复本集群中整合内存（RAM）。
3. 使用与部署相同的服务器硬件创建一个概念验证系统。通过这个方法，你可以在你的概念验证系统中配置和测试一个服务器。接着，你可以根据需要，在扩展一个复制集或者增加一个分片进行拓展时，直接将其放入部署系统中。