MongoDB部署架构之三：Sharding
2.3 分片设计思想
2.3.1合理的架构下的需要多少个分片
3 分片机制提供了如下三种优势
1MongoDB常见部署架构
先复习一下mongoDB的常见部署架构
1.1单复制集
MongoDB 可以以单复制集的方式运行，client 直连 mongod 读取数据。单复制集的方式下，数据的水平扩展的责任推给了业务层解决（分实例，分库分表）
1.2复制集
1、MongoDB复制集的主要意义在于实现服务高可用，它的现实依赖于两个方面的功能:
- 数据写入时将数据迅速复制到另一个独立节点上
- 在接受写入的节点发生故障时自动选举出一个新的替代节点【自动监控、自动选举、自动切换、自动恢复】
2、在实现高可用的同时，复制集实现了其他几个附加作用:
- 数据分发:将数据从一个区域复制到另一个区域，减少另一个区域的读延迟
- 读写分离:不同类型的压力分别在不同的节点上执行
- 异地容灾:在数据中心故障时候快速切换到异地
3、Mongodb复制集架构
一个典型的复制集由3个以上具有投票权的节点组成，包括:
一个主节点(primary) :接受写入操作和选举时投票
- 两个(或多个)从节点(secondary) :复制主节点上的新数据和选举时投票
- Arbiter (投票节点)：将某一个从库，设置为专用的投票节点，不存储数据，不负责数据复制。
- 不推荐使用Arbiter（投票节点）
4、Mongodb复制集数据是如何复制的？
当一个修改操作，无论是插入、更新或删除，到达主节点master时，它对数据的操作将被记录下来(经过一些必要的转换)，这些日志记录称为oplog。
mongodb的oplog，你可以当成mysql的binlog，oracle的redo。区别在于oplog是一张表（集合collection），json格式记录的。
从节点secondary通过在主节点上打开一个tailable的游标，不断获取（抽取）新进入主节点的oplog, 并在自己的数据上回放，以此保持跟主节点的数据一致。
【RS只有 异步模式，没有同步模式的】
更多内容参考《MongoDB部署架构之二：MongoDB复制集》
1.3分片集群
2 MongoDB分片介绍
分片（sharding）是MongoDB用来将大型集合分割到不同服务器（或者说一个集群）上所采用的方法。尽管分片起源于关系型数据库分区，但MongoDB分片完全又是另一回事。
和MySQL分区方案相比，MongoDB的最大区别在于它几乎能自动完成所有事情，只要告诉MongoDB要分配数据，它就能自动维护数据在不同服务器之间的均衡。
2.1 分片的目的
高数据量和吞吐量的数据库应用会对单机的性能造成较大压力,大的查询量会将单机的CPU耗尽,大的数据量对单机的存储压力较大,最终会耗尽系统的内存而将压力转移到磁盘IO上。
为了解决这些问题,有两个基本的方法: 垂直扩展和水平扩展。
垂直扩展：增加更多的CPU和存储资源来扩展容量。
水平扩展：将数据集分布在多个服务器上。水平扩展即分片。
2.2 MongoDB几个基本概念
各种概念由小到大；
- 片键shard key：文档中的一个字段
- 文档doc： 包含shard key的一行数据
- 块chunk： 包含n个文档
- 分片shard： 包含n个chunk
- 集群cluster： 包含n个分片
重点说一下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是最好的。MongoDB会自动拆分和迁移chunks。
2.3 分片设计思想
分片为应对高吞吐量与大数据量提供了方法。使用分片减少了每个分片需要处理的请求数，因此，通过水平扩展，集群可以提高自己的存储容量和吞吐量。举例来说，当插入一条数据时，应用只需要访问存储这条数据的分片.
使用分片减少了每个分片存储的数据。例如，如果数据库1tb的数据集，并有4个分片，然后每个分片可能仅持有256 GB的数据。如果有40个分片，那么每个切分可能只有25GB的数据。
2.3.1合理的架构下的需要多少个分片
分片大小
分片的基本标准：
关于数据：数据量不超过3TB，尽可能保持在2TB一个片
关于索引：常用索引必须容纳进内存
根据存储总量，单服务器可挂载量，以及并发数相关指标计算，例如：
2.3.2 创建分片表示例
sh.status()
sh.enableSharding("foo")
sh.shardCollection("foo.bar",{_id:"hashed"}
sh.status()
3 分片机制提供了如下三种优势
3.1.mongos 对集群进行抽象，让集群“不可见”
mongodb中没有failover机制，官方建议是将mongos和应用服务器部署在一起,多个应用服务器就要部署多个mongos实例。mongos作为统一路口的路由器，其会将客户端发来的请求准确无误的路由到集群中的一个或者一组服务器上，同时会把接收到的响应拼装起来发回到客户端。
mongos的高可用可以用有几种方法可以使这三个mongos接口都利用起来，减少单个接口的压力。常用的有LVS和HAProxy。于是尝试用HAProxy做负载均衡。但是我加了AWS ELB后，偶尔会报错如下：
org.springframework.dao.DataAccessResourceFailureException: Query failed with error code -5 and error message 'Cursor 65729798047612**** not found on server xxx.elb.xxx.amazonaws.com:27017' on server xxx.elb.xxx.amazonaws.com:27017;
后来改回ip列表后，就不再报错了。
-------------------------------------------------------------------------------------------------------
mongodb 原生提供集群方案，该方案的简要架构如下：
MongoDB集群是一个典型的去中心化分布式集群。mongodb集群主要为用户解决了如下问题：
- 元数据的一致性与高可用（Consistency + Partition Torrence）
- 业务数据的多备份容灾(由复制集技术保证)
- 动态自动分片
- 动态自动数据均衡
下文通过介绍 mongodb 集群中各个组成部分，逐步深入剖析 mongodb 集群原理。
ConfigServer
mongodb 元数据全部存放在configServer中，configServer 是由一组（至少三个）MongoDb实例组成的集群。
ConfigServer 的唯一功能是提供元数据的增删改查。和大多数元数据管理系统（etcd，zookeeper）类似，也是保证一致性与分区容错性。本身不具备中心化的调度功能。
ConfigServer与复制集
ConfigServer 的分区容错性(P)和数据一致性(C)是复制集本身的性质。
mongodb 的读写一致性由 WriteConcern 和 ReadConcern 两个参数保证。
两者组合可以得到不同的一致性等级。
指定 writeConcern:majority 可以保证写入数据不丢失，不会因选举新主节点而被回滚掉。
readConcern:majority + writeConcern:majority 可以保证强一致性的读
readConcern:local + writeConcern:majority 可以保证最终一致性的读
mongodb 对configServer全部指定writeConcern:majority 的写入方式，因此元数据可以保证不丢失。
对 configServer 的读指定了 ReadPreference:PrimaryOnly 的方式，在 CAP 中舍弃了A与P得到了元数据的强一致性读。
Mongos
数据自动分片
对于一个读写操作，mongos 需要知道应该将其路由到哪个复制集上，mongos通过将片键空间划分为若干个区间，计算出一个操作的片键的所属区间对应的复制集来实现路由。
Collection1 被划分为4个chunk，其中
chunk1 包含（-INF，1) , chunk3 包含[20, 99) 的数据，放在shard1上。
chunk2 包含 [1,20), chunk4 包含[99, INF) 的数据，放在shard2上。
chunk 的信息存放在configServer 的mongod实例的 config.chunks 表中，格式如下：
{
"_id" : "mydb.foo-a_\"cat\"",
"lastmod" : Timestamp(1000, 3),
"lastmodEpoch" : ObjectId("5078407bd58b175c5c225fdc"),
"ns" : "mydb.foo",
"min" : { "animal" : "cat" },
"max" : { "animal" : "dog" },
"shard" : "shard0004"
}
值得注意的是：chunk是一个逻辑上的组织结构，并不涉及到底层的文件组织方式。
-------------------------------------------------------------------------------------------------------
3.2.保证集群总是可读写
MongoDB通过多种途径来确保集群的可用性和可靠性。将MongoDB的分片和复制功能结合使用，在确保数据分片到多台服务器的同时，也确保了每分数据都有相应的备份，这样就可以确保有服务器换掉时，其他的从库可以立即接替坏掉的部分继续工作。
3.3.使集群易于扩展
当系统需要更多的空间和资源的时候，MongoDB使我们可以按需方便的扩充系统容量。
4、 分片集群架构
|
组件 |
说明 |
|
Config Server |
存储集群所有节点、分片数据路由信息。默认需要配置3个Config Server节点。 |
|
Mongos |
提供对外应用访问，所有操作均通过mongos执行。一般有多个mongos节点。数据迁移和数据自动平衡。 |
|
Mongod |
存储应用数据记录。一般有多个Mongod节点，达到数据分片目的。 |
分片集群的构造
（1）mongos ：数据路由，和客户端打交道的模块。mongos本身没有任何数据，他也不知道该怎么处理这数据，去找config server
（2）config server：所有存、取数据的方式，所有shard节点的信息，分片功能的一些配置信息。可以理解为真实数据的元数据。
（3）shard：真正的数据存储位置，以chunk为单位存数据。
Mongos本身并不持久化数据，Sharded cluster所有的元数据都会存储到Config Server，而用户的数据会分散存储到各个shard。Mongos启动后，会从配置服务器加载元数据，开始提供服务，将用户的请求正确路由到对应的碎片。
Mongos的路由功能
当数据写入时，MongoDB Cluster根据分片键设计写入数据。
当外部语句发起数据查询时，MongoDB根据数据分布自动路由至指定节点返回数据。
5集群中数据分布
5.1 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是最好的。MongoDB会自动拆分和迁移chunks。
分片集群的数据分布（shard节点）
（1）使用chunk来存储数据
（2）集群搭建完成之后，默认开启一个chunk，大小是64M，
（3）存储需求超过64M，chunk会进行分裂，如果单位时间存储需求很大，设置更大的chunk
（4）chunk会被自动均衡迁移。
5.1.2 chunksize的选择
适合业务的chunksize是最好的。
chunk的分裂和迁移非常消耗IO资源；chunk分裂的时机：在插入和更新，读数据不会分裂。
chunksize的选择：
小的chunksize：数据均衡是迁移速度快，数据分布更均匀。数据分裂频繁，路由节点消耗更多资源。大的chunksize：数据分裂少。数据块移动集中消耗IO资源。通常100-200M
5.1.3 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 大小会随着写入不断增长，直到达到目标大小。
5.3 数据区分
5.3.1 分片键shard key
MongoDB中数据的分片是以集合为基本单位的，集合中的数据通过片键（Shard key）被分成多部分。其实片键就是在集合中选一个键，用该键的值作为数据拆分的依据。
所以一个好的片键对分片至关重要。片键必须是一个索引，通过sh.shardCollection加会自动创建索引（前提是此集合不存在的情况下）。一个自增的片键对写入和数据均匀分布就不是很好，因为自增的片键总会在一个分片上写入，后续达到某个阀值可能会写到别的分片。但是按照片键查询会非常高效。
随机片键对数据的均匀分布效果很好。注意尽量避免在多个分片上进行查询。在所有分片上查询，mongos会对结果进行归并排序。
对集合进行分片时，你需要选择一个片键，片键是每条记录都必须包含的，且建立了索引的单个字段或复合字段，MongoDB按照片键将数据划分到不同的数据块中，并将数据块均衡地分布到所有分片中。
为了按照片键划分数据块，MongoDB使用基于范围的分片方式或者 基于哈希的分片方式。
注意：
分片键是不可变。
分片键必须有索引。
分片键大小限制512bytes。
分片键用于路由查询。
MongoDB不接受已进行collection级分片的collection上插入无分片
键的文档（也不支持空值插入）
5.3.2 以范围为基础的分片Sharded Cluster
Sharded Cluster支持将单个集合的数据分散存储在多shard上，用户可以指定根据集合内文档的某个字段即shard key来进行范围分片（range sharding） 
对于基于范围的分片，MongoDB按照片键的范围把数据分成不同部分。
假设有一个数字的片键:想象一个从负无穷到正无穷的直线，每一个片键的值都在直线上画了一个点。MongoDB把这条直线划分为更短的不重叠的片段，并称之为数据块，每个数据块包含了片键在一定范围内的数据。在使用片键做范围划分的系统中，拥有”相近”片键的文档很可能存储在同一个数据块中，因此也会存储在同一个分片中。
2.3.3 基于哈希的分片
分片过程中利用哈希索引作为分片的单个键，且哈希分片的片键只能使用一个字段，而基于哈希片键最大的好处就是保证数据在各个节点分布基本均匀。
对于基于哈希的分片，MongoDB计算一个字段的哈希值，并用这个哈希值来创建数据块。在使用基于哈希分片的系统中，拥有”相近”片键的文档很可能不会存储在同一个数据块中，因此数据的分离性更好一些。
Hash分片与范围分片互补，能将文档随机的分散到各个chunk，充分的扩展写能力，弥补了范围分片的不足，但不能高效的服务范围查询，所有的范围查询要分发到后端所有的Shard才能找出满足条件的文档。
5.3.4 分片键选择建议
选择合适的片键，影响片键效率的主要因素：
- 取值基数（cardinality）
- 取值分布
- 分散写，集中读
- 被尽可能多的业务场景用到
- 避免单调递增或递减的片键
1、递增的sharding key
数据文件挪动小。（优势）
因为数据文件递增，所以会把insert的写IO永久放在最后一片上，造成最后一片的写热点。同时，随着最后一片的数据量增大，将不断的发生迁移至之前的片上。
2、随机的sharding key
数据分布均匀，insert的写IO均匀分布在多个片上。（优势）
大量的随机IO，磁盘不堪重荷。
3、混合型key
大方向随机递增，小范围随机分布。
为了防止出现大量的chunk均衡迁移，可能造成的IO压力。我们需要设置合理分片使用策略（片键的选择、分片算法（range、hash））
正确姿势：
1、选择基数大的片键，取值基数要大（对于小基数片键，备选值有限，那么块的总数量就有限，随着数据的增加，块变得越来越大。太大的块会导致水平扩展时移动块会非常困难）
2、取值分布均匀的片键，取值分布应该尽可能均匀（对于不均匀的片键，容易造成某些块的数据量急剧增大，块压力越来越大，数据均衡以chunk为单位，所以系统无能为力）
3、定向性好，对主要查询要具有定向能力
分片注意：
分片键是不可变、分片键必须有索引、分片键大小限制512bytes、分片键用于路由查询。
MongoDB不接受已进行collection级分片的collection上插入无分片键的文档（也不支持空值插入）
示例说明：-------------------------------------------
例如：一个email系统片键的例子：
1、片键：{_id：1}
- 基数：好
- 写分布：不好。自增导致热分片
- 定向查询：不好。随机id无法查询
2、片键：{_id："hashed"}
- 基数：好
- 写分布：好
- 定向查询：不好。用email查时，要到多个shard上查找
3、片键：{user_id：1}
- 基数：不好（超级chunk）
- 写分布：好
- 定向查询：好
4、片键：{user_id：1，time：1}
- 基数：好
- 写分布：好
- 定向查询：好
6足够的资源
mongos没有存储，不需要存储
config：1个cpu（也是一个mongod，可以理解为一个shard）
转自：https://www.cnblogs.com/clsn/p/8214345.html#auto_id_0
