logo标签列表

MongoDB: 其中一个分片与其他分片不平衡

mongodbsharding
4
我为我的应用程序设置了一个分片集群，但不幸的是，其中一个分片的数据大小为17 GB，而其他分片的数据大小平均为3 GB。可能出了什么问题？ < p > 10 shards

< p >sh.status()给我提供了大量输出。在这里分享：https://www.dropbox.com/s/qqsucbm6q9egbhf/shard.txt?dl=0

< p >我的糟糕的集合分片分布详细信息如下。

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多个类似的集合，我已通过用户ID将数据分开。

e.g. MyCollection_1_100000
MyCollection_100001_200000
MyCollection_200001_300000

这里我将用户ID数据从1到100000分成了MyCollection_1_100000等其他集合。

所有150多个集合的分片键都是连续数字，但它们被哈希了。应用方式如下：

db.MyCollection_1_100000.ensureIndex({"column": "hashed"})
sh.shardCollection("dbName.MyCollection_1_100000", { "column": "hashed" })

请建议我采取纠正措施来解决不平衡分片问题。
是的，它是 shard_5。 - Avinash
1
请提供完整的 sh.status() 输出，包括键范围。请还为每个分片集合添加 db.youShardedColl.getShardDistribution() 的输出。即使输出很大：我们也需要它。 - Markus W Mahlberg
如果 sh.status() 很大，你可以将其内容发布到像 Dropbox 这样的文件共享服务中，并链接。 - ggallo
嗨@Avinash，你的数据库db中只有一个集合吗？另外，你能否发布db.collection.stats()的输出结果？谢谢。 - Héctor Valverde
@MarkusWMahlberg 我已经在我的问题中添加了完整的sh.status()输出的Dropbox链接，并粘贴了一个未平衡的集合的getShardDistribution()。 - Avinash
1个回答
6

未共享的集合

Shard 5是您集群中的主要分片，这意味着它将接管所有未分片的集合，因此在大小上会变得更大。您应该检查一下。请参见此处。

块分割

正如Markus所指出的那样，分布是按块而不是按文档进行的。块可以增长到其定义的块大小。当它们超过块大小时，它们将被拆分和重新分配。在您的情况下，似乎至少有一个集合比所有其他碎片多了1个块。原因可能是该块尚未达到其块限制（检查db.settings.find({_id：“chunksize”})默认大小为64MB，也可以参见这里），或者该块无法拆分，因为由该块表示的范围无法自动进一步拆分。您应该使用sh.status(true)命令检查范围（您发布的大量输出中某些集合的范围被省略）然后您可以手动拆分块。此外，在dba论坛上也有一个很好的答案。

分片键

如果你没有未分片的集合，问题可能是分片键本身。Mongo建议使用具有高基数和高度随机性的分片键。不知道你列的值范围，我假设基数相对较低（即1000列），与时间戳（每个条目为1，形成许多不同的值）相比较低。
此外，数据应该均匀分布。所以假设你有10个可能的列。但是有很多更多的条目具有特定值的列名，所有这些条目都将被写入同一个分片中。例如：
- entries.count（{column：“A”} = 10-> shard 0 - entries.count（{column：“B”} = 10-> shard 1 - ... - entries.count（{column：“F”} = 100-> shard 5 sh.status()命令应该为你提供一些有关块的信息。

如果您使用对象 ID 或时间戳 - 这些值是单调递增的值 - 将导致数据被写入同一块中。因此，Mongo 建议使用复合键，这将导致更高的基数（字段1 的值范围 x 字段2 的值范围）。在您的情况下，您可以将列名与时间戳结合起来。

但无论如何，对于您当前的安装来说，您都没有运气，因为您无法之后更改 Shard 键。

数据库设计

您打印的冗长输出还表明，您有几个具有相同模式或目的的 DB/collection，我认为它们有点手动分区。是否有特殊原因呢？这也可能会影响群集中数据的分布，因为每个 collection 开始在主节点上填充。至少有一个 collection 在主节点上只有一个 chunk，在总共有 3 或 4 个 chunk 的一些 collection 上都至少有一个 chunk （即 z_best_times_*）。 最好为一个目的只使用一个 collection，并可能使用复合 shard 键 (例如，加入散列时间戳)。

我有一个带有自增列（“y”）的“x”集合，并且我已经按以下方式应用了分片键：sh.shardCollection（“x”，{y：“hashed”}）。由于我的键是散列的，因此我的shard_5仍然显示了120万条目，而shard_1显示了20万条目（分布不均匀）。在这种情况下，您会推荐什么？ - Avinash
2
很难在没有完整的sh.status()输出的情况下说出来，你所描述的情况恰好是“按照书本上的”，我猜你可能错过了其他东西，但是从给定的信息中很难确定。 - Gerald Mücke
1
@Avinash 我看你的负载已经平衡了。请记住，分发是按块而不是按文档进行的。 - Markus W Mahlberg
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接