MongoDB 分片集群

引言

随着企业应用产生的数据规模从 TB 级跨越到 PB 级，单台服务器的磁盘容量和 I/O 读写性能很快就会触及物理天花板。作为最流行的面向文档的 NoSQL 数据库，MongoDB 提供了原生的“分片集群（Sharded Cluster）”机制，实现了真正意义上的无缝水平扩展。

一个完整的 MongoDB 分片集群由以下三部分组成：

用于实际存储数据的物理节点。在生产环境中，每个分片本身都应该是一个副本集（Replica Set），以保障高可用性和数据自动容灾。

存储整个集群的元数据和路由规则，包括哪个数据区间（Chunk）存放在哪个具体的分片上。它同样必须配置为副本集，保证配置信息的强一致性。

作为客户端访问的唯一入口。客户端无需知道数据存储在哪个具体的分片。mongos 收到读写请求后，先去 Config Servers 获取最新的数据映射关系，然后将请求精准路由到对应的分片，最后将数据汇总返回给客户端。

分片键（Shard Key）直接决定了数据分布的均匀程度。一个糟糕的分片键会导致绝大多数流量集中在某一个分片上，产生“热点写（Hotspot Write）”现象：

如果使用时间戳或自增 ID 作为分片键，所有新插入的数据都会因为区间上限的不断递增而落在最后一个 Chunk 中，最终全部被写入同一个分片，完全失去了水平分摊写入压力的意义。

通过计算分片键值的 MD5 哈希来分配数据。它可以让具有相似属性的数据极度均匀地随机打散在所有分片上，非常适合写密集型的业务系统。

sh.shardCollection("mydb.users", { "user_id": "hashed" })

但哈希分片的缺点在于不适合范围查询，因为连续的数据被分散在不同的节点上，范围查询不得不调用所有分片进行数据搜集（Scatter-Gather）。

引言

分片集群的核心架构组件

一个完整的 MongoDB 分片集群由以下三部分组成：

1. Shards (分片存储节点)

用于实际存储数据的物理节点。在生产环境中，每个分片本身都应该是一个副本集（Replica Set），以保障高可用性和数据自动容灾。

2. Config Servers (配置服务器)

存储整个集群的元数据和路由规则，包括哪个数据区间（Chunk）存放在哪个具体的分片上。它同样必须配置为副本集，保证配置信息的强一致性。

3. Mongos (路由服务器)

分片键的选择与 Chunk 分裂

分片键（Shard Key）直接决定了数据分布的均匀程度。一个糟糕的分片键会导致绝大多数流量集中在某一个分片上，产生“热点写（Hotspot Write）”现象：

递增属性（如 ObjectId、时间戳）的弊端

哈希分片 (Hash Sharding)

通过计算分片键值的 MD5 哈希来分配数据。它可以让具有相似属性的数据极度均匀地随机打散在所有分片上，非常适合写密集型的业务系统。

sh.shardCollection("mydb.users", { "user_id": "hashed" })

但哈希分片的缺点在于不适合范围查询，因为连续的数据被分散在不同的节点上，范围查询不得不调用所有分片进行数据搜集（Scatter-Gather）。