gpt4 book ai didi

MongoDB:其中一个分片不像其他分片那样平衡

转载 作者:可可西里 更新时间:2023-11-01 09:12:13 25 4
gpt4 key购买 nike

我的应用程序有一个分片集群设置,但不幸的是,其中一个分片占用了 17 GB 的数据大小,而其他分片平均占用了 3 GB 的数据大小。可能是什么问题?

10 shards

sh.status() 给了我巨大的输出。在这里共享:https://www.dropbox.com/s/qqsucbm6q9egbhf/shard.txt?dl=0

我的坏收藏分片分布详情如下。

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 多个类似的集合,其中我按 user_id 划分数据

e.g. MyCollection_1_100000
MyCollection_100001_200000
MyCollection_200001_300000

这里我在 MyCollection_1_100000 中划分了用户 ID 从 1 到 100000 的数据,对于其他集合也是如此

所有 150 多个集合的分片键都是序列号,但它是散列。通过以下方式申请

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

请建议我解决不平衡分片问题的纠正步骤。

最佳答案

未共享的集合

分片 5 是集群中的主要分片,这意味着它将采用所有未分片 集合,因此会变得更大。你应该检查一下。参见 here .

分块

正如 Markus 所指出的,分发是由 block 而不是文档完成的。 block 可能会增长到它们定义的 block 大小。当它们超过 block 大小时,它们将被拆分并重新分配。在您的情况下,似乎至少有一个集合比所有其他分片多了 1 个 block 。原因可能是 block 尚未达到其 block 限制(检查 db.settings.find( { _id:"chunksize"}) 默认大小为 64MB,另请参见 here )或chunk 无法拆分,因为chunk 所代表的范围无法自动进一步拆分。您应该使用 sh.status(true) 命令检查范围(对于您发布的大输出中的某些集合,省略了范围的输出)但是你可以split the chunk manually .dba forum 上也有很好的答案.

分片键

如果您没有未分片的集合,问题可能出在分片键本身。蒙戈suggest使用具有高基数和高度随机性的分片键。在不知道您的列的值范围的情况下,我假设基数相当低(即 1000 列),比方说时间戳(每个条目 1,构成很多不同的值)。

此外,数据应该均匀分布。因此,假设您有 10 个可能的列。但是有更多的条目具有列名称的特定值,所有这些条目都将写入同一个分片。例如

  • entries.count({column: "A"} = 10 -> 分片 0
  • entries.count({column: "B"} = 10 -> 分片 1
  • ...
  • entries.count({column: "F"} = 100 -> 分片 5

sh.status() 命令应该为您提供有关 block 的更多信息。

如果您使用对象 ID 或时间戳——它们是单调递增的值——将导致数据也被写入同一 block 。所以 Mongo 建议使用复合键,这将导致更高的基数(字段 1 的值范围 x 字段 2 的值范围)。在您的情况下,您可以将列名与时间戳结合起来。

但无论哪种方式,您当前的安装都不走运,因为您不能change the shard key afterwards .

数据库设计

您打印的详细输出还表明,您有多个数据库/集合具有相同的模式或目的,我认为它们是手动分区的。这有什么特别的原因吗?这可能会影响集群中数据的分布以及每个收集开始时在主节点上的填充。至少有一个集合在主节点上只有一个 block ,有些集合总共有 3 或 4 个 block ,所有主节点上都至少有一个 block (即 z_best_times_*)。最好你应该只有一个集合用于一个目的,并且可能使用复合分片键(即另外的哈希时间戳)。

关于MongoDB:其中一个分片不像其他分片那样平衡,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/36338298/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com