MongoDB数据库的Auto-Sharding使用教程

MongoDB是10gen团队开发的一款面向文档的NoSQL数据库。最近一年多以来，MongoDB被越来越多的大型网站应用到生产环境中，比较著名的有Foursquare, bit.ly, SourceForge, Boxed等。MongoDB提供了Auto-Sharding功能，使用者通过简单的配置就可以很方便地构建一个分布式MongoDB集群。

MongoDB的Auto-Sharding能够做到：

当各Sharding间负载和数据分布不平衡时，自动rebalancing

简单方便的添加和删除节点

自动故障转移(auto failover)

可扩展至上千台节点

一个MongoDB Sharding由三部分组成：

1. Shards

Shard即存储实际数据的分片，每个Shard可以是一个mongod实例，也可以是一组mongod实例构成的Replica Set。为了实现每个Shard内部的auto-failover，MongoDB官方建议每个Shard为一组Replica Set。

2. Config Servers

为了将一个collection拆分为多个chunk，存储在多个shard中，需要为该collection指定一个shard key. 例如{name: 1}, {_id: 1}, {lastname:1, firstname:1}等。shard key决定了该条记录属于哪个chunk，例如当1

3. Routing Process

MongoDB的二进制包中有一个mongos程序，它是用来做为MongoDB集群的Routing Process的。它相当于一个透明代理，接收来自客户端的查询或更新请求，然后询问Config Servers需要到哪个Shard上查询或保存记录，再连接相应的Shard进行操作，最后将结果返回给客户端。客户端只需要将原本发给mongod的查询或更新请求原封不动地发给Routing Process，而不必关心所操作的记录存储在哪个Shard上。

接下来我就为大家介绍一下如何搭建一个简单的MongoDB集群用来测试MongoDB的Auto-Sharding功能。

这个MongoDB集群将包含两个Shards，一个Config Server和一个Routing Process。我们将使用MongoDB 1.6.5来做这个测试，下载地址为： http://www.mongodb.org/downloads

首先，我们为两个Shards和一个Config Server创建数据目录：

然后，我们依次启动两个mongod进程作为Shard，一个mongod进程作为Config Server，一个mongos进程作为Routing Process：

mongos启动参数中，chunkSize这一项是用来指定chunk的大小的，单位是MB，默认大小为200MB，为了方便测试Sharding效果，我们把chunkSize指定为 1MB。

接下来，我们使用mongo shell登录到mongos，添加Shard节点：

下面我们为DataBase “foo”启用Sharding，并将其中的 Collection “col” 的 shard key设置为“{_id: 1}”，用来测试Sharding功能：

为了测试Sharding的balance效果，我陆续插入了大约200M的数据，插入过程中使用db.stats() 查询数据分布情况。发现在数据量较小，30M以下时，所有trunk都存储在了shard0000上，但继续插入后，数据开始平均分布，并且mongos会对多个shard之间的数据进行rebalance 。在插入数据达到200M，刚插入结束时，shard0000上大约有135M数据，而shard0001上大约有65M数据，但过一段时间之后，shard0000上的数据量减少到了115M，shard0001上的数据量达到了85M。

MongoDB的Auto-Sharding功能自1.6版本开始才production-ready，至今不过半年多的时间，大多数公司仍在观望中，不敢将其用到生产环境，因此目前网上并没有太多相关资料可以参考。今后我会陆续为大家分享更多MongoDB使用过程中的经验心得。