MongoDB简介

MongoDB是一个基于分布式文件存储的数据库，由C++语言编写，旨在为WEB应用提供可扩展的高性能数据存储解决方案。文档数据库，类似 JSON 文档内存储数据，在面对数据，这种方法非常自然，比传统的排/列模型更加直观和强大。

MongoDB分片简介

为了维护大规模的数据，或者满足大规模的并发访问，单台服务器已经达到瓶颈，需要通过服务器扩容来满足需求，这里就会涉及分片（Sharding）。

分片实际是对数据按照某种既定的规则进行数据切分存储，使用时，通过多线程（多服务器资源）实现数据库快速检索和返回，已达到加速的目的。

分片技术广泛应用于大数据、高并发、多维度计算、复杂检索等场景下。

分片的几个组件

主要有如下所述三个主要组件：

Shard（数据节点）:

用于存储实际的数据。在分片中，每组shard存储不同的数据，同一组shard由多个Replica set（复制集）组成，不同的shard之间解决数据分片存储（分散存储），不同的Replica set解决高可用问题。

Config Server（配置节点）:

用于存储MongoDB元数据信息，其中包括 chunk信息。

Query Routers（路由节点）:

客户端的连接入口，可配置多个，使用应用连接高可用。

分片的几种方式

Hash Sharding

通过对分片键进行Hash计算，根据Hash值将数据分配对应的分片上（chunk）。

Hash分片基本可以实现数据的均衡分布，可以有效解决数据热点问题，常用于随机读写较多的应用场景。

Ranged Sharding

范围分区是根据分片键，安装一定的区间进行划分，落在同一区间的数据会被分配到同一个分片（chunk）上。

Zones in Sharded Clusters

Zones是在Ranged Sharding基础上进行了灵活配置，使其满足更复杂的业务场景。

一个zone可以包含一个或者多个Ranged Sharding Key，即一个zone可以分配在多个shard节点上，同一个shard节点上也可以包含多个zone。看到这里，也许会被这里的包含规则给弄晕了，MongoDB之所以会设计zone，通常用于异机房多中心数据存储中，实现本地数据快速读写的效果，解决跨机房（数据中心）数据传输。

剑有了，你会用吗？

通过上面的介绍，相信对MongoDB分片有了一点的了解，如何以正确的姿势去使用，需要通过大量的实践去检验。

分片是把双刃剑，用好了系统会像defu般丝滑，用不好，砸电脑的心都用，这里对如何进行系统优化、如何才能构建丝滑般的分片集群不做详解，但是有个大方向你必须知道，有了它，你才能知道如何去做一个好的分片架构设计。

没错，就是它，响应时间！

有人说，你不是废话吗，系统快不快，丝不丝滑不都是通过响应时间来判断的吗？

没错，但是你知道这个响应时间是怎么来的吗？

从应用对数据库发出一个查询操作，都需要经过哪些操作，每个操作都做了什么，瓶颈在哪里，应该怎么排查问题？

通过MongoDB的一个工具我们看下：

示例采用3分片架构，查询返回数据量26w左右，耗时374ms。从响应时间入手，看下374ms怎么来的。

分片rs1耗时：100+150+110+14=374

分片rs2耗时：10+10+20+14=54

分片rs3耗时：30+50+70+14=164

所以，最终的响应时间取决于最慢的那个分片。

本示例慢的原因和数据量大小有一定关系，数据分布不均衡导致查询结果耗时不同。

注意，这里的数据分布不均衡不是指分片存储数据不均衡，而是返回的结果集分布不均衡，即查询的结果数据主要集中在rs1分片上，导致这个问题的原因主要和分片涉及与业务逻辑不匹配导致的。

这里对这个问题不再做深入分析，只需明白耗时最多的那个节点将决定集群最终的响应时间，那么有哪些问题会导致不同分片之间响应时间的差异呢，遇到问题该如何优化呢，在数据库设计时，如何根据业务特性进行合理的分片呢？

欢迎大家一起讨论，期待与大家共同成长！

Tags：windows mongodb安装与配置