MongoDB 6.0.3分片Sharding与平衡策略的变化_mongodb

速览

1、分片机制概述

2、平衡策略变化

3、迁移阈值与Chunk的变化

4、开启集合分片变化

5、集合分片查询变化

6、总结

分片机制概述

MongoDB 的分片是一种水平扩展技术，用于将大型数据集分割成更小的部分，分布在网络中的多个服务器（即分片）上，以提高性能和可扩展性。分片机制的核心是将数据块（chunks）分散到不同的分片上，以便实现负载均衡。

平衡策略变化

自MongoDB 6.0.3版本起，分片集群中数据的分布方式经历了显著变化：

  1. 数据范围代替数据块：在之前的版本中，数据是以固定大小的数据块（默认64MB或128MB）进行划分和管理的。然而，自6.0.3起，MongoDB转向了一种新的数据划分方式，即数据范围（ranges），这种划分方式更注重数据的实际大小而非数据块的数量。
  2. 平衡策略演变：在新版本中，平衡器（balancer）的工作原理从关注数据块的分布转向了关注数据范围的分布，以实现更均匀的数据分布。这意味着平衡器不再简单地在分片之间移动数据块，而是寻找数据分布的平衡，确保各分片上的数据量大致相等。
  3. 数据块分裂策略：在之前的版本中，数据块可能会根据预设的阈值自动分裂。但现在，数据块（或数据范围）的分裂仅发生在需要跨分片移动时，以减少不必要的分裂操作。
  4. 术语更新：为了反映这一变化，术语“数据块”（chunk）现在被“数据范围”（range）替代。
  5. 命令变更：moveRange 命令被引入，替代了原有的 .moveChunk 命令，以适应新的数据范围概念。
  6. 默认数据块大小：自MongoDB 5.2起，数据块的默认大小从64MB增加到了128MB，这有助于减少数据块的数量，简化管理。
  7. 分片集合启用简化：自MongoDB 6.0起，启用分片集合的操作变得更加简洁，不再需要显式地使用 enableSharding 命令。
  8. 碎片整理状态监控：自MongoDB 5.3起，通过 balancerCollectionStatus 命令，管理员可以获取关于正在进行的碎片整理过程的详细信息，包括当前的碎片整理阶段以及待处理的数据块数量。

迁移阈值与Chunk的变化

迁移阈值的变化

  • 迁移阈值：为了决定何时进行数据块迁移，MongoDB引入了一个新的阈值。在6.0.3版本之后，如果不同分片上的数据大小差异超过了384MB，即三倍于默认的Chunk大小（128MB），平衡器就会认为需要进行数据块的迁移。这比之前的版本中基于数据块数量的迁移策略更加注重实际的数据分布状况。

Chunk管理的变化

  • 自动分割策略：在之前的MongoDB版本中，当数据块（chunk）的大小接近或达到默认最大大小时，MongoDB会自动将其分割成更小的chunk，以保持数据分布的均匀性。然而，在MongoDB 6.0.3及更高版本中，数据块不再进行自动分割。数据块的分割仅在需要进行迁移时才会发生，以确保数据块的边界适合迁移操作，同时减少不必要的数据块分裂带来的开销。

开启集合分片变化

创建集合分片前无需对db执行enableSharding操作

集合分片查询变化

1、不再显示集合分片信息

> sh.status()
  • 1.

2、查询集合分片情况

下面的SQL将"MOnoDB"更换为所需要查询的DB名称即可
var dbName = "MOnoDB";
db.getSiblingDB(dbName).getCollectionNames().forEach(function(collName) {
  print("————————————————————————");
  print("Collection: " + collName);
  db.getSiblingDB(dbName).getCollection(collName).getShardDistribution();
});
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.

3、无需关注之前的chunk数据块，只需关注集合的大小

Collection: prom_report
Shard d-88888894 at mgset-78435829/21.0.0.37:3000,21.0.0.39:3000


 data : 1.78GiB docs : 1526137 chunks : 0
 estimated data per chunk : InfinityGiB
 estimated docs per chunk : Infinity


Shard d-2ze567564 at mgset-78435832/21.0.0.42:3000,21.0.0.45:3000


 data : 1.84GiB docs : 1536972 chunks : 0
 estimated data per chunk : InfinityGiB
 estimated docs per chunk : Infinity


Shard d-2z5756704 at mgset-78435831/21.0.0.46:3000,21.0.0.48:3000


 data : 2.37GiB docs : 2128734 chunks : 0
 estimated data per chunk : InfinityGiB
 estimated docs per chunk : Infinity


Totals
 data : 6GiB docs : 5191843 chunks : 0
 Shard d-88888894contains 29.7% data, 29.39% docs in cluster, avg obj size on shard : 1KiB
 Shard d-2ze567564 contains 30.78% data, 29.6% docs in cluster, avg obj size on shard : 1KiB
 Shard d-2z5756704 contains 39.5% data, 41% docs in cluster, avg obj size on shard : 1KiB
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
  • 15.
  • 16.
  • 17.
  • 18.
  • 19.
  • 20.
  • 21.
  • 22.
  • 23.
  • 24.
  • 25.
  • 26.
  • 27.
  • 28.
  • 29.
  • 30.

总结

这些变化反映了MongoDB在分片机制上的持续优化，目的是为了提供更高效、更平衡的数据分布，减少不必要的数据块分裂，简化集群管理，同时增强数据分布的均匀性和性能。通过关注数据范围而非数据块，MongoDB的分片机制变得更加智能和灵活，有助于提高大规模数据集的处理能力和可扩展性。