MongoDB 学习笔记：Sharded Cluster

本文目录

1 整体架构

2 Shard Key

3 Chunk

---

1 整体架构

1.1 Shard

Shard用于存储用户数据，每个Shard存储用户数据中的一部分。

当数据量超过Shard整体容量时，可以动态增加Shard节点，从而动态扩展数据容量。

每个Shard节点部署在一台服务器上，每台服务器上可能部署了多个Shard节点。

1.2 Router（Mongos）

Router（Mongos）是Sharded Cluster的访问入口，使得集群内部对外透明。

Router本身不存储数据，而是用于请求的路由，将请求分发至相应的Shard节点。

元数据将存储到Config Server，而用户数据将存储到各Shard中。

1.3 Config Server

Config Server用于存储原数据和集群配置。

2 Shard Key

Shard Key（片键）由文档中的一个或多个字段组成，Shard Key 中的字段必须是某个索引的前缀，即至少需要创建一个索引，且该索引以 Shard Key 作为前缀字段，或该索引仅包含Shard Key字段。

MongoDB会根据数据的Shard Key对数据进行一个范围划分，每一个范围内的数据对应一个Chunk。

从而决定该文档应该存储在哪一个Shard上，最终决定该文档应该存储在哪一个机器上。

2.1 Sharding Strategy（分片策略）

MongoDB 支持两种分片策略：Ranged Sharding（范围分片） 和 Hashed Sharding（哈希分片）

Ranged Sharding 就是基于 Shard Key 值进行范围划分；

Hashed Sharding 则是将 Shard Key 先进行一次 Hash 操作，得到一个 Hash 值，然后基于该 Hash 值进行范围划分。

2.2 Shard Key 的设计

原则：

（1）尽量让数据均匀分布在各Chunk中，从而均匀分布在各Shard中，减少Chunk拆分和迁移的可能性。

（2）尽量保证范围查询可以落在较少的Shard中，以避免Scatter/Gather操作，提升性能。

例如：当希望以用户ID（一组递增数字）作为Shard Key。

但由于用户ID是递增数字，导致新用户的数据总是落在最后一个Chunk中，进而可能导致不断拆分和迁移后面的Chunk数据。

因此，在设计Shard Key的时候，可以创建一个单独的字段SK，该字段内容如下（+号标识连接）：

SK = 1 + 用户ID最后一位 + 用户ID

即，当用户ID为10055123时，SK值为1310055123。

这时，新增用户的SK值前两位将从10-19依次变化，相当于将用户ID分成了10个大组，分别对应不同的Chunk，起到了分散数据的作用。即满足（1）的要求。

当经常通过用户ID查询某用户的数据。上述设计也可以保证相同用户的数据会保存在同一个Chunk中，即保证了相同的用户数据会保存在同一个Shard中。当请求某个用户的数据时，查询会被路由至相应的Shard执行，而不会让所有Shard都查询是否有该用户数据，然后再汇集返回给调用者。即满足（2）的要求。

3 Chunk

MongoDB会根据Shard Key将数据对应保存在不同Chunk上，每个Chunk保存一部分数据。

每个Chunk有一定容量上限，当Chunk内数据超过该上限，该Chunk将会被拆分成两个Chunk，拆分后的Chunk将对应更小范围的Shard Key值。

当某个Chunk仅对应一个Shard Key时，将无法被拆分，即每个Chunk以Shard Key作为最小单位，进行数据的保存。

每个Chunk属于一个Shard，每个Shard包含一个或多个Chunk。

当各Shard上的数据量不均衡时，超过某个阈值，将会引发Chunk的迁移操作，数据量过多的Shard中的部分数据，将会以Chunk为单位，迁移至其它Shard中，以达到各Shard相对均衡的状态。

当Shard Key设计完成后，有时，需要根据Shard Key对Chunk进行预设。

从而，在初始阶段，就将Chunk进行了初始拆分，且确定了每个Chunk的边界，以减少前期频繁的Chunk拆分及迁移。