MongoDB分块分布

Question

我已经部署了带有两个碎片(两个副本集)的带有的MongoDB集群。

不幸的是，我在碎片之间的块分发方面遇到了问题，我对MongoDB和数据库一般都很陌生，所以这些问题可能是我误解了主题的结果。描述问题的问题在文章的底部，下面是我的切分集群的配置。

共享簇

它包括：

1. 配置副本集，每个实例配置为: mongod configsvr- configReplicaSet --绑定_ip 0.0.0.0 -dbpath /data/db -port 27019
2. 三个单神实例的第一个副本碎片，每个实例配置为: mongod shardsvr shardReplicaSet1 -绑定_ip 0.0.0.0 -dbpath /data/db -端口27017
3. 三个单神实例的第二个副本碎片，每个实例配置为: mongod shardsvr shardReplicaSet2 -绑定_ip 0.0.0.0 -dbpath /data/db -端口27017
4. 单个mongos实例，它的容器以/bin/bash开头，尽管在docker -组合中有命令，但实际上，在docker映像中定义的入口点是/bin/bash，所以它可能会重写坞-复合
5. 单芒果壳实例。

这是莱克-复合公司。

version: '2.1'
services:
  mongors1-1:
    container_name: mongors1-1
    image: mongodb-server-shard
    command: mongod --shardsvr --replSet shardReplicaSet1 --bind_ip 0.0.0.0  --dbpath /data/db --port 27017
    ports:
    - 27011:27017
    expose:
    - "27017"
    networks:
      default:
        ipv4_address: 172.19.0.11
    stdin_open: true
    tty: true

  mongors1-2:
    container_name: mongors1-2
    image: mongodb-server-shard
    command: mongod --shardsvr --replSet shardReplicaSet1 --bind_ip 0.0.0.0  --dbpath /data/db --port 27017
    ports:
    - 27012:27017
    expose:
    - "27017"
    networks:
      default:
        ipv4_address: 172.19.0.12
    stdin_open: true
    tty: true

  mongors1-3:
    container_name: mongors1-3
    image: mongodb-server-shard
    command: mongod --shardsvr --replSet shardReplicaSet1 --bind_ip 0.0.0.0  --dbpath /data/db --port 27017
    ports:
    - 27013:27017
    expose:
    - "27017"
    networks:
      default:
        ipv4_address: 172.19.0.13
    stdin_open: true
    tty: true

  mongors2-1:
    container_name: mongors2-1
    image: mongodb-server-shard
    command: mongod --shardsvr --replSet shardReplicaSet2 --bind_ip 0.0.0.0  --dbpath /data/db --port 27017
    ports:
    - 27021:27017
    expose:
    - "27017"
    networks:
      default:
        ipv4_address: 172.19.0.21
    stdin_open: true
    tty: true

  mongors2-2:
    container_name: mongors2-2
    image: mongodb-server-shard
    command: mongod --shardsvr --replSet shardReplicaSet2 --bind_ip 0.0.0.0  --dbpath /data/db --port 27017
    ports:
    - 27022:27017
    expose:
    - "27017"
    networks:
      default:
        ipv4_address: 172.19.0.22
    stdin_open: true
    tty: true

  mongors2-3:
    container_name: mongors2-3
    image: mongodb-server-shard
    command: mongod --shardsvr --replSet shardReplicaSet2 --bind_ip 0.0.0.0  --dbpath /data/db --port 27017
    ports:
    - 27023:27017
    expose:
    - "27017"
    networks:
      default:
        ipv4_address: 172.19.0.23
    stdin_open: true 
    tty: true

  mongocfg1:
    container_name: mongocfg1
    image: mongodb-server-shard
    command: mongod --configsvr --replSet configReplicaSet --bind_ip 0.0.0.0  --dbpath /data/db --port 27019
    ports:
    - 2001:27019
    expose:
    - "27019"
    networks:
      default:
        ipv4_address: 172.19.0.101
    stdin_open: true
    tty: true

  mongocfg2:
    container_name: mongocfg2
    image: mongodb-server-shard
    command: mongod --configsvr --replSet configReplicaSet --bind_ip 0.0.0.0 --dbpath /data/db --port 27019
    ports:
    - 2002:27019
    expose:
    - "27019"
    networks:
      default:
        ipv4_address: 172.19.0.102
    stdin_open: true
    tty: true

  mongocfg3:
    container_name: mongocfg3
    image: mongodb-server-shard
    command: mongod --configsvr --replSet configReplicaSet --bind_ip 0.0.0.0 --dbpath /data/db --port 27019
    ports:
    - 2003:27019
    expose:
    - "27019"
    networks:
      default:
        ipv4_address: 172.19.0.103
    stdin_open: true 
    tty: true

  mongo-client:
    container_name: mongo-client1
    image: mongodb-client
    ports:
    - 5000:5000
    expose:
    - "5000"
    networks:
     default:
        ipv4_address: 172.19.0.50
    stdin_open: true 
    tty: true

  mongos1:
    container_name: mongos1
    image: mongodb-mongos
    command: mongos --configdb configReplicaSet/mongocfg1:27019,mongocfg2:27019 --bind_ip 0.0.0.0
    ports:
    - 3300:3300
    expose:
    - "3300"
    - "27017"
    networks:
     default:
        ipv4_address: 172.19.0.150
    stdin_open: true 
    tty: true

  # iperf3-server:
  #   container_name: iperf3-server
  #   image: networkstatic/iperf3
  #   expose:
  #   - "5201"
  #   command: iperf -s
  #   networks:
  #    default:
  #       ipv4_address: 172.19.0.200
  #   stdin_open: true 
  #   tty: true

  # iperf3-client:
  #   container_name: iperf3-client
  #   image: networkstatic/iperf3
  #   expose:
  #   - "5202"
  #   command: iperf -c 172.19.0.200
  #   networks:
  #    default:
  #       ipv4_address: 172.19.0.201
  #   stdin_open: true 
  #   tty: true

我不是使用正式的码头枢纽映像，而是我自己的，它们非常简单，基本安装，区别是，容器与单神--例如，只安装了单神--而不是整个MongoDB安装，类似地，mongos只是安装了mongos。我认为这可能是问题的根源。

iperf3集装箱用于码头桥接网络的速度测量，带宽超过50 Gbites/s，不应成为问题的根源。

集群的进一步配置如下：

1. 我从mongo-client1 1连接到一个配置服务器并运行rs.initiate( { _id："configReplicaSet"，configsvr: true，{_id :0，主机：“mongocfg1 1:27019”}，{_id:1，主机：“mongocfg2 2:27019”}，{_id:2，主机：“mongocfg3 3:27019”} })
2. 类似地，我连接到一个shardReplicaSet1 mongod实例并运行: rs.initiate( { _id："shardReplicaSet1"， members： {_id :0，主机：“mongors1-1:27017”}， {_id :1，主机：“mongors1-2:27017”}， {_id :2，主机：“mongors1-3:27017”}})
3. 以类似的方式，我激发shardReplicaSet2。
4. 我使用连接到mongos1容器并启动mongos的mongos --configdb configReplicaSet/mongocfg1 1:27019，mongocfg1 2:27019-bind_IP0.0.0.0
   1. 我从mongo 1连接到mongos1并运行: sh.addShard( "shardReplicaSet1/mongors1-1:27017")和sh.addShard( "shardReplicaSet2/mongors2-1:27017")，我不知道这是否必要，但我使用每个副本集的主成员的主机名。

问题

1. 通过连接到mongos1，我创建了名为"key_v“的数据库，集合名为"performance"，然后启用对数据库的切分(sh.enableSharding("key_v"))，然后在集合上启用，然后使用shard键: sh.shardCollection("key_v.performance"，{"address"：1})，然后使用for循环向其插入许多文档：

(i=0；i<=10000；i++)

{

db.collection.insert("address": i,"array1": [999, "foo"]);

}

哦，我之前把块大小设置为1MB。因此，循环结束后，db.collection.getShardDistribution()的结果显示，所有块只位于一个碎片上，几分钟后，实际上块在碎片之间平均分布。下面是我的问题:在执行循环期间，mongos不应该在碎片之间分配块，而不是将它们全部分配到一个碎片中吗？如果它可以配置，我应该如何实现？通过这个？[https://docs.mongodb.com/manual/tutorial/manage-shard-zone/][1]。也许碎片钥匙不对？

1. 另一个相关的例子是:我尝试使用mongorestore在bson中导入大型MongoDB数据库。我是从Docker网络外部完成的: mongorestore --主机127.19.0.150:3300 -d import1 -c test /path/base.bson导入工作良好，但是所有的块都位于一个碎片中。此外，这个块到第二个碎片的迁移非常缓慢，数据库重1.3GBytes，40分钟后只有32%的块被迁移了。数据库数据模式由多个字段组成，我选择了一个以Int32数据类型作为切分键的字段，但是它的基数很低，15%的文档具有相同的值，这是它的一个来源吗？每块估计数据为529 per (getShardDistribution()方法结果)。

所有的容器都运行在32 of内存和i7-6700 of的计算机上，缓慢的HDD会不会成为导致块迁移的瓶颈？

Answer 1

因此，循环结束后，db.collection.getShardDistribution()的结果显示，所有块只位于一个碎片上，几分钟后，实际上块在碎片之间平均分布。下面是我的问题:在执行循环期间，mongos不应该在碎片之间分配块，而不是将它们全部分配到一个碎片中吗？

问题是，您使用的是单调递增的切分键。这将导致所有针对单个碎片(也称为“热碎片”)的插入，这些碎片当前具有代表最高碎片键值的块范围。数据最终将被重新平衡到其他碎片，但这并不是对写入缩放的有效使用。你需要选择一个更合适的碎片键。如果您的用例不需要范围查询，也可以考虑在散列碎片键字段上使用address。有关预期结果的说明，请参见散列与范围切分。

另一个相关的例子是:我尝试使用mongorestore在bson中导入大型MongoDB数据库。我是从Docker网络外部完成的: mongorestore --主机127.19.0.150:3300 -d import1 -c test /path/base.bson导入工作良好，但是所有的块都位于一个碎片中。

如果结果是相似的(所有插入到单个碎片，然后被重新平衡)，这也意味着一个糟糕的碎片关键选择。

如果要将大容量插入到空的切分集合中，可以使用一种方法来最小化再平衡:基于现有数据中的切分键值的已知分布的预分割块范围。

数据库数据模式由多个字段组成，我选择了一个以Int32数据类型作为切分键的字段，但是它的基数很低，15%的文档具有相同的值，这是它的一个来源吗？

基数低的切分键肯定会导致数据分配问题。最细粒度的块范围表示单个碎片键值。如果您的文档中有很大一部分共享相同的切分键值，这些值最终将导致不可分割的jumbo chunks，这将被平衡器忽略。

所有的容器都运行在32 of内存和i7-6700 of的计算机上，缓慢的HDD会不会成为导致块迁移的瓶颈？

没有足够的信息来确定磁盘是否是最受限制的因素，但是在一台具有慢速HDD的计算机上运行分片集群肯定会增加资源争用的挑战。选择适当的切分键可以将数据迁移的需求降到最低，除非您要为部署添加或删除碎片。

假设您使用的是MongoDB的最新版本，而WiredTiger存储引擎是默认的(MongoDB 3.2+)，那么您肯定希望显式地设置--wiredTigerCacheSizeGB以限制mongod实例的内部缓存大小。见：我应该将WiredTiger内部缓存设置到什么大小？。