【MongoDB】在window系统下搭建MongoDB的分片系统（一），windowmongodb
这篇主要讲述分片集群的主要原理
坦白说，刚看到这个分片系统（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：建议框架图
这个数据库默认会吃掉大量的内存作缓存用，目前好像也没办法限制内存使用量，所以建议别把数据库和其他程序放在一台机器上了
数据文件确实只能存储2GB，但是那是单个的数据文件。操作系统是32位还是64位是针对内存的，而存储在硬盘里的数据文件是跟操作系统没有直接关系的（跟磁盘的存储格式以及文件管理系统有关）。
32位的操作系统只能访问到3点多G的内存空间，而mongodb是内存数据库，在mode模式为非安全情况下，mongo数据库的数据是存储在内存中的。而监狱32位操作系统访问内存的限制，所以在启动mongod时，会有提示32位操作系统的警告提示。
但是mongodb不会那么笨的，在磁盘上存储的数据文件，mongo会自动进行文件划分；但是这个划分并不是存满后就分出来，是按照一定的索引规则进行文件划分的。所以你看到的，如果你的数据库是大于2G的，你看到的可能是更多被划分的文件。