MongoDB 8.0——分片

1、分片基础

1.1、分片介绍

MongoDB数据库分片就是将数据分成块，再将块存储到不同的服务器上，其实是一种分布式存储数据的方法。如果数据库系统存在大型数据集或高吞吐量应用程序的情形，可能会对单个服务器的容量构成挑战。

例如，较高的查询速率可能会耗尽服务器的CPU容量。大于系统RAM的工作集大小会对磁盘驱动器的I/O容量造成压力。因此，有两种方法可以解决系统扩展的问题，分别是垂直扩展(Vertical Scaling)和水平扩展(HorizontalScaling)。

1.1.1、垂直扩展

涉及增大单个服务器的容量，例如使用更强大的CPU、添加更多RAM或增加存储空间量。可用技术所存在的限制可能会导致单个机器对于给定工作负载来说不够强大。因此，垂直扩展存在实际的最大值。

1.1.2、水平扩展

涉及将系统数据集和负载划分到多个服务器，以及按需增加服务器以提高容量。虽然单个机器的总体速度或容量可能不高，但每个机器均可处理总体工作负载的一部分，因此可能会比单个高速、高容量服务器提供更高的效率。扩展部署的容量只需按需添加额外的服务器，而且这可能会比添加单个机器的高端硬件整体成本更低，但这种做法的代价在于会增大部署的基础设施与维护的复杂性。

对于MongoDB数据库而言，支持通过分片进行水平扩展。

1.2、分片键介绍

MongoDB数据库使用分片键在分片之间分发集合的文档，分片键由文档中的一个或多个字段组成，分片集合中的文档可能缺少分片键字段。当跨分片分发文档时，缺少的分片键字段时将被视为null值，但在路由查询时则不会。

MongoDB在对集合进行分片时会选择分片键。从MongoDB 5.0版本开始，就可以通过更改集合的分片键对集合重新分片。此外，还可以通过向现有分片键添加后缀字段或添加新字段来优化分片键。文档的分片键值决定了其在各分片中的分布。我们可以更新文档的分片键值，除非分片键字段是不可变的_id字段。

分片键索引用于对已填充的集合进行分片，该集合必须具有以分片键开头的索引。对空集合进行分片时，如果该集合还没有指定分片键的适当索引，MongoDB数据库会创建支持索引。

分片键策略对于分片键的选择会影响分片集群的性能、效率和可扩展性。具有最佳硬件和基础架构的集群，可能会因为选择分片键而遇到瓶颈，分片键及其后备索引的选择也会影响集群可以使用的分片策略。

MongoDB数据库将数据分片为数据段，每个数据段都有一个基于分片键、包含下限且不包含上限的范围。为了实现数据在集群中所有分片上的均匀分布，负载均衡器会在后台运行，以便在各分片之间迁移范围。

1.3、分片的优点

MongoDB数据库分片具有如下几项优点。

1.3.1、读取/写入优点

MongoDB在分片集群中的分片之间分配读写工作负载，支持每个分片处理集群操作的子集。通过添加更多的分片，读写工作负载都可以在集群中横向扩展。

对于包含分片键或复合分片键前缀的查询，mongos可将查询定向到特定分片或一组分片。这些有针对性的操作通常比向集群中的每个分片进行广播更为有效。

1.3.2、存储容量优点

分片将数据分布在集群中的分片上，从而允许每个分片包含整个集群数据的子集。随着数据集的增长，更多的分片会增加集群的存储容量。

1.3.3、高可用性优点

按副本集来部署配置服务器和分片，可提高可用性。即使一个或多个分片副本集变为完全不可用，分片集群仍可继续执行部分读取和写入操作。换言之，即便无法访问不可用分片上的数据，针对可用分片的读取或写入仍可成功完成。

2、分片集群

2.1、分片集群的组成

MongoDB分片集群由以下组件构成。

• 分片：每个分片都包含分片数据的一个子集。每个分片都必须作为一个副本集进行部署。
• mongos：mongos充当查询路由器，在客户端应用程序和分片集群之间提供接口。
• 配置服务器：配置服务器会存储集群的元数据和配置设置。配置服务器必须以副本集(CSRS)的形式部署。

关于分片集群内各组件之间的交互原理，具体描述如图所示。

MongoDB数据库在集合级别对数据进行分片，从而将集合数据分布到集群中的分片上。

2.2、生产配置

在MongoDB分片集群中，确保数据冗余和系统高可用性是生产环境的关键要求。对于生产分片集群的部署，可考虑以下事项：

• 将配置服务器部署为3节点副本集。
• 将每个分片部署为3成员副本集。
• 部署一个或多个mongos路由器。

对于副本集分布而言，如果有可能，可以考虑将每个副本集的一个成员部署在适合作为灾难恢复位置的站点中。注意，将副本集成员分布在两个数据中心，比分布在一个数据中心更有优势。当成员分布在两个数据中心时，如果其中一个数据中心发生故障，数据仍可供读取；而如果所有成员都位于单个数据中心，则无法实现此功能。如果具有少数成员的数据中心出现故障，副本集仍然可以支持写入操作和读取操作。但是，如果具有大多数成员的数据中心出现故障，副本集将变为只读。

如果有可能，可将成员分布在至少3个数据中心。对于配置服务器副本集(CSRS)，最佳实践是分布在3个数据中心（也可根据成员数量来增加数据中心数量）​。如果使用第3个数据中心的成本过高，一种可行的分布方法是在两个数据中心均匀分配数据承载成员，并将剩余成员存储在云中。

对于分片数量而言，分片集群需要至少两个分片来分发分片数据。如果计划日后启用分片，但在部署时又不需要启用，那么单个分片的分片集群可能会很有用。基于mongos的数量和分布，mongos路由器在部署多个mongos实例时支持高可用性和可扩展性。

如果代理或负载均衡器位于应用程序和mongos路由器之间，则必须为其配置客户端关联性。客户端关联性允许来自一个客户端的每个连接到达同一个mongos。要实现分片级别的高可用性，可以在已运行mongos实例的同一硬件上添加mongos实例，在应用程序级嵌入mongos路由器。mongos路由器会与配置服务器频繁通信。随着路由器数量的增加，性能可能会下降。如果性能下降，可减少路由器的数量。另外，最多只能部署30个mongos路由器。

在生产配置中，常用的分片集群架构如图所示。

2.3、开发配置

MongoDB数据库分片集群为了进行测试和开发，可以部署具有最少数量组件的分片集群。一般来讲，这些非生产集群具有以下组件：

• 一个mongos实例。
• 单个分片副本集。
• 副本集配置服务器。

下图展示了仅用于开发目的的分片集群架构。

3、分片键的应用

3.1、分片键索引

MongoDB分片键可以是单个索引字段，也可以是复合索引涵盖的多个字段，复合索引决定了集合文档在集群分片中的分布。

MongoDB将分片键值（或哈希分片键值）的取值区间划分为不重叠的分片键值（或哈希分片键值）范围。每个分片键值范围都与一个数据块相关联，MongoDB会尝试在集群中的各个分片之间均匀分配这些数据块。分片键与数据段分发的有效性有直接关系。

MongoDB中的所有分片集合都必须具有支持分片键的索引。索引可以是分片键上的索引，也可以是复合索引，其中分片键是索引的前缀。如果集合为空，则sh.shardCollection()会在分片键上创建索引（如果此类索引尚不存在）​。如果集合不为空，则必须先创建索引，然后才能使用sh.shardCollection()。如果索引是唯一支持分片键的非隐藏索引，则无法将其删除或隐藏。

MongoDB可以对分片键值范围内的分片键索引执行唯一性约束。通过在分片键上使用唯一索引，MongoDB将确保整个键的组合的唯一性，而不是分片键的各个组成部分。对于分片键值范围内的分片集合，只有以下索引是唯一的：

• 分片键上的索引。
• 一个复合索引，其中分片键是前缀。
• 默认_id索引。

只有当_id字段也是分片键时，分片集群才会在整个集群中对_id字段执行唯一性约束。如果_id字段不是分片键，或者只是分片键的前缀，则唯一性约束只适用于存储文档的分片。这意味着两个或多个文档可以具有相同的_id值，前提是其出现在不同的分片上。如果_id字段不是分片键，MongoDB希望应用程序确保所有分片上_id值的唯一性。

如果是唯一索引约束，则意味着以下几点：

• 对于即将被分片的集合，如果该集合还有其他的唯一索引，则无法对其进行分片。
• 对于已分片的集合，无法在其他字段上创建唯一索引。
• 唯一索引为缺少索引字段的文档存储空值，即缺少的索引字段将被视为null索引键值的另一个实例。

要确保分片键值的唯一性，需要将unique参数设置为true值传递给sh.shardCollection()方法，详细说明如下：

• 如果集合为空，sh.shardCollection()会在分片键上创建唯一索引（条件是这种索引尚不存在）​。
• 如果集合不为空，则必须先创建索引，然后才能使用sh.shardCollection()。

尽管可以有以分片键为前缀的唯一复合索引，但如果使用unique参数，则集合必须在分片键上有唯一索引。另外，不能在哈希索引上指定唯一约束。

3.2、将集合分片

MongoDB必须指定要进行分片的集合的完整命名空间和分片键，才能对其进行分片。我们可以使用mongosh方法sh.shardCollection()对集合进行分片，具体代码如下：

sh.shardCollection(<namespace>, <key>)

• 第1个参数namespace指定设计人员想要对其进行分片的集合的完整命名空间("<database>.<collection>")。
• 第2个参数key指定文档{<shard key field1>: <1|"hashed">, ...}，其中1表示基于范围的分片，"hashed"表示哈希分片。

关于分片键字段与字段值，具体描述如下。

• 缺少的分片键字段：分片集合中的文档可能缺少分片键字段。缺失的分片键与值为null的分片键属于同一范围。
• 更改文档的分区密钥值：可以更新文档的分片键值，除非分片键字段是不可变的_id字段。
• 更改集合的分片键：从MongoDB 5.0版本开始，可以通过更改文档的分片键对集合重新分片。设计人员可以通过向现有分片键添加后缀字段来优化分片键。

3.3、选择分片键

MongoDB分片键的选择会影响数据段的创建和在可用分片间的分配。数据的分布会影响分片集群内操作的效率和性能。理想的分片键可以让MongoDB在整个集群中均匀地分发文档，同时也有利于实施常见的查询模式。

在选择分片键时，需要考虑以下几点：

• 分片键的关联基数。
• 分片键值出现的频率。
• 潜在的分片键是否单调递增。
• 分片查询模式。
• 分片键限制。

如果定期更改文档的分片键值，以使该值位于不同分片拥有的分片键范围，则可能会影响集群性能，因为在分片之间迁移文档会涉及额外的资源。

分片键的关联基数决定了负载均衡器可以创建的最大数据段数。尽可能选择关联基数高的分片键。关联基数低的分片键会降低集群中水平扩展的有效性。在任何给定时间，每个唯一的分片键值只能存在于一个数据段上。

现在考虑一个数据集，其包含带有continent字段的用户数据。如果选择在continent上进行分片，则分片键的关联基数将为7。关联基数为7意味着分片集群内的数据段不能超过7个，每个数据段存储一个唯一的分片键值。这也会将集群中的有效分片数限制为7，即添加7个以上的分片不会带来任何好处。

下图展示了使用字段X作为分片键的分片集群。如果X的关联基数较低，则插入操作的分布情况会是图中展示的这样。

如果数据模型要求在关联基数较低的键上进行分片，可考虑使用字段的复合索引来增加关联基数。关联基数低的分片键本身并不保证数据在分片集群中均匀分布。分片键的频率以及单调变化的分片键值的深度也有助于数据的分布。

分片键频率表示给定分片键值在数据中出现的频率。如果多数文档仅包含可能的分片键值的一部分，则存储具有这些值的文档的数据段可能会成为集群内的瓶颈。此外，随着这些数据段的增长，它们可能会成为不可分割的数据段，因为它们无法被进一步分割。这会降低集群内横向扩展的有效性。

下图演示了使用字段X作为分片键的分片集群。如果X的子集值出现频率较高，则插入操作的分布情况会是图中展示的这样，字段X的子集值(12)会集中在一个分片上。

如果数据模型要求在具有高频值的键上进行分片，可以考虑使用唯一或低频率值的复合索引。低频率的分片键本身并不保证数据在分片集群中均匀分布。分片键的关联基数以及单调变化的分片键值的潜力也有助于数据的分布。

关于单调变化的分片键内容，针对单调增加或减少的值的分片键，更有可能将插入操作分布到集群内的单个数据段中。之所以发生这种情况，是因为每个集群都有一个捕获范围上限为maxKey的数据段，maxKey始终是所有值中最高的值。同样，还有一个捕获范围下限为minKey的数据段，minKey始终是所有值中最低的值。

如果分片键值总是增加的，则所有新的插入操作都会路由到以maxKey为上限的数据段。如果分片键值总是减少的，则所有新的插入操作都会路由到以minKey为下限的数据段。包含该上下限数据段的分片会成为写入操作的瓶颈。

为优化数据分布，包含全局maxKey（或minKey）的数据段不会位于同一分片。在分割数据段时，具有maxKey（或minKey）数据段的新数据段会位于不同的分片。

下图演示了使用字段X作为分片键的分片集群。如果X的值单调递增，则插入操作的分布情况可能会是图中展示的这样，字段X的子集值（在大于或等于20上单调递增）会集中在一个分片上。

如果分片键值单调递减，则所有插入操作都将改为路由到Chunk A。如果数据模型需要对单调变化的键进行分片，可以考虑使用哈希分片。对于不产生单调变化的分片键，本身并不保证数据在分片集群中均匀分布。分片键的关联基数和频率也有助于数据的分布。

关于分片查询模式的使用，理想的分片键可将数据均匀地分布在分片集群中，同时也有利于实施常见的查询模式。在选择分片键时，可考虑最常使用的查询模式以及给定分片键能否涵盖这些模式。

在分片集群中，如果查询包含分片键，则mongos仅会将这些查询路由到包含相关数据的分片。如果查询不包含分片键，则这些查询会被广播到所有分片以进行评估。这些类型的查询称为“分散-聚合”查询。每个请求涉及多个分片的查询效率较低，并且向集群添加更多分片时无法实现线性扩展。

这不适用于针对大量数据进行操作的聚合查询。在这些情况下，​“分散-聚合”查询可能是一种有用的方法，因为它允许查询在所有分片上并行运行。

3.4、更改分片键

在MongoDB数据库中，理想的分片键可以让MongoDB在整个集群中均匀地分发文档，同时也有利于实施常见的查询模式。另外，不理想的分片键会导致数据分布不均匀，并产生以下问题：

• 巨型数据块。
• 负载分布不均。
• 查询性能随时间推移下降。

为了解决上述这些问题，MongoDB支持变更分片键：

• 从MongoDB 5.0版本开始，可以通过更改集合的分片键对集合重新分片。
• 可以通过向现有分片键添加后缀字段来优化分片键。

在对数据集进行重新分片时，数据分布修复最为有效。如果想改进数据分布，并且集群满足重新分片的条件，则应该将集合重新分片，而不是优化分片键。如果集群不符合重新分片的条件，则应优化分片键。

优化集合的分片键可以实现更细粒度的数据分布，并且可以解决现有键由于关联基数不足而导致巨型数据块的问题。

注意，不要修改任何当前分片键字段的范围或哈希类型，这会导致数据不一致。例如，请勿将分片密钥从{customer_id: 1}修改为{customer_id: “hashed”,order_id: 1}。从MongoDB 5.0版本开始，可以通过为集合提供新的分片键来对集合重新分片。

如果要优化集合的分片键，可以使用refineCollectionShardKey命令。refineCollectionShardKey会向现有键添加一个或多个后缀字段以创建新的分片键。例如，在一个test数据库中有一个orders集合，其分片键为{customer_id: 1}，可以使用refineCollectionShardKey命令将分片键更改为新的分片键{customer_id: 1, order_id: 1}，具体代码如下：

3.5、对集合重新分片

在MongoDB数据库中，理想的分片键可以让MongoDB在整个集群中均匀地分发文档，同时也有利于实施常见的查询模式。而如果由于数据分配不平均，不太理想的分片键可能会导致性能或扩展问题。

从MongoDB 5.0版本开始，可以通过更改集合的分片键来更改集群中的数据分配情况。从MongoDB 7.2版本开始，可以使用相同的分片键对集合进行重新分片，从而允许在不更改分片键的情况下重新分发数据以包含新分片或不同区域。

3.5.1、重新分片之前需要满足的要求

在对集合进行重新分片之前，请确保满足以下要求：

• 应用程序允许受影响的集合块进行两秒钟的写入。在写入受阻期间，应用程序的延迟会增加。如果工作负载无法满足此要求，可考虑优化分片键。
• 数据库符合以下资源要求：

确保每个分片上的可用存储空间至少是重新分片的集合大小及其总索引的集合大小的两倍，再除以分片数量。

storage_req = （ ( collection_storage_size + index_size ) * 2 ） / shard_count

例如，假设一个集合包含2TB数据，并具有分布在4个分片上的400GB索引。要对此集合执行重新分片操作，每个分片都需要1.2TB的可用存储空间。

1.2 TB storage = （ ( 2 TB collection + 0.4 TB index ) * 2 ） / 4 shards

为了满足存储要求，可能需要在重新分片操作期间升级到下一个存储层。操作完成后，可以缩减规模。

确保I/O容量低于50%。

确保CPU负载低于80%。

• 必须重写应用程序的查询，才能同时使用当前分片键和新的分片键。如果应用程序可以容忍停机，则可以执行以下步骤来避免重写应用程序的查询，从而同时使用当前分片键和新的分片键：

停止应用程序。

重写应用程序以使用新的分片键。

等待重新分片完成。要监控重新分片进程，可以使用$currentOp管道阶段。

部署重写的应用程序。

• 如果没有正在运行的索引被创建，使用db.currentOp()检查是否有任何正在运行的索引被创建，具体代码如下：
  
  在结果文档中，如果inprog字段值为空数组，则表示没有正在运行的索引被创建，具体代码如下：
  
  注意：重新分片是一个密集型写入操作，会显著提高操作日志的生成速率。为了避免操作日志无限增长，建议设置固定的操作日志大小，并适当增加操作日志的大小，以最大程度减少一个或多个从节点因操作日志溢出而过时的可能性。

在集合重新分片操作中，分片可以是发送分片，也可以是接收分片。发送分片是指当前存储分片集合数据段的分片，而接收分片是指根据分片键和区域存储分片集合新数据段的分片。分片可以同时作为发送分片和接收分片。除非使用区域划分，否则发送分片和接收分片是相同的。

3.5.2、重新分片的操作步骤

配置服务器的主节点始终担任重新分片协调器的角色，并负责启动重新分片操作的每个阶段。重新分片的具体步骤如下。

步骤1：开始重新分片操作。

连接到mongos时，发出reshardCollection命令，指定要重新分片的集合和新分片键，具体代码如下：

MongoDB将阻止写入的最大秒数设置为两秒，并且重新开始分片操作。

步骤2：监控重新分片操作。

要监控重新分片操作，可以使用$currentOp管道阶段，具体代码如下：

注意，想要查看更新的值，需要连续运行前面的管道。

步骤3：完成重新分片操作。

在整个重新分片进程中，完成重新分片操作的预计时间(remainingOperationTimeEstimatedSecs)会减少。当估计时间低于两秒时，MongoDB会阻止写入并完成重新分片操作。在完成重新分片操作的估计时间低于两秒之前，重新分片操作默认不会阻止写入。在写入受阻期间，应用程序的延迟会增加。重新分片进程完成后，重新分片命令会返回ok: 1，具体代码如下：

如果要查看重新分片操作是否成功完成，需要检查sh.status()方法的输出，具体代码如下：

sh.status()

sh.status()方法的输出包含小部分数据库。如果重新分片成功完成，则输出会列出集合的新分片键值，具体代码如下：

如果重新分片的集合使用Atlas Search，则在重新分片操作完成后，搜索索引变得不可用。重新分片操作完成后，需要手动重新生成索引。