MongoDB分片介绍（一）——基本概念

 

一、简介

拥有大量数据和高吞吐量应用的数据库将挑战单个服务器的容量。大量的查询将会耗尽单台机器的CPU，大量的数据将超出单台机器的存储空间，活动数据集合将超出单台机器的内存容量导致磁盘IO压力巨大。为解决上述问题，存在两种思路，一种为水平扩展，一种为垂直扩展。

垂直扩展的基本思路是增加单台机器的性能，包括CPU扩容、内存扩容、存储空间扩容。通过增加容量进行扩展存在着明显的限制，拥有大量CPU和内存的服务器过于昂贵，远远超过那些小型系统。并且，单台机器能够扩展的容量总是存在限制的，不能做到无限扩容。

水平扩展将数据打散并分布到多台物理机器上（称为多个分片），每个分片都是一套独立的数据库。无数个分片组成一个大的、单一对外的数据库系统。分片技术主要用于解决大容量数据和高吞吐应用带来的扩展难题。分片技术减少了每个分片需要处理操作个数，当集群增大时，每个新增的分片都会分担一部分操作压力，这样集群的数据容量和处理能力得到了水平扩展。分片技术同时减少了每台机器存储的数据量，当集群规模增大时，整个数据库能够容纳数据量也随之增大。

MongoDB通过分片技术支持水平扩展，MongoDB分片集群中有三个组件：Shards、Query Routers、Config servers。Shards存储实际的用户数据，为提高可用性和一致性，在生产环境下，每个分片可以是一个复制集。Query Routers是通过Mongos实例实现，它与客户应用程序接口并将应用程序的数据请求转发到对应的分片。Mongos实例在获得各个分片返回结果后，再拼装成最终结果集返回给应用程序。一个应用程序可以有多个Query Routers，以分担客户端请求的压力。Config servers存储了分片集群的元数据，包含了集群用户数据和分片之间的映射关系，Query Routers将使用这些元处理将用户请求引导到合适的分片上。一个MongoDB分片集群典型部署如下，包含三个Config servers、两个Query Routers和若干个分片。

 

 

 

 

 二、数据分片过程

 

1. 分片键

当客户端应用程序通过mongos向数据库插入一条数据时，碰到的第一个问题是应该将输入插入到那个分片中。MongoDB是通过分片键实现对分片的选择的，即通过集合字段中个别字段的值确定数据应该插入到那个分片。分片键必须是一个索引或者是组合索引的一个字段，MongMongoDB支持基于范围的分片和基于HASH的分片两种方法。

对基于范围的分片，MongoDB根据分区键值范围把输入分成各个区间。假设是一个数据型键值取值范围从负无穷到正无穷，类似一个横坐标，MongoDB就把这个坐标线分成若干段，每段线表示一个区间，相互之间不重叠。

 

 

对基于HASH的分片，MongoDB首先计算分区键值的HASH值，然后用这些HASH值去创建Chunk。由于键值相邻的记录HASH不同，因此它们会落到不同的Chunk中，这一点保证了集合在分片集群上的随机分布。

 

 

 

2、分裂与平衡

当新数据不断插入到MongoDB的时候，一个个Chunk是如何产生的呢？MongoDB是如何保证各个分片之间的Chunk数量平衡的呢？这里就要提到两个后台进程：splitting和balancer。

Splitting是一个用于防止一个Chunk过大的后台进程，当Chunk增大到超过设定的值时，MongoDB将会把这这个Chunk分裂成两个Chunk。插入、更新操作都可能引起Chunk分裂。在分裂过程中，MongoDB只涉及一些元数据的修改，不需要在分片之间移动数据。

 

 

 

当某个集合的各分片的数据分布不平衡时，balancer后台进程将会从拥有最多Chunk的分片将Chunk迁移到拥有最少Chunk的分片上，直到各个分片上的数据达到平衡。比如一个集合在分片1上有100个Chunk，分片2上有50个Chunk，balancer进程将会从分片1上迁移25个Chunk到分片2上，以达到两个分片的数据分布平衡。Chunk的移动都是在后台进行的，如果在移动过程中有数据请求，这些请求将会仍然转发到原始分片上。

Chunk迁移过程分为三步：首先目标分片接受来自源分片的集合数据，然后目标分片应用在迁移过程中捕获的对正在迁移的Chunk的修改，最后目标分片更新Config Server上的元数据。如果迁移过程失败，那么后台进程将会退出迁移过程，继续将Chunk留在源分片。迁移成功后，MongoDB才会删除源分片上的Chunk。

 

 

三、元数据

Config Server中保存了关于分片的所有元数据，这些元数据反映了分片的状态信息和组织信息。元数据包含了分片列表、Chunk列表以及分片的配置参数设置等，都存放在Config Server 中的一个名称为Config的数据库中。我们不建议大家手工直接维护Config数据库中的数据，应通过分片相关的命令来维护这些数据。

mongos实例在启动或者重启时将会从Config Server中读取元数据并保存在自己的内存中。当管理员执行命令修改Config Server中的元数据或者Chunk完成迁移后时，mongos实例同时也会在内存中更新相关数据。

在生产环境下，MongoDB建议应同时启动三个Config Server，以提高Config Server的整体可用性。当其中的一个或者两个Config Server不可用时，集群的整个元数据将变成只读状态，这时应用依然能够存取业务数据，但是分裂、平衡等影响元数据的操作将不能进行，直到三个Config Server都可用。