mongodb 集群shard_MongoDB分片集群

一、分片集群介绍

（一）、分片的目的

　高数据量和吞吐量的数据库应用会对单机的性能造成较大压力,大的查询量会将单机的CPU耗尽,大的数据量对单机的存储压力较大,最终会耗尽系统的内存而将压力转移到磁盘IO上

为了解决这些问题,有两个基本的方法: 垂直扩展和水平扩展。

垂直扩展

增加更多的CPU和存储资源来扩展容量。

水平扩展

将数据集分布在多个服务器上。水平扩展即分片。

（二）、分片设计思想

分片为应对高吞吐量与大数据量提供了方法。使用分片减少了每个分片需要处理的请求数，因此，通过水平扩展，集群可以提高自己的存储容量和吞吐量。举例来说，当插入一条数据时，应用只需要访问存储这条数据的分片.

使用分片减少了每个分片存储的数据。

（三）、分片集群节点介绍

1、路由节点mongos

* 提供集群单一入口

* 转发应用端请求

* 选择合适数据节点进行读写

* 合并多个数据节点的返回

* 无状态

2、配置节点config

* 所有存、取数据的方式

* 所有shard节点的信息，分片功能的一些配置信息

3、数据节点mongod

* 以复制集为单位

* 横向扩展

* 最大1024分片

* 分片之间数据不重复

* 所有分片在一起才可以完整工作

Mongos本身并不持久化数据，Sharded cluster所有的元数据都会存储到Config Server，而用户的数据会议分散存储到各个shard。Mongos启动后，会从配置服务器加载元数据，开始提供服务，将用户的请求正确路由到对应的碎片。

（四）、MongoDB分片集群特点

* 应用全透明，无特殊处理

* 数据自动均衡

* 动态扩容，无须下线

（五）、分片集群数据分布方式

基于范围

基于Hash

基于zone / tag

二、分片集群中数据分布

（一）、Chunk是什么

在一个shard server内部，MongoDB还是会把数据分为chunks，每个chunk代表这个shard server内部一部分数据。chunk的产生，会有以下两个用途：

Splitting

当一个chunk的大小超过配置中的chunk size时，MongoDB的后台进程会把这个chunk切分成更小的chunk，从而避免chunk过大的情况

Balancing

在MongoDB中，balancer是一个后台进程，负责chunk的迁移，从而均衡各个shard server的负载，系统初始1个chunk，chunk size默认值64M,生产库上选择适合业务的chunk size是最好的。ongoDB会自动拆分和迁移chunks

（二）、chunk特点

（1）使用chunk来存储数据

（2）进群搭建完成之后，默认开启一个chunk，大小是64M，

（3）存储需求超过64M，chunk会进行分裂，如果单位时间存储需求很大，设置更大的chunk

（4）chunk会被自动均衡迁移。

（三）、chunksize的选择

小的chunksize：数据均衡是迁移速度快，数据分布更均匀。数据分裂频繁，路由节点消耗更多资源。大的chunksize：数据分裂少。数据块移动集中消耗IO资源。通常100-200M

（四）、chunk分裂及迁移

随着数据的增长，其中的数据大小超过了配置的chunk size，默认是64M，则这个chunk就会分裂成两个。数据的增长会让chunk分裂得越来越多。

这时候，各个shard 上的chunk数量就会不平衡。这时候，mongos中的一个组件balancer 就会执行自动平衡。把chunk从chunk数量最多的shard节点挪动到数量最少的节点。

（五）、chunkSize 对分裂及迁移的影响

　MongoDB 默认的 chunkSize 为64MB，如无特殊需求，建议保持默认值；chunkSize 会直接影响到 chunk 分裂、迁移的行为。

chunkSize 越小，chunk 分裂及迁移越多，数据分布越均衡；反之，chunkSize 越大，chunk 分裂及迁移会更少，但可能导致数据分布不均。

chunkSize 太小，容易出现 jumbo chunk（即shardKey 的某个取值出现频率很高，这些文档只能放到一个 chunk 里，无法再分裂）而无法迁移；chunkSize 越大，则可能出现 chunk 内文档数太多（chunk 内文档数不能超过 250000 ）而无法迁移。

chunk 自动分裂只会在数据写入时触发，所以如果将 chunkSize 改小，系统需要一定的时间来将 chunk 分裂到指定的大小。

chunk 只会分裂，不会合并，所以即使将 chunkSize 改大，现有的 chunk 数量不会减少，但 chunk 大小会随着写入不断增长，直到达到目标大小

三、分片集群规划

（一）、IP端⼝规划

db01 10.0.0.51

Shard2_Master 28100

Shard1_Slave 28200

Shard3_Arbiter 28300

Config Server 40000

mongos Server 60000

db02 10.0.0.52

Shard2_Master 28100