图片 9

[C#项目开源] MongoDB 可视化管理工具 (2011年10月-至今)

正文

该项目从2011年10月开始开发,知道现在已经有整整5年了。MongoDB也从一开始的大红大紫到现在趋于平淡。
MongoCola这个工具在一开始定位的时候只是一个Windows版本的工具,期间也想改为WebPage版本,但是只是开了一个头,也没有继续下去。
现在想想,可能这个决定是正确的,WebPage版本是为了跨平台才去做的,但是,当时的环境,Net
Core并没有发布,即使用MVC5搭建平台,也依然无法做到跨平台。
现在,随着Net Core的发布,WebPage的事情也重新摆上日程了。

选在这个时候发布软件,一是因为Connect16大会之后,微软也发布了很多令人振奋的消息,所以我也来锦上添花一下。二来,MongoDB3.4这个重大的版本更新也是箭在弦上了,应该年底就会发布正式版本了。三来,也是对于今年的一个总结。
虽然这只是一个Winform的项目,但是在开发中,几乎将整个MongoDB的官方文档都翻了一遍,很多知识也重新学习了一下,收获还是很丰富的。
由于开发周期很长,很多代码在这次开发中,都进行了老朽化处理,废弃和修改了很多东西,所以测试也并不完全,所以这个工具现在只是用于学习MongoDB或者是开发环境下使用。

对于开源软件,其实很多人只是想看看源代码,或者收藏源代码,能够从源代码里面找到自己想要的功能的人不多,能够加入开发的更少了。这个项目只有2-3个同志贡献过有用代码,非常感谢。
所以这次开源,我也不抱什么希望,如果有谁能够从我的代码中学到些什么,我就知足了。

MongoCola工具 :

MongoCola是一款帮助你在图形界面下查看,操作MongoDB的工具类软件。
本工具的目标是尽量用图形界面来代替命令脚本帮您完成一些日常的MongoDB管理工作。

本软件是完全免费的软件,您可以无条件的使用本软件的任何功能。
下载地址:
用户手册:

GitHub 项目地址
意见和建议:
版本号:Ver 2.1.0
文档最后更新时间:2016-11-24

为何要分片 1.减少单机请求数,降低单机负载,提高总负载
2.减少单机的存储空间,提高总存空间。

该项目在Github上的热度:

图片 1

图片 2

用户手册:

图片 3

在开发的过程中,当然会有一些问题产生,如果有问题,可以和MongoDB工程师通过JIRA进行沟通。
如果你的资料够详细,能够很快复原出问题现场,他们的feedback也是很快的。

图片 4

常见的mongodb sharding 服务器架构

GeoNear

真正有用的开源信息,也就是上面这些了。不过,按照博客园小编的想法,文章或多或少要写点什么东西,不然会当作广告处理的。所以还是写点什么吧。

前几天,有个朋友用MongoDB做GeoNear的查询操作。在MongoDB中,对于地理坐标的内置处理是一个特色。
你可以在数据的某个字段里面保存坐标,然后可以使用GeoNear来寻找离开指定坐标,指定距离内的所有记录。
但是,这里有一个坑,在MongoDB里面有一种坐标格式是GeoJson,一种格式是LegacyPoint。前者是现在官方推荐的坐标形式,后者就如它的名字一样,是旧的形式。
这两种坐标,前者是一个BsonDocument,后一种是BsonArray:
BsonDocument:{ type:”point”,coordinate:”40.1234,120.333″}
BsonArray:[40.1234,120.3333]
但是,在GeoNear这个命令中,前者的距离单位是Meter(米),后者是Redius(弧度)。1个弧度
= 6314公里,所以很容易搞错的。
如果你使用了LegacyPoint作为指定点的坐标,然后想指定1000米之内的所有坐标,恭喜你,你实际上会得到所有的点(1000弧度,6314000公里)
当然,即使你输入的指定坐标是GeoJson,但是你的数据库里存放的点是LegacyPoint,则同样会是所有的点。
所以,如果您的项目需要用到地理坐标,请一定要用GeoJson来保存数据。

这些知识也是博客园上的一个同志问我的,我也通过查阅官方文档才得到这样的结论。所以说,官方文档,阅读文档的能力,也是程序员的一个技能。

接下来贴几张图吧:第一张是上面提到的GeoNear

图片 5

主界面这个样子的

图片 6

MapReduce

图片 7

最后引用一段网络上的MongoDB3.4新特性的资料来结束这篇帖子:

MongoDB 下一个大版本 3.4 即将发布,本文主要介绍 3.4
版本在功能特性上做的改进,内容翻译自 Development Release Notes for 3.4
Release Candidate。

图片 8

分片集群(Sharde d Cluster)

要构建一个 MongoDB Sharding Cluster,需要三种角色:
1.Shard Server 即存储实际数据的分片,每个Shard可以是一个mongod实例,也可以是一组mongod实例构成的Replication
Set。为了实现每个Shard内部的auto-failover(自动故障切换),MongoDB官方建议每个Shard为一组Replica
Set。
2.Config Server 为了将一个特定的collection存储在多个shard中,需要为该collection指定一个shard
key(片键),例如{age: 1} ,shard
key可以决定该条记录属于哪个chunk(分片是以chunk为单位,后续会介绍)。Config
Servers就是用来存储:所有shard节点的配置信息、每个chunk的shard
key范围、chunk在各shard的分布情况、该集群中所有DB和collection的sharding配置信息。
3.Route Process 这是一个前端路由,客户端由此接入,然后询问Config
Servers需要到哪个Shard上查询或保存记录,再连接相应的Shard进行操作,最后将结果返回给客户端。客户端只需要将原本发给mongod的查询或更新请求原封不动地发给Routing
Process,而不必关心所操作的记录存储在哪个Shard上。(所有操作在mongos上操作即可)

Membership Awareness

MongoDB 3.4里,分片集群的所有组件,Config server、mongod、mongos
都能相互感知整个分片集群的存在,了解整个分片集群的配置信息,这样能避免分片集群的误配置,比如在现在的版本,有可能会将一个
shard 错误的加到多个 sharded cluster 了。这个特性引入了如下限制

分片集群里 mongod 启动时,必须显式配置 sharding.clusterRole 为
shardsrv
3.4版本的 mongos 不能连接低版本的 mongod
Config server 的 Primary 节点负责负载均衡

MongoDB 3.2及以前版本里,分片集群的负载均衡由 mongos 负责,多个 mongos
会抢一个分布式锁,抢锁成功的 mongos 会对执行负载均衡任务,在 shard
间迁移 chunk;在3.4版本里,负载均衡将由 Config server 的 Primary
节点负责,预计会在负载均衡并发度及效率上会有大的提升。

配置分片服务器 下面我们在同一台物理机器上构建一个简单的 Sharding Cluster:

不再支持 SCCC Config server 的模式

MongoDB 3.2版本引入了复制集模式的 Config Server(CSRS
模式),在此之前,Config server
由多个镜像的单节点组成(SCCC模式),3.4版本里,MongoDB 将不再支持
SCCC模式的 Config server。

所以往 3.4 版本升级时,如果Config server 还是 SCCC 模式,需要先升级为
SCRS 模式。

图片 9

Sharding Zones

分片集群里引入了 Zone 的概念,主要取代现在的 tag-aware sharding
机制,能将某些数据分配到指定的一个或多个 shard 上,这个特性将极大的方便
sharding cluster 的跨机房部署,详细了解 Sharding zone 机制。

Shard Server 1:27017
Shard Server 2:27018
Config Server :27027
Route Process:40000

复制集(Replica Set)

majority WriteConcern 支持配置是否刷 journal

配置复制集时,增加 writeConcernMajorityJournalDefault 选项,默认为
true,即当指定 WriteConcern 为 majority 时,数据写到大多数节点并且
journal 成功刷盘后,才向客户端确认成功;如果为
false,数据写到大多数节点的内存,就向客户端确认。

1.步骤一: 启动Shard Server

支持配置 Primary 追数据的时间

配置复制集时,增加 catchUpTimeoutMillis
选项,默认为2s,来指定新选举出来的 Primary
从其它拥有更新数据的节点追数据的时间,增加该时间能最大限度的减少需要
rollback 的数据,但可能增加整个 failover 的时间,该选项只能在
protocolVersion 为1时使用。

mkdir -p ./data/shard/s0 ./data/shard/s1 #创建数据目录
mkdir -p ./data/shard/log # 创建日志目录
./bin/mongod --port 27017 --dbpath /usr/local/mongodb/data/shard/s0 --fork --logpath /usr/local/mongodb/data/shard/log/s0.log # 启动Shard Server实例1
./bin/mongod --port 27018 --dbpath /usr/local/mongodb/data/shard/s1 --fork --logpath /usr/local/mongodb/data/shard/log/s1.log # 启动Shard Server实例2

支持 Linearizable Read Concern

“linearizable” Read Concern 级别保证,一定能读到 WriteConcern 为
majority,并且确认时间在读请求开始之前的数据,该级别仅在查询结果只有单个文档的情况下有效。

步2.骤二: 启动Config Server

Decimal Type

MongoDB 3.4 新增对decimal128 format的支持,最多支持34位小数位。

跟 Double 类型不同,decimal
数据存储的是实际的数据,无精度问题,以9.99为例,decimal
NumberDecimal(“9.99″) 的值就是9.99; 而 Double 类型的9.99则是一个大概值
9.9900000000000002131628….

mkdir -p ./data/shard/config #创建数据目录
./bin/mongod --port 27027 --dbpath /usr/local/mongodb/data/shard/config --fork --logpath /usr/local/mongodb/data/shard/log/config.log #启动Config Server实例

Aggregation

MongoDB 在3.4版本增加了大量的 aggregation
操作符,功能更加强大了,举几个例子

bucket 能对方便的对数据进行分类
$grahpLookup 在 3.2的$lookup
的基础上更进一步,能支持更复杂的关系运算了。
$addFields 使得文档操作更丰富了,比如将某些字段求和存储为新的字段。
详细的介绍请参考Aggregation部分

注意,这里我们完全可以像启动普通mongodb服务一样启动,不需要添加—shardsvr和configsvr参数。因为这两个参数的作用就是改变启动端口的,所以我们自行指定了端口就可以
3.步骤三: 启动Route Process ./bin/mongos --port 4000 --configdb localhost:27027 --fork --logpath /usr/local/mongodb/data/shard/log/route.log --chunkSize=1 # 启动Route Server实例mongos启动参数中,chunkSize这一项是用来指定chunk的大小的,单位是MB,默认大小为200MB,为了方便测试Sharding效果,我们把chunkSize指定为
1MB。意思是当这个分片中插入的数据大于1M时开始进行数据转移
4.步骤四: 配置Sharding

Collation and Case-Insensitive Indexes

MongoDB 3.4 开始支持
collation,在之前的版本里,文档里存储的字符串,不论是中文还是英文,不论大小写,一律按字节来对比,引入
collation 后,支持对字符串的内容进行解读,可以按使用的 locale
进行对比,也支持对比时忽略大小写。

create、createIndexes、find、aggregate 等涉及字符串操作的命令都支持
collation。

# 我们使用MongoDB Shell登录到mongos,添加Shard节点
./bin/mongo admin --port 40000 #此操作需要连接admin库
> db.runCommand({ addshard:"localhost:27017" }) #添加 Shard Server 或者用 sh.addshard()命令来添加,下同;
{ "shardAdded" : "shard0000", "ok" : 1 }
> db.runCommand({ addshard:"localhost:27018" })
{ "shardAdded" : "shard0001", "ok" : 1 }
> db.runCommand({ enablesharding:"test" }) #设置分片存储的数据库
{ "ok" : 1 }
> db.runCommand({ shardcollection: "test.users", key: { id:1 }}) # 设置分片的集合名称。且必须指定Shard Key,系统会自动创建索引,然后根据这个shard Key来计算
{ "collectionsharded" : "test.users", "ok" : 1 }
 > sh.status(); #查看片的状态
 > printShardingStatus(db.getSisterDB("config"),1); # 查看片状态(完整版);
 > db.stats(); # 查看所有的分片服务器状态

视图(Views)

MongoDB
3.4里增加了对只读视图的支持,视图将集合里满足某个查询条件的数据虚拟成一个特殊的集合,用户可以在特殊的集合上做进一步的查询操作。

注意这里我们要注意片键的选择,选择片键时需要根据具体业务的数据形态来选择,切不可随意选择,实际中尤其不要轻易选择自增_id作为片键,除非你很清楚你这么做的目的,具体原因我不在此分析,根据经验推荐一种较合理的片键方式,“自增字段+查询字段”,没错,片键可以是多个字段的组合。
另外这里说明一点,分片的机制:mongodb不是从单篇文档的级别,绝对平均的散落在各个片上,
而是N篇文档,形成一个块”chunk”,优先放在某个片上,
当这片上的chunk,比另一个片的chunk区别比较大时(>=3)
,会把本片上的chunk,移到另一个片上,
以chunk为单位,维护片之间的数据均衡。
也就是说,一开始插入数据时,数据是只插入到其中一块分片上的,插入完毕后,mongodb内部开始在各片之间进行数据的移动,这个过程可能不是立即的,mongodb足够智能会根据当前负载决定是立即进行移动还是稍后移动。
在插入数据后,立马执行db.users.stats();两次可以验证如上所说。
这种分片机制,节省了人工维护成本,但是由于其是优先往某个片上插入,等到chunk失衡时,再移动chunk,并且随着数据的增多,shard的实例之间,有chunk来回移动的现象,这将会为服务器带来很大的IO开销,解决这种开销的方法,就是手动预先分片;

安全提升(Security Enhancement)

MongoDB 3.4
支持轮转的将复制集、或分片集群的各个节点开启鉴权,不需要停服务,详细步骤参考Enforce
Keyfile Access Control in a Replica Set without Downtime

手动预先分片 以shop.user表为例:

工具(MongoDB Tools)

MongoDB 3.4 引入 mongoreplay 工具,可用于监控并记录 mongod
上执行的命令并 replay 到另一个 mongod 实例上,该工具可用于代替
mongosniff。

sh.shardCollection(‘shop.user',{userid:1}); # user表用userid做shard key
for(var i=1;i<=40;i++) { sh.splitAt('shop.user',{userid:i*1000}) } # 预先在1K 2K...40K这样的界限切好chunk(虽然chunk是空的), 这些chunk将会均匀移动到各片上.

General Enhancements

支持 systemd
降低默认的 wiredtiger cache 配置
Changes Affecting Compatibility

可能影响兼容性的修改

升级步骤(Upgrade Procedures)

单节点升级到 3.4
复制集升级到 3.4
分片集群升级到 3.4

通过mongos添加user数据. 数据会添加到预先分配好的chunk上,
chunk就不会来回移动了.

repliction set and shard 一般mongoDB如果真的到了分片的级别后,那片服务器避无可免的要用到复制集,部署的基本思路同上,只需要注意两点:
sh.addShard( host ) server:port OR setname/server:port #
如果是复制集的片服务器,我们应该复制集的名称写在前面比如
sh.addShard(‘ras/192.168.42.168:27017’); #
27017也就是复制集中的primary
另外在启动本机的mongod服务的时候,最好把ip也给写进去,否则有可能会有不可预知的错误。