Sharding
在本页面
Sharding是一种用于在多台计算机之间分配数据的方法。 MongoDB 使用分片来支持具有非常大的数据集和高吞吐量操作的部署。
具有大数据集或高吞吐量应用程序的数据库系统可能会挑战单个服务器的容量。例如，高查询率可能会耗尽服务器的 CPU 容量。大于系统 RAM 的工作集大小会增加磁盘驱动器的 I/O 容量。
解决系统增长的方法有两种：垂直缩放和水平缩放。
“垂直扩展”涉及增加单个服务器的容量，例如使用功能更强大的 CPU，添加更多 RAM 或增加存储空间量。可用技术的局限性可能会限制一台计算机对于给定的工作负载没有足够的功能。此外，基于云的提供程序具有基于可用硬件配置的严格上限。结果，垂直缩放有一个实际的最大值。
“水平扩展”涉及划分系统数据集并在多台服务器上加载，并添加其他服务器以根据需要增加容量。虽然单台计算机的整体速度或容量可能不高，但是每台计算机只能处理全部工作量的一部分，因此与单台高速大容量服务器相比，可能提供更高的效率。扩展部署的容量仅需要根据需要添加其他服务器，这可以比一台机器的高端硬件降低总体成本。折衷方案是增加基础结构和部署维护的复杂性。
MongoDB 通过sharding支持水平扩展。
Sharded Cluster
MongoDB sharded cluster由以下组件组成：
-
shard：每个分片都包含分片数据的子集。每个分片都可以部署为replica set。
-
mongos：
mongos充当查询 Router，在 Client 端应用程序和分片群集之间提供接口。 -
config servers：配置服务器存储集群的元数据和配置设置。从 MongoDB 3.4 开始，配置服务器必须部署为副本集(CSRS)。
下图描述了分片群集中组件的交互：
Shard Keys
要将文档分发到集合中，请使用shard key将 MongoDB partitions收集到集合中。 shard key由一个或多个不变字段组成，该字段存在于目标集合中的每个文档中。
在分片集合时选择分片键。分片后不能更改分片键的选择。分片集合只能有一个*分片密钥。参见分片密钥规范。
要对非空集合进行分片，该集合必须具有以分片键开头的index。对于空集合，如果集合尚不具有指定分片键的适当索引，则 MongoDB 将创建索引。参见分片索引。
分片密钥的选择会影响分片群集的性能，效率和可伸缩性。选择分片密钥可以使具有最佳硬件和基础结构的群集成为瓶颈。分片键及其后备索引的选择也会影响群集可以使用的sharding strategy。
Chunks
MongoDB 将分片的数据分区到chunks。每个块都有基于shard key的包含性下限和排除性上限范围。
MongoDB 使用分片集群平衡器在sharded cluster中的shards上迁移chunks。平衡器尝试在集群中的所有分片上实现均匀的块平衡。
有关更多信息，请参见使用块进行数据分区。
分片的优点
读/写
MongoDB 在sharded cluster中的shards之间分配读写工作负载，从而允许每个分片处理集群操作的子集。通过添加更多分片，可以在集群中水平扩展读写工作负载。
对于包含分片键或compound分片键的前缀的查询，mongos可以将查询定位到特定分片或分片集。对于集群中的每个分片，这些targeted operations通常比broadcasting更有效。
Storage Capacity
Sharding将数据分布在群集中的shards上，从而允许每个分片包含全部群集数据的子集。随着数据集的增长，其他分片将增加群集的存储容量。
High Availability
即使一个或多个分片不可用，sharded cluster仍可以 continue 执行部分读取/写入操作。尽管在停机期间无法访问不可用分片上的数据子集，但是针对可用分片的读取或写入仍然可以成功。
从 MongoDB 3.2 开始，您可以将config servers部署为replica sets。只要大多数副本集可用，具有 Config Server 副本集(CSRS)的分片群集就可以 continue 处理读取和写入。
在 3.4 版中，MongoDB 删除对 SCCC 配置服务器的支持。
在生产环境中，各个分片应部署为replica sets，以提高冗余性和可用性。
分片前的注意事项
分片式群集基础结构的要求和复杂性需要仔细计划，执行和维护。
为了确保群集的性能和效率，在选择分片密钥时需要仔细考虑。不能在分片后更改分片密钥，也不能对分片的集合进行分片。参见选择分片键。
分片具有某些操作要求和限制。有关更多信息，请参见分片群集中的操作限制。
如果查询“不”包含分片密钥或compound分片密钥的前缀，则mongos将执行broadcast operation，查询分片集群中的“所有”分片。这些分散/聚集查询可能是长时间运行的操作。
Note
如果您与 MongoDB 签订了有效的支持 Contract，请考虑与您的 Client 代表联系，以获取分片群集计划和部署方面的帮助。
分片和非分片集合
数据库可以包含分片和未分片集合的混合。分片的集合是partitioned，并且分布在群集中的shards上。未分片的集合存储在primary shard上。每个数据库都有其自己的主碎片。
连接到分片群集
您必须连接到mongosRouter 才能与sharded cluster中的任何集合进行交互。这包括分片的和未分片的集合。Client 端绝对不要连接到单个分片以执行读取或写入操作。
您可以以与连接mongod相同的方式连接到mongos，例如通过mongo shell 或 MongoDB driver。
Sharding Strategy
MongoDB 支持两种分片策略，用于在sharded clusters上分配数据。
Hashed Sharding
哈希分片涉及计算分片键字段值的哈希值。然后根据散列的分片键值为每个chunk分配一个范围。
Tip
使用哈希索引解析查询时，MongoDB 自动计算哈希值。应用程序不需要计算哈希。
尽管分片键范围可能是“接近”的，但它们的哈希值不太可能在相同的chunk上。基于散列值的数据分发有助于更均匀的数据分发，尤其是在分片键更改monotonically的数据集中。
但是，散列分布意味着对分片键进行基于范围的查询不太可能针对单个分片，从而导致整个集群范围内的broadcast operations
有关更多信息，请参见Hashed Sharding。
Ranged Sharding
远程分片涉及根据分片键值将数据划分为多个范围。然后，根据碎片键值为每个chunk分配一个范围。
值为“ close”的一系列分片键更有可能驻留在同一chunk上。这允许targeted operations，因为mongos可以将操作仅路由到包含所需数据的分片。
远程分片的效率取决于选择的分片密钥。分片密钥考虑不周全会导致数据分布不均，这可能会削弱分片的某些优势或导致性能瓶颈。有关远程分片，请参阅分片键选择。
有关更多信息，请参见Ranged Sharding。
分片群集中的区域
在分片群集中，您可以基于shard key创建zones的分片数据。您可以将每个区域与集群中的一个或多个分片关联。分片可以与任意数量的区域关联。在平衡群集中，MongoDB 仅将区域覆盖的chunks迁移到与该区域关联的分片。
每个区域覆盖一个或多个shard key值范围。区域覆盖的每个范围始终包括其下边界和上边界。
在定义要覆盖的区域的新范围时，必须使用shard key中包含的字段。如果使用compound分片键，则范围必须包含分片键的前缀。有关更多信息，请参见区域中的分片键。
选择分片密钥时，请仔细考虑将来使用区域分片的可能性，因为在对集合进行分片后无法更改分片密钥。
最常见的是，区域用于改善跨多个数据中心的分片群集的数据局部性。
有关更多信息，请参见zones。
分片中的排序规则
使用shardCollection命令和collation : { locale : "simple" }选项将具有default collation的集合分片。成功的分片需要：
-
集合必须具有前缀为分片键的索引
-
索引必须具有排序规则
{ locale: "simple" }
使用排序规则创建新集合时，在分片集合之前，请确保满足这些条件。
Note
分片集合上的查询 continue 使用为集合配置的默认排序规则。要使用分片索引的simple排序规则，请在查询的collation document中指定{locale : "simple"}。
有关分片和排序规则的更多信息，请参见shardCollection。