MongoDB 分片
高数据量(消耗内存)和高吞吐量(消耗CPU)的数据库应用会对单机的性能造成较大压力,为了解决这些问题,一般采用两种方法:水平扩展(将数据集分布在多个服务器上)和垂直扩展(增加更多的CPU和存储资源)。
当MongoDB存储海量数据时,一台机器可能不足以存储数据,也可能不足以提供可接受的读写吞吐量。这时,我们可以通过分割数据,使得数据分布在多个服务器上。
1. 分片集群架构
- Config Server:存储集群所有节点、分片数据数据信息等元数据信息,默认需要配置3个Config Server节点;
- Mongos:专用路由进程,提供对外应用访问,将客户端发来的请求准确无误的路由到集群中的一个或一组服务器上,同时会把接收到的响应拼装起来发回客户端;
- Shard:存储数据,以chunk为单位存储数据;
1.1 Chunk
在Shard内部,MongoDB还会把数据分为chunks,每个chunk包含shard的一部分数据,chunk的产生有两个用途:
- Splitting:当chunk的大小超过配置的chunk size(默认为64M)时,MongoDB的后台进程会把这个chunk切分成更小的chunk;
- Balancing:balancer时一个后台进程,负责chunk的迁移,从而均衡各个shard的负载;
chunk size的选择:小的chunk size数据均衡时迁移速度快,数据分布更均匀,但数据分裂频繁,路由节点消耗更多资源;大的chunk size数据分裂少,但数据块迁移消耗IO资源大,通常选择100M~200M;
2. 数据区分
2.1 分片键 shard key
MongoDB中的数据分片是以集合为基本单位的,集合中的数据通过shard key被分成多个部分。其实shard key就是在集合中选一个键,用该键作为数据拆分的依据。
注意:
- shard key是不可变的;
- shard key必须有索引;
- shard key大小限制512bytes;
- shard key用于路由查询;
2.2 以范围为基础的分片 Sharded Cluster
Sharded Cluster支持将单个集合的数据分散存储到多个shard上,用户可以指定根据集合内文档的某个字段(shard key)来进行范围分片。
在使用shard key做范围划分的系统中,拥有”相近”shard key的文档很可能存储在同一个数据块中,因此也会存储在同一个分片中。
2.3 基于哈希的分片
对于基于哈希的分片,MongoDB计算一个字段的哈希值,并用这个哈希值来创建数据块。在使用基于哈希分片的系统中,拥有”相近”shard key的文档很可能不会存储在同一个数据块中,因此数据的分离性更好一些。