MongoDB: 其中一个分片不像其他分片那样平衡
MongoDB: One of the shard is not equally balanced like other shards
我的应用程序有一个分片集群设置，但不幸的是，其中一个分片占用了 17 GB 的数据大小，而其他分片平均占用了 3 GB 的数据大小。可能是什么问题？
sh.status() 给了我巨大的输出。分享于此：https://www.dropbox.com/s/qqsucbm6q9egbhf/shard.txt?dl=0
我的坏 collection 分片分布详情如下。
mongos> db.MyCollection_1_100000.getShardDistribution()
Shard shard_0 at shard_0/mongo-11.2816.mongodbdns.com:270
00,mongo-12.2816.mongodbdns.com:27000,mongo-13.2816. mongodbdns.com:27000,mongo-3.2816.mongodbdns.com:27003
data : 143.86MiB docs : 281828 chunks : 4
estimated data per chunk : 35.96MiB
estimated docs per chunk : 70457
Shard shard_1 at shard_1/mongo-10.2816.mongodbdns.com:270 00,mongo-11.2816.mongodbdns.com:27002,mongo-19.2816. mongodbdns.com:27001,mongo-9.2816.mongodbdns.com:27005
data : 107.66MiB docs : 211180 chunks : 3
estimated data per chunk : 35.88MiB
estimated docs per chunk : 70393
Shard shard_2 at shard_2/mongo-14.2816.mongodbdns.com:270 00,mongo-3.2816.mongodbdns.com:27000,mongo-4.2816.mo ngodbdns.com:27000,mongo-6.2816.mongodbdns.com:27002
data : 107.55MiB docs : 210916 chunks : 3
estimated data per chunk : 35.85MiB
estimated docs per chunk : 70305
Shard shard_3 at shard_3/mongo-14.2816.mongodbdns.com:270 04,mongo-18.2816.mongodbdns.com:27002,mongo-6.2816.m ongodbdns.com:27000,mongo-8.2816.mongodbdns.com:27000
data : 107.99MiB docs : 211506 chunks : 3
estimated data per chunk : 35.99MiB
estimated docs per chunk : 70502
Shard shard_4 at shard_4/mongo-12.2816.mongodbdns.com:270 01,mongo-13.2816.mongodbdns.com:27001,mongo-17.2816. mongodbdns.com:27002,mongo-6.2816.mongodbdns.com:27003
data : 107.92MiB docs : 211440 chunks : 3
estimated data per chunk : 35.97MiB
estimated docs per chunk : 70480
Shard shard_5 at shard_5/mongo-17.2816.mongodbdns.com:270 01,mongo-18.2816.mongodbdns.com:27001,mongo-19.2816. mongodbdns.com:27000
data : 728.64MiB docs : 1423913 chunks : 4
estimated data per chunk : 182.16MiB
estimated docs per chunk : 355978
Shard shard_6 at shard_6/mongo-10.2816.mongodbdns.com:270 01,mongo-14.2816.mongodbdns.com:27005,mongo-3.2816.m ongodbdns.com:27001,mongo-8.2816.mongodbdns.com:27003
data : 107.52MiB docs : 211169 chunks : 3
estimated data per chunk : 35.84MiB
estimated docs per chunk : 70389
Shard shard_7 at shard_7/mongo-17.2816.mongodbdns.com:270 00,mongo-18.2816.mongodbdns.com:27000,mongo-19.2816. mongodbdns.com:27003,mongo-9.2816.mongodbdns.com:27003
data : 107.87MiB docs : 211499 chunks : 3
estimated data per chunk : 35.95MiB
estimated docs per chunk : 70499
Shard shard_8 at shard_8/mongo-19.2816.mongodbdns.com:270 02,mongo-4.2816.mongodbdns.com:27002,mongo-8.2816.mo ngodbdns.com:27001,mongo-9.2816.mongodbdns.com:27001
data : 107.83MiB docs : 211154 chunks : 3
estimated data per chunk : 35.94MiB
estimated docs per chunk : 70384
Shard shard_9 at shard_9/mongo-10.2816.mongodbdns.com:270 02,mongo-11.2816.mongodbdns.com:27003,mongo-12.2816. mongodbdns.com:27002,mongo-13.2816.mongodbdns.com:27002
data : 107.84MiB docs : 211483 chunks : 3
estimated data per chunk : 35.94MiB
estimated docs per chunk : 70494
Totals
data : 1.69GiB docs : 3396088 chunks : 32
Shard shard_0 contains 8.29% data, 8.29% docs in cluster, avg obj size on shard : 535B
Shard shard_1 contains 6.2% data, 6.21% docs in cluster, avg obj size on shard : 5 34B
Shard shard_2 contains 6.2% data, 6.21% docs in cluster, avg obj size on shard : 5 34B
Shard shard_3 contains 6.22% data, 6.22% docs in cluster, avg obj size on shard : 535B
Shard shard_4 contains 6.22% data, 6.22% docs in cluster, avg obj size on shard : 535B
Shard shard_5 contains 42% data, 41.92% docs in cluster, avg obj size on shard : 5 36B
Shard shard_6 contains 6.19% data, 6.21% docs in cluster, avg obj size on shard : 533B
Shard shard_7 contains 6.21% data, 6.22% docs in cluster, avg obj size on shard : 534B
Shard shard_8 contains 6.21% data, 6.21% docs in cluster, avg obj size on shard : 535B
Shard shard_9 contains 6.21% data, 6.22% docs in cluster, avg obj size on shard : 534B
我有 150 多个类似的 collection，我将数据除以 user_id
e.g. MyCollection_1_100000
MyCollection_100001_200000
MyCollection_200001_300000
这里我在MyCollection_1_100000中划分了用户id范围从1到100000的数据，同样对于其他collections
shard key for all 150+ collection 是序号但它是 hashed。通过以下方式申请
db.MyCollection_1_100000.ensureIndex({"column": "hashed"})
sh.shardCollection("dbName.MyCollection_1_100000", { "column": "hashed" })
请建议我解决不平衡分片问题的纠正步骤。
未共享Collections
分片 5 是集群中的主分片，这意味着它将占用所有 未分片的 collections，因此它的大小会变大。你应该检查一下。参见 here。
块分割
正如 Markus 指出的那样，分发是按块而不是按文档完成的。块可能会增长到它们定义的块大小。当它们超过块大小时，它们将被拆分并重新分配。在您的情况下，似乎至少有一个 collection 比所有其他分片多了 1 个块。原因可能是块尚未达到其块限制（检查 db.settings.find( { _id:"chunksize" }) 默认大小为 64MB，另请参阅 here）或者块无法拆分，因为块表示的范围不能进一步自动拆分。您应该使用 sh.status(true) 命令检查范围（在您发布的大输出中省略了某些 collections 的范围输出）
但是你可以split the chunk manually。
dba forum.
上也有很好的回答
分片键
如果您没有未分片的 collection，问题可能出在分片键本身。 Mongo suggest 使用具有高基数和高度随机性的分片键。在不知道您的列的值范围的情况下，我假设基数相当低（即 1000 列），比方说时间戳（每个条目 1，构成很多不同的值）。
此外，数据应该均匀分布。因此，假设您有 10 个可能的列。但是有更多的条目具有列名称的特定值，所有这些条目都将写入同一个分片。例如
- entries.count({列: "A"} = 10 -> 分片 0
- entries.count({列: "B"} = 10 -> 分片 1
- ...
- entries.count({列: "F"} = 100 -> 分片 5
sh.status() 命令应该会为您提供有关区块的更多信息。
如果您使用 object id 或时间戳 - 它们是单调递增的值 - 将导致数据也被写入同一块。
因此 Mongo 建议使用复合键，这将导致更高的基数（字段 1 的 value-range x 字段 2 的 value-range）。在您的情况下，您可以将列名与时间戳结合起来。
但无论哪种方式，您当前的安装都不走运，因为您不能 change the shard key afterwards。
数据库设计
您打印的详细输出还表明，您有多个 dbs/collections 具有相同的模式或目的，我认为这些是手动分区的。这有什么特别的原因吗？这可能会影响集群中数据的分布以及每个 collection 开始在主节点上填充。至少有一个 collection 在主节点上只有一个块，一些总共有 3 或 4 个块，所有在主节点上都至少有一个块（即 z_best_times_*）。
最好你应该只有一个 collection 用于一个目的，并且可能使用复合分片键（即另外的哈希时间戳）。
我的应用程序有一个分片集群设置，但不幸的是，其中一个分片占用了 17 GB 的数据大小，而其他分片平均占用了 3 GB 的数据大小。可能是什么问题？
sh.status() 给了我巨大的输出。分享于此：https://www.dropbox.com/s/qqsucbm6q9egbhf/shard.txt?dl=0
我的坏 collection 分片分布详情如下。
mongos> db.MyCollection_1_100000.getShardDistribution()
Shard shard_0 at shard_0/mongo-11.2816.mongodbdns.com:270
00,mongo-12.2816.mongodbdns.com:27000,mongo-13.2816. mongodbdns.com:27000,mongo-3.2816.mongodbdns.com:27003
data : 143.86MiB docs : 281828 chunks : 4
estimated data per chunk : 35.96MiB
estimated docs per chunk : 70457
Shard shard_1 at shard_1/mongo-10.2816.mongodbdns.com:270 00,mongo-11.2816.mongodbdns.com:27002,mongo-19.2816. mongodbdns.com:27001,mongo-9.2816.mongodbdns.com:27005
data : 107.66MiB docs : 211180 chunks : 3
estimated data per chunk : 35.88MiB
estimated docs per chunk : 70393
Shard shard_2 at shard_2/mongo-14.2816.mongodbdns.com:270 00,mongo-3.2816.mongodbdns.com:27000,mongo-4.2816.mo ngodbdns.com:27000,mongo-6.2816.mongodbdns.com:27002
data : 107.55MiB docs : 210916 chunks : 3
estimated data per chunk : 35.85MiB
estimated docs per chunk : 70305
Shard shard_3 at shard_3/mongo-14.2816.mongodbdns.com:270 04,mongo-18.2816.mongodbdns.com:27002,mongo-6.2816.m ongodbdns.com:27000,mongo-8.2816.mongodbdns.com:27000
data : 107.99MiB docs : 211506 chunks : 3
estimated data per chunk : 35.99MiB
estimated docs per chunk : 70502
Shard shard_4 at shard_4/mongo-12.2816.mongodbdns.com:270 01,mongo-13.2816.mongodbdns.com:27001,mongo-17.2816. mongodbdns.com:27002,mongo-6.2816.mongodbdns.com:27003
data : 107.92MiB docs : 211440 chunks : 3
estimated data per chunk : 35.97MiB
estimated docs per chunk : 70480
Shard shard_5 at shard_5/mongo-17.2816.mongodbdns.com:270 01,mongo-18.2816.mongodbdns.com:27001,mongo-19.2816. mongodbdns.com:27000
data : 728.64MiB docs : 1423913 chunks : 4
estimated data per chunk : 182.16MiB
estimated docs per chunk : 355978
Shard shard_6 at shard_6/mongo-10.2816.mongodbdns.com:270 01,mongo-14.2816.mongodbdns.com:27005,mongo-3.2816.m ongodbdns.com:27001,mongo-8.2816.mongodbdns.com:27003
data : 107.52MiB docs : 211169 chunks : 3
estimated data per chunk : 35.84MiB
estimated docs per chunk : 70389
Shard shard_7 at shard_7/mongo-17.2816.mongodbdns.com:270 00,mongo-18.2816.mongodbdns.com:27000,mongo-19.2816. mongodbdns.com:27003,mongo-9.2816.mongodbdns.com:27003
data : 107.87MiB docs : 211499 chunks : 3
estimated data per chunk : 35.95MiB
estimated docs per chunk : 70499
Shard shard_8 at shard_8/mongo-19.2816.mongodbdns.com:270 02,mongo-4.2816.mongodbdns.com:27002,mongo-8.2816.mo ngodbdns.com:27001,mongo-9.2816.mongodbdns.com:27001
data : 107.83MiB docs : 211154 chunks : 3
estimated data per chunk : 35.94MiB
estimated docs per chunk : 70384
Shard shard_9 at shard_9/mongo-10.2816.mongodbdns.com:270 02,mongo-11.2816.mongodbdns.com:27003,mongo-12.2816. mongodbdns.com:27002,mongo-13.2816.mongodbdns.com:27002
data : 107.84MiB docs : 211483 chunks : 3
estimated data per chunk : 35.94MiB
estimated docs per chunk : 70494
Totals
data : 1.69GiB docs : 3396088 chunks : 32
Shard shard_0 contains 8.29% data, 8.29% docs in cluster, avg obj size on shard : 535B
Shard shard_1 contains 6.2% data, 6.21% docs in cluster, avg obj size on shard : 5 34B
Shard shard_2 contains 6.2% data, 6.21% docs in cluster, avg obj size on shard : 5 34B
Shard shard_3 contains 6.22% data, 6.22% docs in cluster, avg obj size on shard : 535B
Shard shard_4 contains 6.22% data, 6.22% docs in cluster, avg obj size on shard : 535B
Shard shard_5 contains 42% data, 41.92% docs in cluster, avg obj size on shard : 5 36B
Shard shard_6 contains 6.19% data, 6.21% docs in cluster, avg obj size on shard : 533B
Shard shard_7 contains 6.21% data, 6.22% docs in cluster, avg obj size on shard : 534B
Shard shard_8 contains 6.21% data, 6.21% docs in cluster, avg obj size on shard : 535B
Shard shard_9 contains 6.21% data, 6.22% docs in cluster, avg obj size on shard : 534B
我有 150 多个类似的 collection，我将数据除以 user_id
e.g. MyCollection_1_100000
MyCollection_100001_200000
MyCollection_200001_300000
这里我在MyCollection_1_100000中划分了用户id范围从1到100000的数据，同样对于其他collections
shard key for all 150+ collection 是序号但它是 hashed。通过以下方式申请
db.MyCollection_1_100000.ensureIndex({"column": "hashed"})
sh.shardCollection("dbName.MyCollection_1_100000", { "column": "hashed" })
请建议我解决不平衡分片问题的纠正步骤。
未共享Collections
分片 5 是集群中的主分片，这意味着它将占用所有 未分片的 collections，因此它的大小会变大。你应该检查一下。参见 here。
块分割
正如 Markus 指出的那样，分发是按块而不是按文档完成的。块可能会增长到它们定义的块大小。当它们超过块大小时，它们将被拆分并重新分配。在您的情况下，似乎至少有一个 collection 比所有其他分片多了 1 个块。原因可能是块尚未达到其块限制（检查 db.settings.find( { _id:"chunksize" }) 默认大小为 64MB，另请参阅 here）或者块无法拆分，因为块表示的范围不能进一步自动拆分。您应该使用 sh.status(true) 命令检查范围（在您发布的大输出中省略了某些 collections 的范围输出）
但是你可以split the chunk manually。
dba forum.
分片键
如果您没有未分片的 collection，问题可能出在分片键本身。 Mongo suggest 使用具有高基数和高度随机性的分片键。在不知道您的列的值范围的情况下，我假设基数相当低（即 1000 列），比方说时间戳（每个条目 1，构成很多不同的值）。
此外，数据应该均匀分布。因此，假设您有 10 个可能的列。但是有更多的条目具有列名称的特定值，所有这些条目都将写入同一个分片。例如
- entries.count({列: "A"} = 10 -> 分片 0
- entries.count({列: "B"} = 10 -> 分片 1
- ...
- entries.count({列: "F"} = 100 -> 分片 5
sh.status() 命令应该会为您提供有关区块的更多信息。
如果您使用 object id 或时间戳 - 它们是单调递增的值 - 将导致数据也被写入同一块。 因此 Mongo 建议使用复合键，这将导致更高的基数（字段 1 的 value-range x 字段 2 的 value-range）。在您的情况下，您可以将列名与时间戳结合起来。
但无论哪种方式，您当前的安装都不走运，因为您不能 change the shard key afterwards。
数据库设计
您打印的详细输出还表明，您有多个 dbs/collections 具有相同的模式或目的，我认为这些是手动分区的。这有什么特别的原因吗？这可能会影响集群中数据的分布以及每个 collection 开始在主节点上填充。至少有一个 collection 在主节点上只有一个块，一些总共有 3 或 4 个块，所有在主节点上都至少有一个块（即 z_best_times_*）。
最好你应该只有一个 collection 用于一个目的，并且可能使用复合分片键（即另外的哈希时间戳）。