简介

MongMongo是一个用Java写的ODM框架，使得对MongoDB的操作更加便捷。

MongoMongo努力为Java开发者提供类似于ActiveORM 或者 Hibernate的操作API,并且保留了MongoDB的schemaless，document-based 设计,动态查询,原子修改操作等特性。当然你可以很方便的绕开MongoMongo而使用Java Driver 原生提供的功能。




示例代码



public class Blog extends Document {  
    static {  
        storeIn("blogs");                  
        hasManyEmbedded("articles", new Options(map(  
                Options.n_kclass, Article.class  
        )));  
        //create index  
        index(map("blogTitle", -1), map(unique,true));  
        //validate uerName field  
        validate("userName",map(length,map(  
                minimum,5  
        )));  

    }  
    //association related  
    public AssociationEmbedded articles() {throw new AutoGeneration();}  
    private String userName;  
    private String blogTitle;  
}  

public class Article extends Document {  
    static {          
        belongsToEmbedded("blog", new Options(map(  
                Options.n_kclass, Blog.class  
        )));  
    }  
    public AssociationEmbedded blog() {throw new AutoGeneration();}  
    private String title;  
    private String body;  
}  

public class Usage{  
  public static void main(String[] args){  

     Blog blog = Blog.where(map("userName","sexy java")).in(map("id",list(1,2,3))).singleFetch();  
     blog.articles().build(map("title","i am title","body","i am body"));  
     blog.save();  
  }  

}  


从上面代码中能够学习到关联，存储，创建索引，设置别名等操作都简单的在static 块中调用一个函数即可实现。




和Spring-data对比

Spring-data的写法为




public static void main( String[] args )  
   {  
       MongoOperations mongoOps = new MongoTemplate(new Mongo(), "mydb");  
       Person person = new Person();  
       person.setName("Joe");  
       person.setAge(10);  
       mongoOps.insert(person);  
       log.info(mongoOps.findOne(new Query(Criteria.where("name").is("Joe")), Person.class));  
   }  



而MongoMongo写法为




public static void main( String[] args )  
 {  
     Person person =  Person.create(map("name","Joe","age",34));  
     person.save();  
     log.info(Person.where(map("name","Joe")).singleFetch());   
 } 


从上面能够看出Spring-dat为了构造查询串引入Criteria对象，为了进行查询引入Query对象,查询时还要申明Person对象等，而MongoMongo写的比较简单而且清晰。




总结

针对MongoDB非关系型数据库的操作框架有很多，在项目中也可以选择合适项目的比较关系，通过对比之后单独使用MongoMongo在代码易用性和清晰度上占优势，而其他的可能和其他框架集成上有优势，所以需要用到的时候做出正确的判断就可以了。

虽然可以用阿里云自带的dts 并且也是免费的，但是万一后续没有用阿里云或者换工具了咋办。所以还是尝试学习使用一下工具迁移。工具也是阿里开源的  哈哈哈
下载mongoshake
# 建议下载最新版本 https://github.com/alibaba/MongoShake/releases?spm=a2c4g.11186623.2.21.5f006ed2c3KAD0
# 但是新版本的可能会出现version GLIBC_2.14 not found
mkdir -p /srv/mongoshake 
cd  /srv/mongoshake
wget https://github.com/alibaba/MongoShake/releases/download/release-v2.0.7-20190817/mongo-shake-2.0.7.tar.gz
# 百度网盘地址 链接:https://pan.baidu.com/s/1lJGIb93R3oK30FxgTHbYmQ  密码:643n

解压mongoshake
cd /srv/mongoshake
tar zxvf mongo-shake-2.0.7.tar.gz

修改配置文件




参数
说明
示例值
备注




mongo_urls
源端MongoDB实例的ConnectionStringURI格式连接地址。
mongo_urls = mongodb://root:Ftxxxxxx@dds-bpxxxxxxxx.mongodb.rds.aliyuncs.com:3717,dds-bpxxxxxxxx.mongodb.rds.aliyuncs.com:3717
这里能用内网地址就用内网地址


tunnel.address
目标端MongoDB实例的ConnectionStringURI格式连接地址。
tunnel.address = mongodb://root:Ftxxxxxx@dds-bpxxxxxxxx.mongodb.rds.aliyuncs.com:3717,dds-bpxxxxxxxx.mongodb.rds.aliyuncs.com:3717
可以直接在阿里云mongo集群的信息里 复制黏贴


sync_mode
数据同步的方式，取值：
all：执行全量数据同步和增量数据同步。
document：仅执行全量数据同步。
oplog：仅执行增量数据同步。
sync_mode = all
默认值为oplog，但是我这边第一次同步选all 同步失败了，所以还是先全量再增量


replayer.dml_only
是否仅同步DML操作，取值：
false：同步DML操作和DDL操作。
true：仅同步DML操作。
replayer.dml_only = false
默认取值为true


filter.namespace.black
指定数据同步的黑名单，这些指定的命名空间不会被同步至目标数据库，多个命名空间用英文分号（;）分隔。

默认为空 不需要修改


filter.namespace.white
指定数据同步的白名单，只有这些指定的命名空间会被同步至目标数据库，多个命名空间用英文分号（;）分隔。

默认为空 不需要修改


启动mongoshake
我这里选择all模式 会出现失败的情况  所以采用了全量+增量 2步分开的方式 失败报错如下。

./collector -conf=collector.conf -verbose

进度条如下。 并不是实时更新的样子。100G左右数据 只能根据磁盘空间 判断是否同步。



数据最终全量同步过去了，但是最后还是出现了飞机坠机 哈哈哈。count了一下 数据量是对的，没有影响。
给自己做个笔记 万一下次用的上呢。
参考阿里云手册
https://www.alibabacloud.com/help/zh/doc-detail/122621.htm

 

关于MongoShake项目说明：

https://github.com/alibaba/MongoShake/wiki

MongoShake发行版下载：

https://github.com/alibaba/MongoShake/releases

MongoShake遇到的问题FAQ：

https://github.com/alibaba/MongoShake/wiki/FAQ

 

安装
项目相关软件包路径为/root/MongoShake，部署之前确保目标端实例已使用源端实例全备mongodump文件进行还原,MongoShake是通过抽取源端oplog应用到目标端以达到增量的同步，利用的是oplog中DML操作的幂等特性，部署项目需要用到的组件有：

 

1.go go1.12.5(二进制)

2.MongoShake 2.0(源码包)或MongoShake 2.0(二进制)

 

go的安装

MongoShake是基于go语言进行开发的，在进行源码编译的时候需要go的运行环境。本例的go语言环境配置使用的是二进制包方式。如果使用的MongoShake二进制包，解压即可得到MongoShake执行命令，则无需要安装go环境。

 

二进制包下载
# wget https://dl.google.com/go/go1.12.5.linux-amd64.tar.gz

 

解压
# tar zxf go1.12.5.linux-amd64.tar.gz

# cp go /usr/local/go1.12 –ra

 

配置环境变量
# vim /etc/profile.d/go.sh

添加配置：

export GOROOT=/usr/local/go1.12

export GOPATH=/go

export PATH=/go/bin:$GOROOT/bin:$PATH

 

配置生效：

# . /etc/profile.d/go.sh

 

查看当前go环境
# go version

go version go1.12.5 linux/amd64

至此，go语言环境安装完成。

 

MongoShake的安装(源码)

因为MongoShake的项目源码是放在github上的，所以获取源码的方式可以通过git进行，也可以到项目地址下载zip源码压缩包。

 

Git安装
首先确保安装了git，如果没有安装则使用yum进行安装。

 

# git version

git version 2.21.0

 

yum安装git：

# yum install git -y

 

源码包获取
因为国内环境访问github的速度较慢，所以可以先修改hosts文件，通过绑定host的方式来访问，可以加快对github访问的速度。

 

# vim /etc/hosts

文末添加：

151.101.44.249 github.global.ssl.fastly.net

192.30.253.113 github.com

103.245.222.133 assets-cdn.github.com

23.235.47.133 assets-cdn.github.com

203.208.39.104 assets-cdn.github.com

204.232.175.78 documentcloud.github.com

204.232.175.94 gist.github.com

107.21.116.220 help.github.com

207.97.227.252 nodeload.github.com

199.27.76.130 raw.github.com

107.22.3.110 status.github.com

204.232.175.78 training.github.com

207.97.227.243 www.github.com

185.31.16.184 github.global.ssl.fastly.net

185.31.18.133 avatars0.githubusercontent.com

185.31.19.133 avatars1.githubusercontent.com

192.30.253.120 codeload.github.com

 

注意每行行尾不能出现空格，否则绑定的host不生效！

 

获取源代码：

# mkdir /go/src/github.com/

# cd /go/src/github.com/

# git clone https://github.com/alibaba/MongoShake.git

Cloning into 'MongoShake'...

remote: Enumerating objects: 60, done.

remote: Counting objects: 100% (60/60), done.

remote: Compressing objects: 100% (49/49), done.

remote: Total 1341 (delta 14), reused 29 (delta 10), pack-reused 1281

Receiving objects: 100% (1341/1341), 18.56 MiB | 24.00 KiB/s, done.

Resolving deltas: 100% (694/694), done.

 

依赖包安装
 

MongoShake使用的是govendor解决依赖包问题，在编译MongoShake之前需要确认依赖包都已安装，而首先安装的是govendor。

 

# go get -u github.com/kardianos/govendor

# govendor -version

v1.0.9

 

govendor安装完成之后，开始安装MongoShake的依赖包。

 

# GOPATH= /go/src/github.com/MongoShake/

# cd /go/src/github.com/MongoShake/src/vendor

# govendor sync

 

编译
 

依赖包安装完成之后，则可以开始进行编译了。

 

# cd /go/src/github.com/MongoShake/

# ./build.sh

[ BUILD RELEASE ]

Build collector

mongoshake/collector/configure

vendor/github.com/eapache/queue

vendor/github.com/vinllen/log4go

vendor/github.com/gugemichael/nimo4go

vendor/github.com/vinllen/mgo/internal/json

vendor/github.com/vinllen/mgo/internal/scram

vendor/github.com/nightlyone/lockfile

vendor/github.com/davecgh/go-spew/spew

vendor/github.com/eapache/go-resiliency/breaker

vendor/github.com/golang/snappy

vendor/github.com/vinllen/mgo/bson

vendor/github.com/eapache/go-xerial-snappy

vendor/github.com/pierrec/lz4/internal/xxh32

vendor/github.com/pierrec/lz4

vendor/github.com/rcrowley/go-metrics

vendor/github.com/vinllen/mgo

mongoshake/oplog

vendor/github.com/Shopify/sarama

mongoshake/common

mongoshake/dbpool

mongoshake/collector/ckpt

mongoshake/executor

mongoshake/quorum

mongoshake/tunnel/kafka

mongoshake/tunnel

mongoshake/modules

mongoshake/collector

command-line-arguments

develop,7858a69529c89b04207a9913df7ac0e082b256af,release,go1.12.5,2019-06-19_13:19:39

Build receiver

mongoshake/receiver/configure

mongoshake/receiver

command-line-arguments

develop,7858a69529c89b04207a9913df7ac0e082b256af,release,go1.12.5,2019-06-19_13:19:39

 

至此，MongoShake编译完成。

 

MongoShake的安装(二进制)

因为获取依赖包访问github的速度很慢，所以项目也提供了编译好的二进制包，二进制包会使用相对比较稳定的源码进行编译，如果允许的话还是使用源码包进行编译。

 

二进制下载
# wget https://github.com/alibaba/MongoShake/releases/download/release-v2.0.0-20190619/mongoshake-2.0.tar.gz

 

解压
# tar zxf mongoshake-2.0.tar.gz -C /go/src/github.com/MongoShake-2.0

# ls /go/src/github.com/MongoShake-2.0/

ChangeLog  collector  collector.conf  hypervisor  mongoshake-stat  receiver  start.sh  stop.sh

 

至此，MongoShake的配置就完成了。

 

配置
MongoShake同步任务配置根据原先项目的设计做了自定义配置，采用每个项目对应一个目录的方式进行，这样可以方便管理与维护，可以参考已成功完成迁移的实例bbs进行修改，本例以bbs配置进行修改演示，由于之前bbs项目是基于MongoShake 1.4.6版本完成的，collector配置文件与2.0稍有不同，可以参照2.0版本进行修改。

 

查看bbs对应目录结构

# tree /go/src/github.com/MongoShake/bbs/ -L 1

/go/src/github.com/MongoShake/bbs/

 

├── bbs_collector

├── bbs.conf

├── bbs_start.sh

├── bbs_stop.sh

├── diagnostic

└── logs

 

其中：

bbs_collector：MongoShake拉取oplog的主执行程序，通过默认collector复制重命名得到；

bbs.conf：MongoShake配置文件，针对bbs的配置；

bbs_start.sh：项目启动的shell脚本，结合默认的hypervisor启动项目；

bbs_stop.sh：项目停止的shell脚本；

logs：存放hypervisor日志和bbs_collector运行日志。

 

配置项目目录

本例以ask项目为例。

# mkdir -pv /go/src/github.com/MongoShake-2.0/ask/logs

# cd /go/src/github.com/MongoShake-2.0/ask

 

拷贝BBS相应的文件，并重命名。

 

# cp ../../MongoShake/bbs/bbs*  /go/src/github.com/MongoShake-2.0/ask

# mv bbs_collector  ask_collector

# mv bbs.conf  ask.conf

# mv bbs_start.sh  ask_start.sh

# mv bbs_stop.sh  ask_stop.sh

 

配置文件修改

修改ask.conf配置文件，也可以基于MongoShake 2.0版本默认的配置文件进行修改。

 

为了便于说明，先去除相应的注释与空行。

 

# cat ask.conf | grep -v "^$" | grep -v "^#"

mongo_urls = mongodb://root:sdfsdfsdf@10.10.111.1:27018,10.10.111.2:27230 #源端

collector.id = askSet

sync_mode = oplog

checkpoint.interval = 5000

http_profile = 20230

system_profile = 20231

log_level = info

log_file = askSet.log

log_buffer = true

filter.namespace.black =

filter.namespace.white =

oplog.gids =

shard_key = collection

syncer.reader.buffer_time = 1

worker = 1

worker.batch_queue_size = 32

adaptive.batching_max_size = 8192

fetcher.buffer_capacity = 128

worker.oplog_compressor = none

tunnel = direct

tunnel.address = mongodb://root:csdfsdfsdfsd@172.20.16.1:27017 #目标端

context.storage = database

context.address = ckpt_default

context.start_position = 2019-06-18T09:20:00Z

master_quorum = false

transform.namespace =

dbref = false

replayer.dml_only = false

replayer.executor = 1

replayer.executor.upsert = true

replayer.executor.insert_on_dup_update = true

replayer.conflict_write_to = none

replayer.durable = true

replayer.collection_parallel = 3

replayer.document_parallel = 4

replayer.document_batch_size = 256

replayer.collection_drop = false

 

主要配置选项如下：

 

mongo_urls：配置源端实例mongodb连接信息，如果是副本集，将所有mongodb节点都写上，格式如上；

collector.id：项目进程名称，能唯一标识即可；

sync_mode：同步模式，2.0开始支持全量+增量，默认为oplog，即增量，对于一些较小的实例可以采用all方式；

http_profile：项目进程监控端口，确保唯一即可；

system_profile：项目进程监控端口，确保唯一即可；

log_file：collector日志文件名称，会在logs目录下生成;

tunnel.address：目标端mongodb实例连接信息，格式如上；

context.start_position：开始读取oplog的时间点，是UTC格式，比CST晚8小时，即开始同步时间需要比生成mongodump全备文件早8个小时开始同步，才能确保在oplog增量同步时覆盖mongodump备份这段时间的操作；

replayer.dml_only：是否只同步DML，如果需要同步DDL，则指定选项false。

 

配置文件其他选项保持默认就可以。

 

启动文件修改

修改ask_start.sh文件。

 

# vim ask_start.sh

 

 

#catalog=$(dirname "$0")

#cd "${catalog}"/../ || exit 1

if [ $# != 1 ] ; then

        echo "USAGE: $0 [conf]"

        exit 0

fi

 

# conf

hypervisor_path="/go/src/github.com/MongoShake-2.0/hypervisor"

collector_path="/go/src/github.com/ MongoShake-2.0/ask/ask_collector"

conf_path="/go/src/github.com/ MongoShake-2.0/ask/ask.conf"

logs_dir="/go/src/github.com/ MongoShake-2.0/ask/logs/"

task_name="askSet_collector"

 

if [ "Darwin" == "$(uname -s)" ];then

        printf "\\nWARNING !!! MacOs doesn't supply to use this script, please use \"./%s -conf=config_file_name\" manual command to run\\n" "$nam

e"

    exit 1

fi

 

GOMAXPROCS=0

 

if [ $GOMAXPROCS != 0 ] ; then

        ${hypervisor_path} --daemon --exec="GOMAXPROCS=$GOMAXPROCS ${collector_path} -conf=$1 2>&1 1>> $task_name.output" 1>>${logs_dir}hypervisor

.output 2>&1

else

        ${hypervisor_path} --daemon --exec="${collector_path} -conf=$1 2>&1 1>> $task_name.output" 1>>${logs_dir}hypervisor.output 2>&1

Fi

 

其中涉及修改的选项如下，配置参考以上说明：

 

hypervisor_path：hypervisor路径，以项目默认为主；

collector_path=：ask对应的collector执行文件；

conf_path=：ask对应的配置文件；

logs_dir=：ask对应的日志文件路径；

task_name=：ask任务名称。

 

 

至此，ask项目配置已完成。

 

开启同步
本例中ask项目源端开始mongodump生成全备文件时的时间为：

 

2019-06-18T17:24:25.699+0800

 

所以ask配置的oplog同步时间为：

 

2019-06-18T09:20:00Z

 

在确保ask mongodump全备文件通过mongorestore还原至目标端实例成功完成之后，使用shell启动文件开始进行同步。

 

# cd /go/src/github.com/ MongoShake-2.0/ask/

# ./ask_start.sh ask.conf

 

查看ask_collector日志状态。

 

[2019/06/19 15:35:22 CST] [INFO] [common.(*ReplicationMetric).startup.func1:137] [name=askReplset, filter=2, get=211, consume=209, apply=209, failed_times=0, success=209, tps=0, ckpt_times=0, retransimit_times=0, tunnel_traffic=29KB, lsn_ckpt={0,1970-01-01 08:00:00}, lsn_ack={1560929701,2019-06-19 15:35:01}]

[2019/06/19 15:35:23 CST] [INFO] [collector.(*OplogSyncer).calculateWorkerLowestCheckpoint:122] worker offset [6704142017150058497] use lowest 6704142017150058497

[2019/06/19 15:35:23 CST] [INFO] [executor.(*Executor).doSync:231] Replayer-0 Executor-0 doSync oplogRecords received[1] merged[1]. merge to 100.00% chunks

[2019/06/19 15:35:23 CST] [INFO] [collector.(*Worker).transfer:179] Collector-worker-0 transfer retransmit:false send [1] logs. reply_acked [6704142107344371713], list_unack [0]

[2019/06/19 15:35:23 CST] [INFO] [ckpt.(*MongoCheckpoint).Insert:179] Record new checkpoint success [1560929701]

[2019/06/19 15:35:23 CST] [INFO] [collector.(*OplogSyncer).checkpoint:54] CheckpointOperation write success. updated from 6704125962562306050(1560925963) to 6704142017150058497(1560929701)

[2019/06/19 15:35:27 CST] [INFO] [common.(*ReplicationMetric).startup.func1:137] [name=askReplset, filter=3, get=213, consume=210, apply=210, failed_times=0, success=210, tps=0, ckpt_times=1, retransimit_times=0, tunnel_traffic=29KB, lsn_ckpt={1560929701,2019-06-19 15:35:01}, lsn_ack={1560929722,2019-06-19 15:35:22}]

[2019/06/19 15:35:30 CST] [INFO] [collector.(*OplogSyncer).calculateWorkerLowestCheckpoint:122] worker offset [6704142107344371713] use lowest 6704142107344371713

[2019/06/19 15:35:30 CST] [INFO] [executor.(*Executor).doSync:231] Replayer-0 Executor-0 doSync oplogRecords received[1] merged[1]. merge to 100.00% chunks

 

查看运行监控端口状态。

 

# netstat -lntup | grep ask

tcp6       0      0 :::20231                :::*                    LISTEN      5312/ask_collector

tcp6       0      0 :::20230                :::*                    LISTEN      5312/ask_collector

 

从collector日志可以看出实时的oplog增量检查点checkpoint，而这个checkpoint信息由MongoShake默认创建mongoshake数据库和ckpt_default集合来记录，记录的是当前增量同步oplog位置的时间信息。

 

cmsReplset:SECONDARY> db.ckpt_default.find()

{ "_id" : ObjectId("5d09f22ccee40923c7e59a50"), "name" : "cmsReplset", "ckpt" : Timestamp(1560931886, 3) }

 

停止同步
使用ask_stop.sh文件停止ask项目的同步。

 

# ./ask_stop.sh askSet.pid

 

数据量校验
为了校验MongoDB同步后各个数据库中集合文档数，这里编写了一个shell脚本mongodb_compare.sh，脚本已同步到DBA SVN中迁移百度云文件夹下，使用方法可以通过直接运行脚本文件得到。

 

# ./mongodb_compare.sh

 USAGE:./mongodb_compare.sh 'src_MongoDB_Primary_ip:port' 'dst_MongoDB_Primary_ip:port' [db_name for check...]

 Example: ./mongodb_compare.sh '192.168.58.3:27017' '172.20.3.6:27017' [db_name,[db_name]...]

 

这里演示校验ask实例源端和目标端集合文档数。

 

首先需确认当前mongoshell执行命令mongo的绝对路径，并修改脚本中涉及mongo命令的地方，假设当前mongo命令的绝对路径为/usr/local/mongodb3.4/bin/mongo，则修改mongodb_compare.sh脚本中涉及mongo命令处，并保存。如下：

 

src_conn="/usr/local/mongodb3.4/bin/mongo $src_ins -u$src_user -p$src_pwd --quiet --authenticationDatabase admin -eval "

dst_conn="/usr/local/mongodb3.4/bin/mongo $dst_ins -u$dst_user -p$dst_pwd --quiet --authenticationDatabase admin -eval "

 

运行脚本进行校检。（脚本见下一篇推文）

 

# ./mongodb_compare.sh '10.10.111.1:27017' '172.20.16.1:27017'

Enter the src_ins:10.10.111.1:27017 conn user: root       # 输入源端实例连接用户

Enter the src_ins:10.10.111.1:27017 user password:        # 输入源端实例连接用户密码

Enter the dst_ins:172.20.16.1:27017 conn user: root        # 输入目标端实例连接用户

Enter the dst_ins:172.20.16.1:27017 password:              # 输入目标端实例连接用户密码

 

10.10.111.1:27017 <----------> 172.20.16.1:27017

==============================================================

DB:cms

autoincre_system docs: 3 <----------> 3

cms_mall_product docs: 3824 <----------> 3824

pageslog docs: 58043 <----------> 58043

pageslog_list docs: 58043 <----------> 58043

 system.indexes docs: 7 <----------> 0 different!

 system.profile docs: 1701 <----------> 0 different!

system.users docs: 2 <----------> 2

test docs: 1 <----------> 1

==============================================================

DB:test

 system.indexes docs: 2 <----------> 0 different!

system.profile docs: 0 <----------> 0

t docs: 3 <----------> 3

test docs: 1 <----------> 1

==============================================================

DB:OpenPlatform

a docs: 0 <----------> 0

app_log_10 docs: 450904 <----------> 450904

app_log_11 docs: 406611 <----------> 406611

app_log_12 docs: 160810 <----------> 160810

app_log_5 docs: 1324893 <----------> 1324893

app_log_6 docs: 965174 <----------> 965174

app_log_7 docs: 855134 <----------> 855134

app_log_8 docs: 715728 <----------> 715728

app_log_9 docs: 639511 <----------> 639511

auth_info docs: 247083 <----------> 247083

feedback docs: 49 <----------> 49

qdms docs: 0 <----------> 0

 system.indexes docs: 13 <----------> 0 different!

 system.profile docs: 1748 <----------> 0 different!

user_session docs: 24200 <----------> 24200

 

如果有文档数不同的集合则脚本通过红色显示，如果只是system集合红色显示，代表正常，因为system集合是不做同步的，所以其他集合出现红色时则证明两端集合的文档数不一致。在确保源端与目标端实例除system集合外所有集合的文档数一致后则表明数据一致。

 

当源端集合文档数与目标端不一致时，则以源端数据为主进行修复。主要修复步骤：

 

首先停止MongoShake对应项目的同步；
	
源端使用mongodump导出不一致的文档；
	
目标端通过mongorestore还原不一致的文档；
	
重新开启MongoShake对应项目的同步。
 

导出文档命令：

 

# mongodump -h 10.10.111.1 --port 28230 -uroot –p’root_password’ --authenticationDatabase admin –d cms –c pageslog –o ./cms_pageslog

 

导入文档命令：

 

# mongorestore -h 172.20.16.1 --port 27017 -uroot -p’root_password’ --authenticationDatabase admin -d cms -c pageslog  --drop  ./pageslog.bson

 

用户迁移
如果源实例的admin数据库包含名为root的用户，并且该root用户为实例对应的拥有root角色超级权限的用户，则在使用mongorestore进行还原恢复至百度云mongodb实例时不能包括admin数据库，这会导致百度云实例上超级用户被修改，导致百度云后台技术错误，所以关于用户的迁移只能通过查找数据库连接配置文件对应项目中实例的连接用户，然后在百度云实例上admin或者相应数据库手动创建用户。

 

摘要

mongo 的索引非常强大，和关系型数据库索引没什么区别。这里主要介绍mongo索引基本知识和mongo本人在索引上的犯的错。



索引种类

单字段索引
复合索引 
复合索引各个字段的顺序应该是精确匹配字段(=xxx),排序字段(避免在内存中排序，使用index排序)，范围查询字段

如db.book.find({company: ‘xxx’, age:{$lt:30}).sort({name:1}) 
db.book.find().explain("executionStats")可以很好的列出查询执行计划。 

总共有四个重要参数： 

executionTimeMills：查询执行的时间 

nReturned: 返回的文档数 

totalKeysExamined: 索引扫描数 

totalDocsExamined: 文档扫描数

当然希望nReturned数目=totalKeysExamined 

不扫描文档。（后面不挂着数据，index及数据）

或者nReturned = totalKeysExamined = totalDocsExamined 

如果有排序，为了不让排序在内存中进入，在nReturned = totalDocsExamined的基础上，totalKeysExamined可以大于nReturned。对于大数据量的内存排序会非常消耗性能

如果我们创建一个复合索引是db.book.ensureIndex({company:1,age:1,name:1}) 

这时候nReturned = totalKeysExamined = totalDocsExamined 

。因为查询会用到index，不需要额外的文档扫描。但是会有SORT stage,即在内存中排序,在大数据量的情况下内存排序是很慢的。

尝试加一个index，在排序字段放在扫描字段前面 

db.book.ensureIndex({company:1,name:1,age:1}) 
这时候发现mongo选择了新的index

 "indexBounds" : {
         "company" : [
                 "[\"a\", \"a\"]"
         ],
         "name" : [
                 "[MinKey, MaxKey]"
         ],
         "age" : [
                 "[-1.#INF, 30.0)"
         ]
 },

且执行计划中有reject SORT排序

"rejectedPlans" : [
        {
                "stage" : "SORT",
                "sortPattern" : {
                        "name" : 1
                },


这时候nReturned = totalDocsExamined < totalKeysExamined 多扫描了index，但是是值得的。这也是为什么在开始的时候时候说联合index的字段排序顺序是精确匹配字段(=xxx),排序字段(避免在内存中排序，使用index排序)，范围查询字段 

如{name:1,address:1}，包含的是两个查询

db.book.find({name:"xxx"})
db.book.find({name:"xxx",address:"xxx"})

但是如果你的查询不是范围查询。而是精确匹配字段。那还是使用原来的index。因为这时候排序字段用到了index查询，不需要SORT阶段了

db.book.find({company:'a',age:30}).sort({name:1}).explain("executionStats")
 "indexBounds" : {
         "company" : [
                 "[\"a\", \"a\"]"
         ],
         "age" : [
                 "[30.0, 30.0]"
         ],
         "name" : [
                 "[MinKey, MaxKey]"
         ]
 },

多键索引 

如array索引 
https://docs.mongodb.com/manual/core/index-multikey/

多键索引是没法查一个数组全部匹配的，会先查第一个元素，后面的会使用filter
$elemMatch
son:{ $elemMatch:{$gt:9,$lt:11}} 这个查询和son:{$gt:9,$lt:11}的区别， 

后者是只要数组中任意一个字段满足其他一个条件即可，比如第一个字段满足gt:9,第二个字段满足lt:11那么也认为是满足条件。所以使用索引时，只能使用到一个边界条件。

在联合索引中只允许有一个array字段。但是因为mongo是free schema的。可以是不同的字段，只要一个document中只有一个array就行了,在不同的document中可以是不同字段
唯一索引 

db.book.createIndex({“name”:1},{“unique”:true}) 

mongo 默认创建的不是唯一索引，需要显示指定。唯一索引会对数据进行校验，不允许重复数据。
sharding cluster 索引 

索引是在各个shard上面单独建立的，不是全局的。 

sharding cluster 环境，只允许_id,和shard key建立unique index.因为unique index 需要shard 之间通信，违背了shard 设计理念。所以需要避免
注意

当一个collection上面有多个index 

    某个查询可能命中多个index，这时候mongo是如何选择索引的呢。

首先mongo会对某类类似查询语句在可能命中的index都执行一遍，并行执行的，最早返回100个结果找出最优的index，然后记住这类查询所用到的索引。以后查询操作就使用这个索引。当有index更改时，再去更改这个值。

当有一个复合索引 

{name:1,address:1,email:1}

这时候有一个新的查询{name:xxx,address:xxx,phone:xxx} 

可以用到已经创建的复合索引。这时候你会不会单独在创建一个索引呢。 

优势是这个查询也很快，缺点是多了一个index，减弱了插入性能。

这个可能需要衡量前两个字段过滤掉了多少数据，phone这个字段占剩下数据量的多少来决定需要创建什么样的index.
mongo 中有一个名字叫scalar(标量字段)就是非array,非embedded document这样的字段。针对这些字段的索引与关系型数据库并无差别，无需特殊处理 

觉得这篇分享就有点过于强调阅读mongo源码来解决的问题的重要性，因为这个就可以通过上述分析找到root cause 
https://yq.aliyun.com/articles/74635?utm_campaign=wenzhang&utm_medium=article&utm_source=QQ-qun&201752&utm_content=m_19216
array index

mongo 可以对array建立index,注意是将index中的每个元素都作为index key,进行索引。所以对array建立index一定要十分小心，很容易导致index size 很大。另外mongo支持指定array某一列进行查询。



test.book
{
    _id:1,
    name:english,
    address:[addr1,addr2]
}

db.book.find({“address.0”:”addr1”}) 
当对address创建index,这样的查询是用不到index的。只有基于array的查询，index才能有效。 

mongo并没有那么神奇的在创建index的同时还保留列数。



shard key index

表中有数据 

表中有数据再创建shard key,需要首先创建对应的index,才能去创建shard key
表中无数据 

表中无数据，创建shard key的同时,mongo会自动创建一个对应字段的index
sh.shardCollection("test.book",{name:1,address:1})

会自动创建index



{name:1,address:1}



mongo index VS cassandra secondary index

1.query 过程 

cassandra query,首先根据partitioner key去找对应partition,partition中的数据是按照clustering key排序的。注意是按照clustering key排序的，clustering key这个字段 不是index。

mongo(sharding cluster) query,首先根据给定的shard key去找在哪个节点上，然后将请求发送到此节点。进行查找。 

如果你的query case是



db.book.find({name:"xxx",address:"xxx"})

而shard key是name。此外再单独为address建立一个index。这时候你的query其实是命中的address 的单字段index。而不是预想的已经将name数据过滤了。这点和cassandra有很大的不同

2.范围 

cassandra secondary index 是local的,在每个节点上。 
mongo 的index是全局的。 

mongo sharding cluster 环境，index也是在各个shard上独立创建的。



参考

http://www.mongoing.com/eshu_explain3