MongoDB Auto-Sharding入门介绍。

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

MongoDBAuto-Sharding能够做到:

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

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

  • 自动故障转移(auto failover)

  • 可扩展至上千台节点

 

一个MongoDB Sharding由三部分组成:

1. Shards

Shard即存储实际数据的分片,每个Shard可以是一个mongod实例,也可以是一组mongod实例构成的Replica Set。为了实现每个Shard内部的auto-failoverMongoDB官方建议每个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节点的配置信息;每个chunkshard key范围;chunk在各shard的分布;该集群中所有DBcollectionsharding配置。

3. Routing Process

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

 

接下来我就为大家介绍一下如何搭建一个简单的MongoDB集群用来测试MongoDBAuto-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 }

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

 

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

你可能感兴趣的:(mongodb,linux,职场,休闲,onlyzq)