【MongoDB】在window系统下搭建MongoDB的分片系统(一)

这篇主要讲述分片集群的主要原理

坦白说,刚看到这个分片系统(Sharding)有点蒙,感觉有点太高大上了。看美国作家Kyle Banker《Mongodb in action》没有明白。又查询资料,首先对与分片的做个说明。从其他书本上看的,说分片这是一种将海量数据水平扩展的数据库集群系统,数据分表存储在sharding的各个节点上,使用者通过简单的配置就可以很方便地够将一个分布式MongoDB集群。

一、角色说明

要构建一个MongoDB分片集群,需要三个角色:

  • shard server  即存储实际数据得分片,每个shard 可以是一个Mongod实例,也可以是一组mongod实例构成得Replica Set(也就是以前博客里说明的复制集)。为了实现每个shard内部的auto-failover,MongoDB官方建议每个shard 为一组Replica set。
  • Config Server  为了将一个特定的collection存储在多个shard中,需要为该collection指定一个shard key,例如{age:1},shard key可以决定该条记录属于哪个chunk。(chunk将在后面做详细介绍)Config Servers就是用来存储所有shard节点的配置信息,每个chunk的shard key范围,chunk在各shard的分布情况 、该集群中所有DB和collection的sharding 配置信息
  • Route Process 这个一个前端路由,客户端由此接入,然后询问config servers需要到哪个shard上查询或把保存记录,在连接相应的shard进行操作,最后讲结果返回客户端。客户端只需要将原本发给mongod的查询或更新请求原封不动地发给rounting processl.而不必关心所操作的记录存储在哪个shard上,

二、框架结构

如果用一台物理机搭建分片集群:结构图如下:


每个服务器的端口不一样

三、框架说明

由于该分片集群比较抽象,我从其他数据上看到些说明,在这里做一个补充;

A:分片是把数据库分别在多个服务器上

B:查询一个用户实际涉及两次查询,第一次访问配置数据库以获得用用户的分片位置,第二次查询直接访问包含用户数据的分片

C:主要解决说明扩容问题以及负载均衡问题

D:手动管理分片的著名框架为: Twitter的Gizzard (详见:http://mng.bz/4qvd)

E :对现在系统的分片决定因素: 磁盘活动,系统负载以及最重要的工作集大小与可用内存的比例

F:chunk块的概念:它是位于一个分片中的一段连续的分片键范围。它们是种逻辑意义上的东西而不是物理意义上的。

G: 分片键: MongoDB的分片是基于范围的。也就是说分片的集合中每个文档都必须落在指定键的某个值范围。分片键就是让每个文档能在这些范围中找到自己的位置

H:拆分和迁移

这两个是完全不同的概念,拆分思想是当分片块数据达到一定大小时候把其分为两块。拆分后的两块都有相同数量的文档。拆分仅仅是个逻辑操作,不会影响分片集合中里文档的物理顺序。

迁移是由名为“balancer”均衡器软件进行管理的,它的任务是确保数据在各个节点中保持均匀分布。通过跟踪各分片块的数量,就能实现该功能。通常来说,当集群中拥有块最多的分片与拥有块最少的分片的块数差大于8时,均衡器就会发生一次均衡处理。

I:建议框架图




郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。