如何快速掌握MongoDB？ | Sharding篇

图片来源于网络

随着MongoDB在国内的推广，越来越多的开发人员开始使用MongoDB，但是由于缺乏培训和指导，很多人不清楚MongoDB在建模、复制集以及分片等方面的使用原则和技巧。在实际工作中踩到了很多的坑。

我由于工作的关系，需要使用MongoDB进行海量地图数据的存储和快速查询。通过翻阅Mongodb官方手册，跟官方工程师近距离请教，自己实践验证，我总结了一些MongoDB的使用经验，现在分享给大家，希望对大家在使用MongoDB的过程中有借鉴价值。

今天分享的是有关MongoDB分片的使用经验。

一、何时需要分片

我们在考虑分片时，通常是要解决两类问题

1、是存储容量受单机限制，磁盘资源遭遇瓶颈了。

2、是读写能力受单机限制了

其实 读能力也可以在复制集里加secondary节点来扩展，可能是CPU、内存或者网卡等资源遭遇瓶颈，导致读写能力无法扩展

二、如何确定sharding 和 mongos节点个数

shard、mongos的数量归根结底是由应用需求决定，如果使用sharding只是解决海量数据存储的问题，访问并不多，那么很简单,假设单个shard能存储M， 需要的存储总量是N。

分片个数= N / M / 0.75

因为对访问要求不高，至少部署2个mongos做高可用即可。

如果你使用sharding是解决高并发写入（或读取）数据的问题，总的数据量其实很小，这时部署的shard、mongos要能满足读写性能需求，而容量上则不是考量的重点

假设单个shard最大qps为M，单个mongos最大qps为Ms，需要总的qps为Q ,那么

分片个数=Q / M / 0.75

路由节点个数= Q /Ms/ 0.75

mongos、mongod的服务能力，需要用户根据访问特性来实测得出 。

三、如何进行分键的选择

在做mongodb的分片时，选择片键也是非常关键的问题。

在官方的文档中指出四个原则可以遵循。

第一个是，片键的取值基数要比较大，如果片键可取值少，会出现巨大的chunk，无法被分裂和迁移的情况。

第二个是，大部分的读请求都能用到，如果读请求用不到片键，mongos会发查询请求到所有分片服务器，进行全表的扫描，最后到mongos再合并，这个检索的效率会很低。

第三个是，当单个片键的取值范围不够大的话，可以考虑选择多个字段，组合成复合片键。扩大取值基数。

第四个是，不要选择单调递增的字段作为片键。比如日期型字段 或_id作为片键，因为会导致写一直在一个shard中，使单个服务器写过热，无法发挥集群的效应。

四、configServer如何设计

在整个MongoDB集群的设计中，有关分片和路由节点的设计方式前面已经讨论过，重点介绍一下configServer的设计。

在mongodb3.4版本开始，就已经不在支持用单个mongod实例做configserver了，要求把congfigserver部署成复制集来使用啦。

Configserver的复制集是不允许有 仲裁节点和延迟节点的。当有一个config节点宕机，则整个configserver只能读元数据不能写了

另外，mongos进程会把configserver中的元数据加载到内存中，如果configserver的复制集中所有的节点都连接不上，两个路由节点还是可以连接下面的分片集群进行工作的。

此时，Chunck的分裂、迁移的操作也将不会发生，当然mongos进程重启了就必须连接configserver来读取元数据。

config Server复制集

五、应用案例

本案例中需要存储42T的地图瓦片数据，是典型的海量存储应用类型。单个分片服务器最大可以提供30T的存储空间，因此基于文章第二部分的计算方法，计算得出需要2个分片才能实现42T数据的存储。

在Mongos的配置上，由于不需要支持高并发写入的场景，因此部署2个mongos做高可用即可满足案例应用的需要了。

在Config Server 的配置方面，采用了复制集的方式进行Config Server的设计方式，来保证元数据读写的高可用和高可靠。

在片键的选择上，本案例中所有的查询都是基于瓦片所在的层级 z、行号 x、列号 y以及瓦片类型 t 进行检索。

考虑到 如果使用瓦片所在的层级 z、行号 x 做片键，会出现片键取值基数小，以及多个分片检索的问题。

因此采用了层级 z、行号 x、列号 y以及瓦片类型 t做复合片键的设计方式。这样的片键选择，既可以保证片键的取值基数足够大，又可以使瓦片的查询快速定位到单个分片。

分片设计方案

六、使用技巧

在部署过程中有一个小技巧分享给大家，建议把27017端口分配给mongos使用。

这样用mongo维护集群时，默认就连接到了mongos，维护集群会方便一些，不需要反复确认mongos分配的是哪个端口了。

另外，在部署mongos节点时建议与AppServer 部署在一起，这样应用端与Mongos的通信就是本地通信了，会加快应用端的连接和访问的速度。

为了深入学习MongoDB，我还通过了MongoDB官方认证考试，文中有说的不清楚，或值得商榷的地方，可以通过发简信的方式联系我，一起讨论，相互学习。

End.