MongoDB Auto-Sharding 入门介绍

最新推荐文章于 2021-01-19 17:01:13 发布

SAN_YUN

最新推荐文章于 2021-01-19 17:01:13 发布

阅读量247

点赞数

分类专栏： mongoDB 文章标签：数据库 shell

本文链接：https://blog.csdn.net/SAN_YUN/article/details/84321485

版权

mongoDB 专栏收录该内容

29 篇文章 0 订阅

订阅专栏

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上。

Sharding架构图:

接下来我就为大家介绍一下如何搭建一个简单的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使用过程中的经验心得。