logo
搜索
我的图书馆

发文章

发文工具

其他工具

留言交流
搜索
分享

MongoDB分片实战：集群搭建

 昵称21365845 2015-05-25

环境准备

Linux环境

主机 OS 备注
192.168.32.13　 CentOS6.3 64位　 普通PC
192.168.71.43　 CentOS6.2 64位　 服务器，NUMA CPU架构

MongoDB版本：mongodb-linux-x86_64-2.4.1，下载地址：www./downloads.

MongoDB安装：分别在两台机器上安装好mongodb 2.4.1，安装路径都为/url/local/mongodb-2.4.1/

cd /usr/local/src/
wget http://fastdl./linux/mongodb-linux-x86_64-2.4.1.tgz
tar -zxvf mongodb-linux-x86_64-2.4.1.tgz
cp -r mongodb-linux-x86_64-2.4.1 /usr/local/mongodb-2.4.1
cd /usr/local/mongodb-2.4.1/bin/
ll

可以看到mongodb安装成功有如下模块：

 

mongodb启动和关闭等在后面集群搭建中有详细说明，在此不再赘述。

Sharding集群搭建

Mongodb一共有三种集群搭建的方式：Replica Set（副本集）、Sharding（切片）和Master-Slaver（主从）。下面要搭建的是Sharding，Sharding集群也是三种集群中最复杂的。

配置服务器启动(192.168.32.13:10000)：

1.    ./bin/mongod --fork --dbpath data/config/ --logpath log/config.log –port 10000

路由服务器启动(192.168.32.13:20000)：

1.    ./bin/mongos --port 20000 --configdb 192.168.32.13:10000 --logpath log/mongos.log  --fork

注意1：配置--conigdb的时候ip地址不能填localhost或127.0.0.1否则添加分片时会返回如下错误信息：

1.    {
2.            "ok" : 0,
3.            "errmsg" : "can't use localhost as a shard since all shards need to communicate. either use all shards and configdbs in localhost or all in actual IPs  host: 192.168.71.43:27017 isLocalHost:0"
4.    }

启动分片1(192.168.32.13:27019)：

1.    ./bin/mongod --dbpath data/shard3/ --logpath log/shard3.log  --fork --port 27019

启动分片2(192.168.32.13:27020)：

1.    ./bin/mongod --dbpath data/shard3/ --logpath log/shard3.log  --fork --port 27020

启动分片3(192.168.71.43:27017)：

1.    numactl --interleave=all ./bin/mongod --dbpath data/shard1/ --logpath log/shard1.log  --fork --port 27017

启动分片4(192.168.71.43:27018)：

1.    numactl --interleave=all ./bin/mongod --dbpath data/shard2/ --logpath log/shard2.log  --fork --port 27018

说明：关于这里为什么加numactl --interleave=all，后面有详细说明。

Note:在生产环境可以将启动的配置信息写入文件，然后启动的时候指定配置文件，这样便于管理：

复制代码
1.    vi conf/config.conf
2.    bpath=data/config/
3.    logpath=log/config.log
4.    port=10000
5.    fork=true

6.    ./bin/mongod -f conf/config.conf
复制代码

添加分片1(192.168.32.13:27019)：

1.    ./bin/mongo --port 20000
2.    mongos> use admin
3.    switched to db admin
4.    mongos> db.runCommand({addshard:"192.168.32.13:27019",allowLocal:true })

注意2：同样这里的192.168.32.13不能用localhost或127.0.0.1代替，并且当路由进程和分片在同一台机器上要指定allowLocal为true,因为MongoDB尽量避免错误的配置，将集群配置在本地，所以这个配置指明当前仅仅是用于开发。

添加分片3(192.168.71.43:27017)：

1.    mongos> db.runCommand({addshard:"192.168.71.43:27017" })

类似的添加分片2,4。

分片添加成功返回类似下面的信息(当前mongodb版本为2.4.1)：

1.    { "shardAdded" : "shard0000", "ok" : 1 }

删除分片：如果要删除分片的话可以removeshard命令：

复制代码
1.    mongos> use admin
2.    switched to db admin
3.    mongos> db.runCommand({"removeshard":"192.168.32.13:27020"})
4.    {
5.            "msg" : "draining started successfully",
6.            "state" : "started",
7.            "shard" : "shard0001",
8.            "note" : "you need to drop or movePrimary these databases",
9.            "dbsToMove" : [
10.                    "test3"
11.            ],
12.            "ok" : 1
13.    }
复制代码

移除分片需要一个过程，MongoDB会把移除的片上的数据（块）挪到其他片上，移动中会显示进度：

复制代码
1.    mongos> db.runCommand({"removeshard":"192.168.32.13:27020"})
2.    {
3.            "msg" : "draining ongoing",
4.            "state" : "ongoing",
5.            "remaining" : {
6.                    "chunks" : NumberLong(0),
7.                    "dbs" : NumberLong(1)
8.            },
9.            "note" : "you need to drop or movePrimary these databases",
10.            "dbsToMove" : [
11.                    "test3"
12.            ],
13.            "ok" : 1
14.    }
复制代码

注意：如果删除的片是数据库的大本营(基片)，必须手动移动或删除数据库，用moveprimary命令，上面的示例中就提示192.168.32.13:27020是test3库的大本营(primary)，这个信息可以通过查看config.databases看到：

1.    mongos> use config
2.    switched to db config
3.    mongos> db.databases.find()
4.    { "_id" : "test3", "partitioned" : false, "primary" : "shard0001" }

这里shard0001就是192.168.32.13:27020，下面通过moveprimary命令移除test3:

1.    mongos> use admin 
2.    switched to db admin
3.    mongos> db.runCommand({"moveprimary":"test3","to":"192.168.32.13:27019"})
4.    { "primary " : "shard0000:192.168.32.13:27019", "ok" : 1 }

这时再查看config.databases会发现test3的大本营变成了shard0000(192.168.32.13:27019)

这时再执行removeshard命令则能成功移除分片了：

复制代码
1.    mongos> db.runCommand({"removeshard":"192.168.32.13:27020"})
2.    {
3.            "msg" : "removeshard completed successfully",
4.            "state" : "completed",
5.            "shard" : "shard0001",
6.            "ok" : 1
7.    }
复制代码

管理分片

进入mongos进程config库可以看到目前分片的情况：

复制代码
1.    ./bin/mongo –port 20000
2.    use config
3.    db.shards.find()
1.    mongos> use config
2.    switched to db config
3.    mongos> db.shards.find()
4.    { "_id" : "shard0000", "host" : "192.168.32.13:27019" }
5.    { "_id" : "shard0001", "host" : "192.168.71.43:27017" }
6.    { "_id" : "shard0002", "host" : "192.168.71.43:27018" }
复制代码

注意3：如果配置过程中发生过上面注意1中出现的情况，即配置configdb的时候用了localhost或127.0.0.1,则运行db.shards.find()可能会出现如下错误：

1.    mongos> db.shards.find()
2.    error: {
3.            "$err" : "could not initialize sharding on connection 192.168.32.13:10000 :: caused by :: mongos specified a different config database string : stored : localhost:10000 vs given : 192.168.32.13:10000",
4.            "code" : 15907
5.    }

解决方法是重新启动config进程。

查看分片后的数据库：

复制代码
1.    ./bin/mongo –port 20000
2.    use test
3.    db.test.user.insert({“test”: “test”})
4.    ……
5.    use config
6.    db.databases.find()
7.    { "_id" : "admin", "partitioned" : false, "primary" : "config" }
8.    { "_id" : "test", "partitioned" : false, "primary" : "shard0000" }
9.    { "_id" : "test2", "partitioned" : false, "primary" : "shard0000" }
10.    { "_id" : "test3", "partitioned" : false, "primary" : "shard0001" }
复制代码

分片逻辑图

上节搭建的分片集群从逻辑上看如下图所示：

 

片：可以普通的mongod进程，也可以是副本集。但是即使一片内有多台服务器，也只能有一个主服务器，其他的服务器保存相同的数据。

mongos路由进程:它路由所有请求，然后将结果聚合。它不保存存储数据或配置信息。

配置服务器：存储集群的配置信息。

整个分布式的集群通过mongos对客户端提供了一个透明统一的接口，客户端不需要关系具体的分片细节，所有分片的动作都是自动执行的，那是如何做到透明和自动的。

切分数据

上节中建立好集群后，默认的是不会将存储的每条数据进行分片处理，需要在数据库和集合的粒度上都开启分片功能。开启test库的分片功能：

1.    ./bin/mongo –port 20000
2.    mongos> use admin 
3.    switched to db admin
4.    mongos> db.runCommand({"enablesharding":"test"})
5.    { "ok" : 1 }

开启user集合分片功能：

1.    mongos> db.runCommand({"shardcollection":"test.user","key":{"_id":1}})
2.    { "collectionsharded" : "test.user", "ok" : 1 }

注意：需要切换到admin库执行命令。

片键：上面的key就是所谓的片键（shard key）。MongoDB不允许插入没有片键的文档。但是允许不同文档的片键类型不一样，MongoDB内部对不同类型有一个排序：

片键的选择至关重要，后面会进行详细的说明。

这时再切换到config库如下查看:

复制代码
1.    mongos> use config
2.    mongos> db.databases.find()
3.    { "_id" : "admin", "partitioned" : false, "primary" : "config" }
4.    { "_id" : "OSSP10", "partitioned" : false, "primary" : "shard0000" }
5.    { "_id" : "test", "partitioned" : true, "primary" : "shard0000" }
6.    { "_id" : "test2", "partitioned" : false, "primary" : "shard0000" }
7.    { "_id" : "test3", "partitioned" : false, "primary" : "shard0001" }
8.    mongos> db.chunks.find()
9.    { "_id" : "test.user-_id_MinKey", "lastmod" : { "t" : 1, "i" : 0 }, "lastmodEpoch" : ObjectId("515a3797d249863e35f0e3fe"), "ns" : "test.user", "min" : { "_id" : { "$minKey" : 1 } }, "max" : { "_id" : { "$maxKey" : 1 } }, "shard" : "shard0000" }
复制代码

Chunks：理解MongoDB分片机制的关键是理解Chunks。mongodb不是一个分片上存储一个区间，而是每个分片包含多个区间，这每个区间就是一个块。

1.    mongos> use config
2.    mongos> db.settings.find()
3.    { "_id" : "chunksize", "value" : 64 }
4.    ……

平衡：如果存在多个可用的分片，只要块的数量足够多，MongoDB就会把数据迁移到其他分片上，这个迁移的过程叫做平衡。Chunks默认的大小是64M200M，查看config.settings可以看到这个值：

只有当一个块的大小超过了64M200M，MongoDB才会对块进行分割（但根据我的实践2.4版本块分割的算法好像并不是等到超过chunkSize大小就分割，也不是一分为二,有待继续学习），并当最大分片上的块数量超过另一个最少分片上块数量达到一定阈值会发生所谓的chunk migration来实现各个分片的平衡 (如果启动了balancer进程的话)。这个阈值随着块的数量不同而不同：

 

这带来一个问题是我们测开发测试的时候，往往希望通过观察数据在迁移来证明分片是否成功，但64M200M显然过大，解决方法是我们可以在启动mongos的时候用—chunkSize来制定块的大小，单位是MB。

1.    ./bin/mongos --port 20000 --configdb 192.168.32.13:10000 --logpath log/mongos.log  --fork --chunkSize 1

我指定1MB的块大小重新启动了一下mongos进程。

或者向下面这要修改chunkSize大小：

1.    mongos> use config
2.    mongos> db.settings.save( { _id:"chunksize", value: 1 } )

 2.4版本之前MongoDB基于范围进行分片的（2.2.4会介绍基于哈希的分片），对一个集合分片时，一开始只会创建一个块，这个块的区间是（-∞，+∞），-∞表示MongoDB中的最小值，也就是上面db.chunks.find()我们看到的$minKey，+∞表示最大值即$maxKey。Chunck的分割是自动执行的，类似于细胞分裂，从区间的中间分割成两个。

分片测试

 现在对上面我们搭建的MongoDB分片集群做一个简单的测试。目前我们的集群情况如下（为了方面展示我采用了可视化的工具MongoVUE）：

像上面提到那样为了尽快能观察到测试的效果，我么启动mongos时指定的chunkSize为1MB。

我们对OSSP10库和bizuser集合以Uid字段进行分片：

1.    mongos> use admin
2.    switched to db admin
3.    mongos> db.runCommand({"enablesharding":"OSSP10"})
4.    { "ok" : 1 }
5.    mongos> db.runCommand({"shardcollection":"OSSP10.bizuser","key":{"Uid":1}})
6.    { "collectionsharded" : "OSSP10.bizuser", "ok" : 1 }

在插入数据之前查看一下config.chunks,通过查看这个集合我们可以了解数据是怎么切分到集群的：

1.    mongos> db.chunks.find()
2.    { "_id" : "OSSP10.bizuser-Uid_MinKey", "lastmod" : { "t" : 1, "i" : 0 }, "lastmodEpoch" : ObjectId("515a8f1dc1de43249d8ce83e"), "ns" : "OSSP10.bizuser", "min" : { "Uid" : { "$minKey" : 1 } }, "max" : { "Uid" : { "$maxKey" : 1 } }, "shard" : "shard0000" }

开始只有一个块，区间（-∞，+∞）在shard0000(192.168.32.13:27019)上，下面我们循环的插入100000条数据：

1.    mongos> use OSSP10
2.    switched to db OSSP10
3.    mongos> for(i=0;i<100000;i++){ db.bizuser.insert({"Uid":i,"Name":"zhanjindong","Age":13,"Date":new Date()}); }

完成后我们在观察一下config.chunks的情况：

复制代码
1.    mongos> db.chunks.find()
2.    { "_id" : "OSSP10.bizuser-Uid_MinKey", "lastmod" : { "t" : 3, "i" : 0 }, "lastmodEpoch" : ObjectId("515a8f1dc1de43249d8ce83e"), "ns" : "OSSP10.bizuser", "min" : { "Uid" : { "$minKey" : 1 } }, "max" : { "Uid" : 0 }, "shard" : "shard0002" }
3.    { "_id" : "OSSP10.bizuser-Uid_0.0", "lastmod" : { "t" : 3, "i" : 1 }, "lastmodEpoch" : ObjectId("515a8f1dc1de43249d8ce83e"), "ns" : "OSSP10.bizuser", "min" : { "Uid" : 0 }, "max" : { "Uid" : 6747 }, "shard" : "shard0000" }
4.    { "_id" : "OSSP10.bizuser-Uid_6747.0", "lastmod" : { "t" : 2, "i" : 0 }, "lastmodEpoch" : ObjectId("515a8f1dc1de43249d8ce83e"), "ns" : "OSSP10.bizuser", "min" : { "Uid" : 6747 }, "max" : { "Uid" : { "$maxKey" : 1 } }, "shard" : "shard0001" }
复制代码

我们可以看见刚开始的块分裂成了三块分别是（-∞,0）在shard0002上,[0,6747）在shard0000上和[6747,+ ∞）在shard0001上。

说明：这里需要说明的是MongoDB中的区间是左闭右开的。这样说上面第一个块不包含任何数据，至于为什么还不清楚，有待继续调研。

我们持续上面的插入操作（uid从0到100000）我们发现块也在不停的分裂：

复制代码
1.    mongos> db.chunks.find()
2.    { "_id" : "OSSP10.bizuser-Uid_MinKey", "lastmod" : { "t" : 3, "i" : 0 }, "lastmodEpoch" : ObjectId("515a8f1dc1de43249d8ce83e"), "ns" : "OSSP10.bizuser", "min" : { "Uid" : { "$minKey" : 1 } }, "max" : { "Uid" : 0 }, "shard" : "shard0002" }
3.    { "_id" : "OSSP10.bizuser-Uid_0.0", "lastmod" : { "t" : 3, "i" : 1 }, "lastmodEpoch" : ObjectId("515a8f1dc1de43249d8ce83e"), "ns" : "OSSP10.bizuser", "min" : { "Uid" : 0 }, "max" : { "Uid" : 6747 }, "shard" : "shard0000" }
4.    { "_id" : "OSSP10.bizuser-Uid_6747.0", "lastmod" : { "t" : 3, "i" : 4 }, "lastmodEpoch" : ObjectId("515a8f1dc1de43249d8ce83e"), "ns" : "OSSP10.bizuser", "min" : { "Uid" : 6747 }, "max" : { "Uid" : 45762 }, "shard" : "shard0001" }
5.    { "_id" : "OSSP10.bizuser-Uid_99999.0", "lastmod" : { "t" : 3, "i" : 3 }, "lastmodEpoch" : ObjectId("515a8f1dc1de43249d8ce83e"), "ns" : "OSSP10.bizuser", "min" : { "Uid" : 99999 }, "max" : { "Uid" : { "$maxKey" : 1 } }, "shard" : "shard0001" }
6.    { "_id" : "OSSP10.bizuser-Uid_45762.0", "lastmod" : { "t" : 3, "i" : 5 }, "lastmodEpoch" : ObjectId("515a8f1dc1de43249d8ce83e"), "ns" : "OSSP10.bizuser", "min" : { "Uid" : 45762 }, "max" : { "Uid" : 99999 }, "shard" : "shard0001" }
复制代码

分片的规则正是上面提到的块的自动分裂和平衡，可以发现不同的块是分布在不同的分片上。

注意：这里使用Uid作为片键通常是有问题的，2.3对递增片键有详细说明。

Note:通过sh.status()可以很直观的查看当前整个集群的分片情况，类似如下：

对已有数据进行分片

面的演示都是从零开始构建分片集群，但是实际中架构是一个演进的过程，一开始都不会进行分片，只有当数据量增长到一定程序才会考虑分片，那么对已有的海量数据如何处理。我们在上节的基础上继续探索。《深入学习MongoDB》中有如下描述：

我们现在来尝试下（也许我使用的最新版本会有所有变化），先在192.168.71.43:27179上再启一个mongod进程：

1.    numactl --interleave=all ./bin/mongod --dbpath data/shard3/ --logpath log/shard3.log  --fork --port 27019

现在我们像这个mongod进程中的OSSP10库的bizuser集合中插入一些数据：

1.    for(i=0;i<10;i++){ db.bizuser.insert({"Uid":i,"Name":"zhanjindong2","Age":13,"Date":new Date()}); }

我们这个时候尝试将这个mongod加入到之前的集群中去：

1.    mongos> db.runCommand({addshard:"192.168.71.43:27019" })
2.    {
3.            "ok" : 0,
4.            "errmsg" : "can't add shard 192.168.71.43:27019 because a local database 'OSSP10' exists in another shard0000:192.168.32.13:27019"
5.    }

果然最新版本依旧不行。我们删除OSSP10库，新建个OSSP20库再添加分片则可以成功。

1.    { "shardAdded" : "shard0003", "ok" : 1 }

那么看来我们只能在之前已有的数据的mongod进程基础上搭建分片集群，那么这个时候添加切片，MongoDB对之前的数据又是如何处理的呢？我们现在集群中移除上面添加的切片192.168.71.43:27019，然后在删除集群中的OSSP10库。

这次我们尽量模拟生产环境进行测试，重新启动mongos并不指定chunksize，使用默认的最优的大小（64M200M）。然后在192.168.71.43:27019中新建OSSP10库并向集合bizuser中插入100W条数据：

1.    for(i=0;i<1000000;i++){ db.bizuser.insert({"Uid":i,"Name":"zhanjindong2","Age":13,"Date":new Date()}); }

然后将此节点添加到集群中，并仍然使用递增的Uid作为片键对OSSP10.bizuser进行分片：

1.    mongos> use admin
2.    switched to db admin
3.    mongos> db.runCommand({"enablesharding":"OSSP10"})
4.    { "ok" : 1 }
5.    mongos> db.runCommand({"shardcollection":"OSSP10.bizuser","key":{"Uid":1}})
6.    { "collectionsharded" : "OSSP10.bizuser", "ok" : 1 }

观察一下config.chunks可以看见对新添加的切片数据进行切分并进行了平衡（每个分片上一个块），基本是对Uid（0~1000000）进行了四等分，当然没那精确：

复制代码
1.    mongos> use config
2.    switched to db config
3.    mongos> db.chunks.find()
4.    { "_id" : "OSSP10.bizuser-Uid_MinKey", "lastmod" : { "t" : 2, "i" : 0 }, "lastmodEpoch" : ObjectId("515b8f3754fde3fbab130f92"), "ns" : "OSSP10.bizuser", "min" : { "Uid" : { "$minKey" : 1 } }, "max" : { "Uid" : 0 }, "shard" : "shard0000" }
5.    { "_id" : "OSSP10.bizuser-Uid_381300.0", "lastmod" : { "t" : 4, "i" : 1 }, "lastmodEpoch" : ObjectId("515b8f3754fde3fbab130f92"), "ns" : "OSSP10.bizuser", "min" : { "Uid" : 381300 }, "max" : { "Uid" : 762601 }, "shard" : "shard0003" }
6.    { "_id" : "OSSP10.bizuser-Uid_762601.0", "lastmod" : { "t" : 1, "i" : 2 }, "lastmodEpoch" : ObjectId("515b8f3754fde3fbab130f92"), "ns" : "OSSP10.bizuser", "min" : { "Uid" : 762601 }, "max" : { "Uid" : { "$maxKey" : 1 } }, "shard" : "shard0003" }
7.    { "_id" : "OSSP10.bizuser-Uid_0.0", "lastmod" : { "t" : 3, "i" : 0 }, "lastmodEpoch" : ObjectId("515b8f3754fde3fbab130f92"), "ns" : "OSSP10.bizuser", "min" : { "Uid" : 0 }, "max" : { "Uid" : 250000 }, "shard" : "shard0001" }
8.    { "_id" : "OSSP10.bizuser-Uid_250000.0", "lastmod" : { "t" : 4, "i" : 0 }, "lastmodEpoch" : ObjectId("515b8f3754fde3fbab130f92"), "ns" : "OSSP10.bizuser", "min" : { "Uid" : 250000 }, "max" : { "Uid" : 381300 }, "shard" : "shard0002" }
复制代码

MongoDB这种自动分片和平衡的能力使得在迁移老数据的时候变得非常简单，但是如果数据特别大话则可能会非常的慢。

Hashed Sharding

MongoDB2.4以上的版本支持基于哈希的分片，我们在上面的基础上继续探索。

交代一下因为环境变动这部分示例操作不是在之前的那个集群上，但是系统环境都是一样，逻辑架构也一样，只是ip地址不一样（只搭建在一台虚拟机上）,后面环境有改动不再说明：

配置服务器：192.168.129.132:10000

路由服务器：192.168.129.132:20000

分片1:192.168.129.132:27017

分片2:192.168.129.132:27018

……其他分片端口依次递增。

我们重建之前的OSSP10库，我们仍然使用OSSP10.bizuser不过这次启动哈希分片，选择_id作为片键：

1.    mongos> use admin
2.    switched to db admin
3.    mongos> db.runCommand({"enablesharding":"OSSP10"})
4.    { "ok" : 1 }
5.    mongos> db.runCommand({"shardcollection":"OSSP10.bizuser","key":{"_id":"hashed"}})
6.    { "collectionsharded" : "OSSP10.bizuser", "ok" : 1 }

我们现在查看一下config.chunks

复制代码
1.    mongos> use config
2.    switched to db config
3.    mongos> db.chunks.find()
4.    { "_id" : "OSSP10.bizuser-_id_MinKey", "lastmod" : { "t" : 2, "i" : 2 }, "lastmodEpoch" : ObjectId("515e47ab56e0b3341b76f145"), "ns" : "OSSP10.bizuser", "min" : { "_id" : { "$minKey" : 1 } }, "max" : { "_id" : NumberLong("-4611686018427387902") }, "shard" : "shard0000" }
5.    { "_id" : "OSSP10.bizuser-_id_-4611686018427387902", "lastmod" : { "t" : 2, "i" : 3 }, "lastmodEpoch" : ObjectId("515e47ab56e0b3341b76f145"), "ns" : "OSSP10.bizuser", "min" : { "_id" : NumberLong("-4611686018427387902") }, "max" : { "_id" : NumberLong(0) }, "shard" : "shard0000" }
6.    { "_id" : "OSSP10.bizuser-_id_0", "lastmod" : { "t" : 2, "i" : 4 }, "lastmodEpoch" : ObjectId("515e47ab56e0b3341b76f145"), "ns" : "OSSP10.bizuser", "min" : { "_id" : NumberLong(0) }, "max" : { "_id" : NumberLong("4611686018427387902") }, "shard" : "shard0001" }
7.    { "_id" : "OSSP10.bizuser-_id_4611686018427387902", "lastmod" : { "t" : 2, "i" : 5 }, "lastmodEpoch" : ObjectId("515e47ab56e0b3341b76f145"), "ns" : "OSSP10.bizuser", "min" : { "_id" : NumberLong("4611686018427387902") }, "max" : { "_id" : { "$maxKey" : 1 } }, "shard" : "shard0001" }
复制代码

MongoDB的哈希分片使用了哈希索引:

哈希分片仍然是基于范围的，只是将提供的片键散列成一个非常大的长整型作为最终的片键。官方文中描述如下：

不像普通的基于范围的分片，哈希分片的片键只能使用一个字段。

 

选择哈希片键最大的好处就是保证数据在各个节点分布基本均匀，下面使用_id作为哈希片键做个简单的测试：

1.    mongos> db.runCommand({"enablesharding":"mydb"})
2.    db.runCommand({"shardcollection":"mydb.mycollection","key":{"_id":"hashed"}})
3.    mongos> use mydb
4.    mongos> for(i=0;i<333333;i++){ db.mycollection.insert({"Uid":i,"Name":"zhanjindong2","Age":13,"Date":new Date()}); }

 

通过MongoVUE观察三个切片上的数据量非常均匀：

上面是使用官方文档中推荐的Objectid作为片键，情况很理想。如果使用一个自增长的Uid作为片键呢：

1.    db.runCommand({"shardcollection":"mydb.mycollection","key":{"Uid":"hashed"}})
2.    for(i=0;i<333333;i++){ db.mycollection.insert({"Uid":i,"Name":"zhanjindong2","Age":13,"Date":new Date()}); }

故障恢复

先不考虑集群中每个分片是副本集复杂的情况，只考虑了每个分片只有一个mongod进程，这种配是只是不够健壮还是非常脆弱。我们在testdb.testcollection上启动分片，然后向其中插入一定量的数据（视你的chunkSize而定），通过观察config.chunks确保testdb.testcollection上的数据被分布在了不同的分片上。

复制代码
1.    mongos> db.runCommand({"enablesharding":"testdb"})
2.    mongos> db.runCommand({"shardcollection":"testdb.testcollection","key":{"Uid":1}})
3.    use testdb
4.    for(i=0;i<1000000;i++){ db.testcollection.insert({"Uid":i,"Name":"zhanjindong","Age":13,"Date":new Date()}); }
5.    mongos> use config
6.    switched to db config
7.    mongos> db.chunks.find()
8.    ……
9.    { "_id" : "testdb.testcollection-Uid_747137.0", "lastmod" : { "t" : 4, "i" : 1 }, "lastmodEpoch" : ObjectId("515fc5f0365c860f0bf8e0cb"), "ns" : "testdb.testcollection", "min" : { "Uid" : 747137 }, "max" : { "Uid" : 962850 }, "shard" : "shard0000" }
10.    ……
11.    { "_id" : "testdb.testcollection-Uid_0.0", "lastmod" : { "t" : 1, "i" : 3 }, "lastmodEpoch" : ObjectId("515fc5f0365c860f0bf8e0cb"), "ns" : "testdb.testcollection", "min" : { "Uid" : 0 }, "max" : { "Uid" : 6757 }, "shard" : "shard0001" }
12.    ……
13.    { "_id" : "testdb.testcollection-Uid_531424.0", "lastmod" : { "t" : 2, "i" : 4 }, "lastmodEpoch" : ObjectId("515fc5f0365c860f0bf8e0cb"), "ns" : "testdb.testcollection", "min" : { "Uid" : 531424 }, "max" : { "Uid" : 747137 }, "shard" : "shard0002" }
复制代码

这时我们强制杀掉shard2进程：

1.    [root@localhost mongodb-2.4.1]# ps -ef |grep mongo
2.    root      6329     1  0 22:52 ?        00:00:08 ./bin/mongod --dbpath data/shard3/ --logpath log/shard3.log --fork --port 27019
3.    kill -9 6329

我们尝试用属于不同范围的Uid对testdb.testcollection进行写入操作(这里插入一条记录应该不会导致新的块迁移)：

复制代码
1.    [root@localhost mongodb-2.4.1]# ps -ef |grep mongo
2.    use testdb
3.    switched to db testdb
4.    ####写
5.    mongos> db.testcollection.insert({"Uid":747138,"Name":"zhanjindong","Age":13,"Date":new Date()})
6.    ##向shard0000插入没有问题
7.    mongos> db.testcollection.insert({"Uid":6756,"Name":"zhanjindong","Age":13,"Date":new Date()})
8.    ##向shard0001插入没有问题
9.    mongos> db.testcollection.insert({"Uid":531425,"Name":"zhanjindong","Age":13,"Date":new Date()})
10.    socket exception [CONNECT_ERROR] for 192.168.129.132:27019
11.    ##向shard0002插入出问题
12.    ####读
13.    mongos> db.testcollection.find({Uid:747139})
14.    ##从shard0000读取没有问题
15.    mongos> db.testcollection.find({Uid: 2})
16.    ##从shard0001读取没有问题
17.    mongos> db.testcollection.find({Uid: 531426})
18.    error: {
19.        "$err" : "socket exception [SEND_ERROR] for 192.168.129.132:27019",
20.        "code" : 9001,
21.        "shard" : "shard0002"
22.    }
23.    ##从shard0002读取有问题
24.    b.testcollection.count()
25.    Sat Apr  6 00:23:19.246 JavaScript execution failed: count failed: {
26.        "code" : 11002,
27.        "ok" : 0,
28.        "errmsg" : "exception: socket exception [CONNECT_ERROR] for 192.168.129.132:27019"
29.    } at src/mongo/shell/query.js:L180
复制代码

可以看到插入操作涉及到分片shard0002的操作都无法完成。这是顺理成章的。

下面我们重新启动shard3看集群是否能自动恢复正常操作：

复制代码
1.    ./bin/mongod --dbpath data/shard3/ --logpath log/shard3.log --fork --port 27019
2.    mongos> use config
3.    switched to db config
4.    mongos> db.shards.find()
5.    { "_id" : "shard0000", "host" : "192.168.129.132:27017" }
6.    { "_id" : "shard0001", "host" : "192.168.129.132:27018" }
7.    { "_id" : "shard0002", "host" : "192.168.129.132:27019" }
复制代码

重复上面的插入和读取shard0002的操作：

1.    mongos> db.testcollection.insert({"Uid":531425,"Name":"zhanjindong","Age":13,"Date":new Date()})
2.    ##没有问题
3.    db.testcollection.find({Uid: 531426})
4.    { "_id" : ObjectId("515fc791b86c543aa1d7613e"), "Uid" : 531426, "Name" : "zhanjindong", "Age" : 13, "Date" : ISODate("2013-04-06T06:58:25.516Z") }
5.    ##没有问题

总结：当集群中某个分片宕掉以后，只要不涉及到该节点的操纵仍然能进行。当宕掉的节点重启后，集群能自动从故障中恢复过来。

这一节在前一节搭建的集群基础上做了一些简单的测试，下一节的重点是性能和优化相关。



插入、查询和更新

插入：MongoDB会根据片键和conifg中的信息写入到指定的分片上。

读取：以下内容摘抄自《深入学习MongoDB》

关于读取：上一节故障恢复中已经有所验证。

更新：如果要更新单个文档一定要在片键中使用片键（update的第一个参数）。我们现在OSSP10.bizuser(已经在_id上进行哈希分片)中插入一条记录：

1.    mongos> use OSSP10
2.    switched to db OSSP10
3.    mongos> db.bizuser.insert({"Uid":10001,"Name":"zhanjindong","Age":23})
4.    db.bizuser.find({"Name":"zhanjindong"})
5.    { "_id" : ObjectId("5160dd378bc15cdb61a131fc"), "Uid" : 10001, "Name" : "zhanjindong", "Age" : 23 }

 尝试根据Name来更新这个文档会得到一个错误：

1.    mongos> db.bizuser.update({"Name":"zhanjindong"},{"$set":{"Sex":0}})
2.    For non-multi updates, must have _id or full shard key ({ _id: "hashed" }) in query

根据片键来更新则不会有任何问题：

1.    mongos> db.bizuser.update({"_id":ObjectId("5160dd378bc15cdb61a131fc")},{"$set":{"Sex":0}})
2.    mongos> db.bizuser.find({"Name":"zhanjindong"})
3.    { "Age" : 23, "Name" : "zhanjindong", "Sex" : 0, "Uid" : 10001, "_id" : ObjectId("5160dd378bc15cdb61a131fc") }

但是批量更新中可以用任何条件：

1.    mongos> db.bizuser.insert({"Uid":10002,"Name":"dsfan","Age":23})
2.    mongos> db.bizuser.insert({"Uid":10003,"Name":"junling","Age":25})
3.    mongos> db.bizuser.update({"Age":23},{"$set":{"Sex":1}},false,true)
4.    mongos> db.bizuser.find({"Age":23})
5.    { "Age" : 23, "Name" : "zhanjindong", "Sex" : 1, "Uid" : 10001, "_id" : ObjectId("5160dd378bc15cdb61a131fc") }
6.    { "Age" : 23, "Name" : "dsfan", "Sex" : 1, "Uid" : 10002, "_id" : ObjectId("5160e2af8bc15cdb61a131fd") }

之所以更新单个文档会有这个强制限制是因为如果不指定片键，MongoDB会将更新操作路由到所有分片上，则无法保证更新操作在整个集群中只操作了一次（不同的分片上可能存在相同Uid的数据），指定片键后，更新操作只会路由到某一个分片上，MongoDB能保证只会更新在这个分片找到的第一个符合条件的文档。下面提到的唯一索引问题和这个问题本质是一样的。批量更新没有这个限制很好理解。

排序：在需要调用sort()来查询排序后的结果的时候，以分片Key的最左边的字段为依据，Mongos可以按照预先排序的结果来查询最少的分片，并且将结果信息返回给调用者。这样会花最少的时间和资源代价。 相反，如果在利用sort()来排序的时候，排序所依据的字段不是最左侧（起始）的分片Key，那么Mongos将不得不并行的将查询请求传递给每一个分片，然后将各个分片返回的结果合并之后再返回请求方。这个会增加Mongos的额外的负担。

片键和索引

 

所有分片的集合在片键上都必须建索引，这是MongoDB自动执行的，所以如果选择某个字段作为片键但是基本不在这个字段做查询那么等于浪费了一个索引，而增加一个索引总是会使得插入操作变慢。

唯一索引问题 如果集群在_id上进行了分片，则无法再在其他字段上建立唯一索引：

复制代码
1.    mongos> db.bizuser.ensureIndex( { "Uid": 1 }, { unique: true } )
2.    {
3.            "err" : "can't use unique indexes with sharding  ns:OSSP10.bizuser key: { Uid: 1.0 }",
4.            "code" : 10205,
5.            "n" : 0,
6.            "ok" : 1
7.    }
复制代码

之所以出现这个错误是因为MongoDB无法保证集群中除了片键以外其他字段的唯一性（验证了CAP理论），能保证片键的唯一性是因为文档根据片键进行切分，一个特定的文档只属于一个分片，MongoDB只要保证它在那个分片上唯一就在整个集群中唯一。

如果实现分片集群上的文档唯一性一种方法是在创建片键的时候指定它的唯一性：

复制代码
1.    mongos> use admin
2.    switched to db admin
3.    mongos> db.runCommand({"enablesharding":"test"})
4.    mongos> db.runCommand({"shardcollection":"test.users","key":{"Uid":1},unique:true})
5.    mongos> use test
6.    switched to db test
7.    mongos> db.users.insert({"Uid":1001})
8.    mongos> db.users.insert({"Uid":1001})
9.    E11000 duplicate key error index: test.users.$Uid_1  dup key: { : 1001.0 }
复制代码

事实上就是建立了一个唯一索引：

Note：更多关于分片集群上唯一索引问题参见《MongoDB Manual》page468。

哈希索引：

 

哈希索引支持使用任何单个字段包括内嵌文档，但是不能使用复合的字段，因此创建哈希索引的时候也只能指定一个字段：

1.    mongos> db.runCommand({"shardcollection":"mydb.mycollection","key":{"Uid":"hashed","Name":"hashed"}})
2.    {
3.            "ok" : 0,
4.            "errmsg" : "hashed shard keys currently only support single field keys"
5.    }

片键的选择

片键的选择对于整个分片集群的性能至关重要，上一节对分片集群中的读、写和更新操作已经做了说明，选择片键的时候要考虑到读自身应用的读写模式和新增分片的情况。

小基数片键：如果某个片键一共只有N个值，那最多只能有N个数据块，也最多只有个N个分片。则随着数据量的增大会出现非常大的但不可分割的chunk。如果打算使用小基数片键的原因是需要在那个字段上进行大量的查询，请使用组合片键，并确保第二个字段有非常多的不同值。

1.    mongos> db.runCommand({"enablesharding":"mydb"})
2.    db.runCommand({"shardcollection":"mydb.mycollection","key":{"x":1}})
3.    mongos> use mydb
4.    switched to db mydb
5.    mongos> var arrayObj = new Array("A","B","C")
6.    mongos> for(i=0;i<333333;i++){ db.mycollection.insert({"x":arrayObj[i%3],"y":"zhanjindong2","Age":13,"Date":new Date()}); }

无论再插入多少条数据，我们查看一下config.chunks会发现只会有三个块，三个块最多只能使用三个分片：

1.    { "_id" : "mydb.mycollection-x_MinKey", "lastmod" : { "t" : 2, "i" : 0 }, "lastmodEpoch" : ObjectId("51613a843999888c2cd63f41"), "ns" : "mydb.mycollection", "min" : { "x" : { "$minKey" : 1 } }, "max" : { "x" : "A" }, "shard" : "shard0001" }
2.    { "_id" : "mydb.mycollection-x_\"A\"", "lastmod" : { "t" : 3, "i" : 0 }, "lastmodEpoch" : ObjectId("51613a843999888c2cd63f41"), "ns" : "mydb.mycollection", "min" : { "x" : "A" }, "max" : { "x" : "C" }, "shard" : "shard0002" }
3.    { "_id" : "mydb.mycollection-x_\"C\"", "lastmod" : { "t" : 3, "i" : 1 }, "lastmodEpoch" : ObjectId("51613a843999888c2cd63f41"), "ns" : "mydb.mycollection", "min" : { "x" : "C" }, "max" : { "x" : { "$maxKey" : 1 } }, "shard" : "shard0000" }

递增的片键：使用递增的分片的好处是数据的“局部性”，使得将最新产生的数据放在一起，对于大部分应用来说访问新的数据比访问老的数据更频繁，这就使得被访问的数据尽快能的都放在内存中，提升读的性能。这类的片键比如时间戳、日期、ObjectId、自增的主键（比如从sqlserver中导入的数据）。但是这样会导致新的文档总是被插入到“最后”一个分片(块)上去,这种片键创造了一个单一且不可分散的热点，不具有写分散性。

随机片键：随机片键（比如MD5）最终会使数据块均匀分布在各个分片上，一般观点会以为这是一个很好的选择，解决了递增片键不具有写分散的问题，但是正因为是随机性会导致每次读取都可能访问不同的块，导致不断将数据从硬盘读到内存中，磁盘IO通常会很慢。

举个例子：比如mydb.mycollection集合记录下面这样的用户信息，Uid是一个比较随机的值：

{
    Uid:12313477994,
    Name:zhanjindong,
    Age:23,
    CreatedTime:2013-04-08 15:23:24.122
}

如果我们对Uid进行分片，那么同一分钟创建的用户信息可能被写入到了不同的块上（通常在不同的分片上），这有很好的分散性。但如果我们想根据时间来查找这一分钟产生的所有新用户，则mongos必须将查询操作路由给所有的分片的多个块上。但如果我们根据时间进行分片，那么这一分钟内新增用户可能都写入到一个块中，那么上面的查询操作只需要路由给一个分片上的一个块就完成了。

组合片键：一个理想的片键是同时拥有递增片键和随即片键的优点，这点很难做到关键是要理解自己的数据然后做出平衡。通常需要组合片键达到这种效果：

准升序键加搜索键 {coarselyAscending:1,search:1}

其中coarselyAscending每个值最好能对应几十到几百个数据块（比如以月为单位或天为单位），serach键应当是应用程序中通常都会依据其进行查询的字段，比如GUID。

注意：serach字段不能是升序字段，不然整个复合片键就下降为升序片键。这个字段应该具备非升序、分布随机基数适当的特点。

事实上，上面这种复合片键中的第一个字段保证了拥有数据局部性，第二字段则保证了查询的隔离性。同时因为第二个字段具备分布随机的特性因此又一定程度的拥有随机片键的特点。

哈希片键：对于哈希片键的选择官方文档中有很明确的说明：

选择哈希分片最大好处就是使得数据在各个节点分布比较均匀。2.2.5 Hased Shaeding一节对哈希片键的使用有简单的测试。

注意：建立哈希片键的时候不能指定唯一：

1.    mongos> db.runCommand({"shardcollection":"OSSP10.Devices","key":{"DeviceId":"hashed"},unique:true})
2.    { "ok" : 0, "errmsg" : "hashed shard keys cannot be declared unique." }

基于范围vs基于哈希

什么时候选择基于范围的分片，什么时候选择基于哈希的分片呢？官方文档的说明很少：

基于哈希的分片通常可以使得集群中数据分布的更加均匀。但是考虑具体应用情况可能有所不同，下面是引用10gen的产品市场总监Kelly Stirman的一段话：

当使用基于范围的分片，如果你的应用程序基于一个分片键范围请求数据，那么这些查询会被路由到合适的分片，通常只有一个分片，特殊情况下可能有一些分片。在一个使用了基于哈希分片的系统中，同样的查询会将请求路由到更多的分片，可能是所有的分片。理想情况下，我们希望查询会被路由到一个单独的分片或者尽可能少的分片，因为这样的扩展能力要比将所有的查询路由到所有的分片好。因此，如果你非常理解自己的数据和查询，那么基于范围的分片可能是最好的选择。

出处：http://www./news/2013/03/mongodb-2-4

总结：对MongoDB 单条记录的访问比较随机时，可以考虑采用哈希分片，否则范围分片可能会更好。

Balancer

小的chunkSize能保证各个分片数据分布更均匀，但导致迁移更频繁。MongoDB为了尽量减少对性能的影响对块迁移的算法有很多的优化措施：2.2.2节对Migration Threshold有简单的说明，另外balancer进程能聪明的避开整个集群高峰时期。

可以定时的执行数据迁移：

1.    use config
2.    db.settings.update({ _id : "balancer" }, { $set : { activeWindow : { start : "23:00", stop: "6:00"

删除定时数据迁移设置：

1.    use config
2.    db.settings.update({ _id : "balancer" }, { $unset : { activeWindow : true } })

开启和关闭balancer：

1.    sh.startBalancer()
2.    sh.stopBalancer()

如果正在有数据进行迁移的话，stopBalancer会等待迁移结束，可以通过下面的方式查看当前是否有迁移在进行：

1.    use config
2.    while( db.locks.findOne({_id: "balancer"}).state ) {
3.    print("waiting..."); sleep(1000);

Note:更多关于balancer信息参见《MongoDB-Manual》page 455

手动分片

MongoDB自动分片都是先从一个分片上的一个块开始的，然后通过不断的分裂和迁移来达到数据的切分和平衡，依赖机器自动执行的好处是简单，但是代价就是性能（虽然balancer已经做了很多优化）。因此MongoDB允许进行手动切分，手动切分有下面两个步骤（官方示例）：

1、用split命令对空集合进行手动的切分。

复制代码
1.    mongos> use admin
2.    switched to db admin
3.    mongos> db.runCommand({"enablesharding":"myapp"})
4.    mongos> db.runCommand({"shardcollection":"myapp.users","key":{"email":1}})
5.    for ( var x=97; x<97+26; x++ ){
6.    for( var y=97; y<97+26; y+=6 ) {
7.    var prefix = String.fromCharCode(x) + String.fromCharCode(y);
8.    db.runCommand( { split : "myapp.users" , middle : { email : prefix } } );
9.           }
10.    }
复制代码

注意：

最好只对一个空的集合进行预分割，如果对存在数据的集合进行预分割,MongoDB会先进行自动分割，然后在尝试进行手动的分割。这可能导致大规模的分割和低效的平横。

2、利用moveChunk命令手动的移动分割的块:

复制代码
1.    var shServer = [ "sh0.example.net", "sh1.example.net", "sh2.example.net", "sh3.example.net", "sh4.example.net" ];
2.    for ( var x=97; x<97+26; x++ ){
3.     for( var y=97; y<97+26; y+=6 ) {
4.      var prefix = String.fromCharCode(x) + String.fromCharCode(y);
5.      db.adminCommand({moveChunk : "myapp.users", find : {email : prefix}, to : shServer[(y-97)/6]})
6.     }
7.    }
复制代码

或者利用balancer自动平衡。

要很好进行手动的切分必须了解片键的范围，如果片键是一个随机值比如哈希分片，则很难进行手动的预分割，其次及时进行了预分割随后插入数据块分裂和迁移（没关闭balancer）依然会存在。

结论：预分割和手动分片适合于将片键范围确定的数据初始化到分片集群中。

其他

journal

如果机器是32位的话在配置分片集群启动shard的时候跟上—journal参数。因为64位默认是开启journal的，32位没有。

NUMA CPU架构问题

NUMA是多核心CPU架构中的一种，其全称为Non-Uniform MemoryAccess，简单来说就是在多核心CPU中，机器的物理内存是分配给各个核的。2.1.1的表中可以看到192.168.71.43这台机器的CPU架构正是NUMA。

在NUMA架构的机器上启动mongodb进程需要特别注意。我们先以正常的方式启动mongodb，然后登录，如下：

3.    ./bin/mongod --dbpath data/ --logpath log/mongodb.log –fork
4.    ./bin/mongo

你会看到类似下面的警告信息：

1.    . Server has startup warnings: 
2.    Mon Apr  1 20:49:25.900 [initandlisten] 
3.    Mon Apr  1 20:49:25.900 [initandlisten] ** WARNING: You are running on a NUMA machine.
4.    Mon Apr  1 20:49:25.900 [initandlisten] **          We suggest launching mongod like this to avoid performance problems:
5.    Mon Apr  1 20:49:25.900 [initandlisten] **              numactl --interleave=all mongod [other options]
6.    Mon Apr  1 20:49:25.900 [initandlisten]

按照提示我们应该向下面这样启动mongodb进程，在启动命令前加上numactl --interleave选项：

1.    numactl --interleave=all ./bin/mongod --dbpath data/ --logpath log/mongodb.log --fork

这时再登录mongodb就不会再有警告信息了。

以上只是就问题解决问题，至于在NUMA架构的CPU上非正常启动mongodb会带来什么样的性能影响还没做验证，网上可以搜到一些别人使用的经验。官方的文档(参看MongoDB Documentation, Release 2.4.1 12.8.1 MongoDB on NUMA Hardware)中有如下说明：

简单做下解释，NUMA架构中每个核访问分配给自己的内存会比分配给其他核内存要快，有下面几种访问控制策略：

  • 缺省(default)：总是在本地节点分配（分配在当前进程运行的节点上）；
  • 绑定(bind)：强制分配到指定节点上；
  • 交叉(interleave)：在所有节点或者指定的节点上交织分配；
  • 优先(preferred)：在指定节点上分配，失败则在其他节点上分配。

但是目前mongodb在这种架构下工作的不是很好，--interleave=all就是禁用NUMA为每个核单独分配内存的机制。

    本站是提供个人知识管理的网络存储空间，所有内容均由用户发布，不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息，谨防诈骗。如发现有害或侵权内容，请点击一键举报。
    转藏 分享 献花（0）

    来自： 昵称21365845 > 《MongoDB》

    举报/认领

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多