【Mongo】集群测试（容灾+查询+并发）

本文包括：

1. 测试环境
2. 集群测试（容灾）
3. 查询测试（效率）
4. 并发测试

环境：

    Mongo Version : 3.4.5 

    Linux Version : Red Hat 7.2  

    RAM : 24G(实例所在单台机器） 

    数据总量 : 50G（1000万条文章）

    集群：shard（rs0，rs1，rs2）三个分片复制集，config-server（复制集），mongos（两台）

一.集群测试（容灾测试）

1. 搭建一个2个分片（rs0，rs1）的集群，导入1000万数据分片信息如下 

   docSum	Shard	chunks	documents
   1001	rs0	2	498
   	rs1	2	503
   281824	rs0	29	141371
   	rs1	29	140453
   10208750	rs0	753	5287009
   	rs1	755	4921741

2.  往集群中插入一个新的分片rs2，chunk发生自动迁移，信息如下：

   docSum	Shard	chunks	documents
   10208750	rs0	503	3304079
   	rs1	503	3605501
   	rs2	502	3299171

   迁移时间较慢，可能和数据量有关，迁移过程中对用户透明，可以正常读写访问  

3. 人工停掉一个分片rs2，模拟一整个分片宕机，结果如下：
   1）分片（hash）到非宕机分片的读写操作都在正常进行；
   2）分片（hash）到宕机分片的读写操作都失败；
   3）集群的分片策略（hash）并没有将宕机分片剔除，分配（hash）的可能分片仍包括已宕机分片；
   4）分片重新启动后，集群恢复正常，但是宕机时间内，分配（hash）到宕机分片的写丢失，不过对于客户端来说这些丢失是可知的（比如java会抛出mongo写异常）；
   但是对于完整的分片集群来说，每个分片应该是包含一个primary，多个secondary的复制集，复制集全部宕机可能性较小，只有primary宕机10s后很快将选出新的primary来使集群回复正常。
4. 更有可能的情况是一个分片的primary宕机
   1）复制集将在10s后意识到primary宕机并和快选举出新的primary节点；
   2）在这十几秒未完成选举期间，如果开启了从secodary读，读不受影响，但是这个分片上的写操作将会失败

二.查询测试

    索引：

• _id 默认唯一索引
• _id_hashed 数据分片专用索引
• textIndex 文本搜索索引针对文章标题创建
• category_1__id_1 自建联合索引
• id__category_1 自建联合索引

结果：

1. 查询时间表

   序号	查询条件	First	Average Time
   1	id	17ms	20ms
   2	categoryId	44ms	80ms（20条文章）
   3	keywords	4s	160~800ms（5条数据）
   4	aggregation	148ms	120ms

   
   
2. 备注
   1、查询指定id的文章
   2、查看指定分类的按id排序的前20条文章
   3、文本索引，查询文章标题title字段，含有关键字得分最高的5条文章（相关性较高、关键字不分词，文章标题分词，Mongo一个集合只能建立一个文本索引，但是这个索引可以包含很多字段）
   4、聚合查询，查询每个分类的文章总数
3. 查询测试中并没有发现同一个集合上一个查询卡住会影响其他查询操作的情况

三.并发测试

    待补充...