【MongoDB】Sharding分片概念及原理

面对海量的数据，如何提升数据读写效率？了解过DB的应该都知道数据库的分区，分区是主要提升数据查询的效率。面对海量数据的IO能力限制以及扩展性，Sharding是一个利器，我们不用关心具体的实现，从而实现性能的提升。

Sharding不是一门技术，而是一个理念，解决数据的水平扩展，突破单节点的IO限制。很多成熟的NoSQL以及NewSQL就自带了sharding实现，使用者直接指定需要分片的字段，集群就可以自行分片了。

sharding是share nothing的简写，在不同的片区，数据互不干扰。和传统的分区不同，数据库分区是物理数据库实现的技术，目的是为了在操作数据库时减少SQL设计的读写范围，提升读数据的时间。sharding是面对分布式的存储，将查询进行并行处理。

sharding是负责数据的一个子集中一台或多台服务器，如果有多台服务器，每一台服务器都是一个数据的副本，通常我们在replica set中可以设定副本数。一般来说，在定义了分片key字段后，sharding有三种方式：

1. 按号段

2. hash取模

3. 用户自定义

很多nosql和newSQL已经实现了sharding技术，下面以MongoDB和Mysql cluster为例来详细介绍。

MongoDB

在指定了分片字段（shard key)后，mongoDB集群会将数据自行进行分区，通过数据量进行分片。同时他会对每一分片进行区间划分，每一区间又各自存储不同范围的数据。这么做目的是为了进行数据的合理转移，减少因为大数据量的转移带来的网络开销，影响使用。通常块定义大小是200M，定义过大，会导致移动数据大带来的网络开销，过小，又会带来管理开销。

mongoDB在移动数据使之达到平衡的工作，由一个平衡器进程来做，自动化完成，你无需关心其中细节。平衡器的目标不仅是平衡，还需要最小化迁移量。

用户不会直接的访问mongo分片，二是通过mongoDB的终端mongos来访问，其会转移所有的请求到对应的分片，而所有的配置，都保存在mongod配置服务器上，mongod是轻量的进程，通常可以运行在任何的mongo集群服务器上。

使用mongo集群需要注意对数据的统计，如果一个分片移动正在进行，那么在两个分片都会保存该数据，直到移动完成，才会在原有分片上将数据删除。所以如果分片不合理造成频繁的移动，那么极有可能是统计出很多多余的数据。

另外，如果需要对数据超过一个字段进行唯一性验证，通常我们设置了一个字段索引，并按照该字段索引进行分片，这时针对另外一个需要唯一性的字段，写入时必须要检测是否已经存在，假设有两个应用程序进程，同时检测，这时会得到都没有的结果，然后同时写入，导致重复字段。解决的方式是必须在写前对所有集群加锁，但会严重影响集群的性能。