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 < shard key < 100时为一个chunk，该chunk保存在shard1上。而Config Servers就是用来存储：所有shard节点的配置信息；每个chunk的shard key范围；chunk在各shard的分布；该集群中所有DB和collection的sharding配置。
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创建数据目录：
sudo mkdir -p /data0/mongo/shard1 /data0/mongo/shard2 /data0/mongo/config
然后，我们依次启动两个mongod进程作为Shard，一个mongod进程作为Config Server，一个mongos进程作为Routing Process：
sudo mongod --port 27017 --fork --logpath /var/log/mongo_shard1.log --dbpath /data0/mongo/shard1 --shardsvr sudo mongod --port 27018 --fork --logpath /var/log/mongo_shard2.log --dbpath /data0/mongo/shard2 --shardsvr sudo mongod --port 27217 --fork --logpath /var/log/mongo_config.log --dbpath /data0/mongo/config --configsvr sudo mongos --port 27417 --fork --logpath /var/log/mongos.log --configdb 127.0.0.1:27217 --chunkSize 1
mongos启动参数中，chunkSize这一项是用来指定chunk的大小的，单位是MB，默认大小为200MB，为了方便测试Sharding效果，我们把chunkSize指定为 1MB。
接下来，我们使用mongo shell登录到mongos，添加Shard节点：
mongo --port 27417 MongoDB shell version: 1.6.5 connecting to: 127.0.0.1:27417/test > use admin; switched to db admin > db.runCommand({addshard:"127.0.0.1:27017"}) { "shardAdded" : "shard0000", "ok" : 1 } > db.runCommand({addshard:"127.0.0.1:27018"}) { "shardAdded" : "shard0001", "ok" : 1 }
下面我们为DataBase “foo”启用Sharding，并将其中的 Collection “col” 的 shard key设置为“{_id: 1}”，用来测试Sharding功能：
> db.runCommand({enablesharding:'foo'}); { "ok" : 1 } > db.runCommand({shardcollection:"foo.col", key:{_id:1}}); { "collectionsharded" : "foo.col", "ok" : 1 }
为了测试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使用过程中的经验心得。