软件测试|Mongodb的分页优化及索引使用

基于我们的数据特性，在进行数据库选型时选择了mongo数据库。在文档数量很大的情况下，存在慢查询，影响服务端性能。合理地对数据库命令及索引进行优化，可以很大幅度提升接口性能

mongo分页查询

在Java中使用mongodb的MongoTemplate进行分页时，一般的策略是使用skip+limit的方式，但是这种方式在需要略过大量数据的时候就显得很低效。

传统分页介绍

假设一页大小为10条。则：

//page 1
1-10

//page 2
11-20

//page 3
21-30
...

//page n
10*(n-1)+1-10*n

MongoDB提供了skip()和limit()方法。

skip: 跳过指定数量的数据. 可以用来跳过当前页之前的数据，即跳过pageSize*(n-1)。limit: 指定从MongoDB中读取的记录条数，可以当做页面大小pageSize。

所以，分页可以这样做：

//Page 1
db.getCollection('file').find({}).limit(10)

//Page 2
db.getCollection('file').find({}).skip(10).limit(10)

//Page 3
db.getCollection('file').find({}).skip(20).limit(10)
........

存在问题

官方文档对skip的描述：

skip方法从结果集的开头进行扫描后返回查询结果。这样随着偏移的增加，skip将变得更慢

The cursor.skip() method requires the server to scan from the beginning of the input results set before beginning to return results. As the offset increases, cursor.skip() will becomeslower.

所以，需要一种更快的方式。其实和mysql数量大之后不推荐用limit m,n一样。

官方建议使用范围查询，可以使用[索引]分页相比，偏移量增加时通常会产生更好的性能。即指定开始位置解决方案是先查出当前页的第一条，然后顺序数pageSize条。

指定范围分页介绍

我们假设基于_id的条件进行查询比较。事实上，这个比较的基准字段可以是任何你想要的有序的字段，比如时间戳。

//Page 1
db.getCollection('file').find({}).limit(pageSize);
//Find the id of the last document in this page
last_id =...

//Page 2
users =db.getCollection('file').find({
'_id':{"$gt":ObjectId("5b16c194666cd10add402c87")}
}).limit(10)

//Update the last id with the id of the last document in this page
last_id =...

显然，第一页和后面的不同。对于构建分页API, 我们可以要求用户必须传递pageSize, lastId。

●pageSize 页面大小

●lastId 上一页的最后一条记录的id，如果不传，则将强制为第一页

降序

_id降序，第一页是最大的，下一页的id比上一页的最后的id还小。

db.getCollection('file').find({ _id:{ $lt:lastId}})
.sort({ _id:-1})
.limit(pageSize)

升序

_id升序，下一页的id比上一页的最后一条记录id还大。

db.getCollection('file').find({ _id:{ $gt:lastId}})
.sort({ _id:1})
.limit(pageSize )

总条数

还有一共多少条和多少页的问题。所以，需要先查一共多少条count

db.getCollection('file').find({}).count();

ObjectId的有序性问题

先看ObjectId生成规则：

比如"_id" : ObjectId(“5b1886f8965c44c78540a4fc”)

取id的前4个字节。由于id是16进制的string，4个字节就是32位，对应id前8个字符。即5b1886f8, 转换成10进制为1528334072. 加上1970，就是当前时间。

事实上，更简单的办法是查看org.mongodb:bson:3.4.3里的ObjectId对象。

publicObjectId(Date date){
this(dateToTimestampSeconds(date), MACHINE_IDENTIFIER, PROCESS_IDENTIFIER, NEXT_COUNTER.getAndIncrement(),false);
}

//org.bson.types.ObjectId#dateToTimestampSeconds 
privatestatic int dateToTimestampSeconds(Date time){
return(int)(time.getTime()/ 1000L);
}

//java.util.Date#getTime
/**
 * Returns the number of milliseconds since January 1, 1970, 00:00:00 GMT
 * represented by this <tt>Date</tt> object.
 *
 * @return  the number of milliseconds since January 1, 1970, 00:00:00 GMT
 *          represented by this date.
 */
public long getTime(){
returngetTimeImpl();
}

MongoDB的ObjectId应该是随着时间而增加的，即后插入的id会比之前的大。但考量id的生成规则，最小时间排序区分是秒，同一秒内的排序无法保证。当然，如果是同一台机器的同一个进程生成的对象，是有序的。

如果是分布式机器，不同机器时钟同步和偏移的问题。所以，如果你有个字段可以保证是有序的，那么用这个字段来排序是最好的。_id则是最后的备选方案。

存在问题

上面的分页看起来看理想，虽然确实是，但有个问题是不能无法做到跳页。

我们的分页数据要和排序键关联，所以必须有一个排序基准来截断记录。而跳页，我只知道第几页，条件不足，无法分页了。

现实业务需求确实提出了跳页的需求，虽然几乎不会有人用，人们更关心的是开头和结尾，而结尾可以通过逆排序的方案转成开头。所以，真正分页的需求应当是不存在的。如果你是为了查找某个记录，那么查询条件搜索是最快的方案。如果你不知道查询条件，通过肉眼去一一查看，那么下一页足矣。

说了这么多，就是想扭转传统分页的概念，在互联网发展的今天，大部分数据的体量都是庞大的，跳页的需求将消耗更多的内存和cpu，对应的就是查询慢。

当然，如果数量不大，如果不介意慢一点，那么skip也不是啥问题，关键要看业务场景。

我今天接到的需求就是要跳页，而且数量很小，那么skip吧，不费事，还快。

比如google，看起来是有跳页选择的啊。再仔细看，只有10页，多的就必须下一页，并没有提供一共多少页，跳到任意页的选择。这不就是我们的find-condition-then-limit方案吗，只是他的一页数量比较多，前端或者后端把这一页给切成了10份。

同样，Facebook，虽然提供了总count，但也只能下一页。

其他场景，比如Twitter，微博，朋友圈等，根本没有跳页的概念的。

如果确实有跳页的需求，可以仍旧采用skip做分页，目前还没有发现性能问题

private List<DBObject> doFindItems(String collectionName,
      Map<String, Object> query, DBObject showFields, int skip,
      int limit, DBObject order) {

   List<DBObject> result = null;
   DBObject obj = genDBObject(query);
   DBCursor cursor = readDB.getCollection(collectionName)
         .find(obj, showFields);
   if (cursor != null) {
      try {
         if (order != null) {
            cursor.sort(order);
         }
         cursor.skip(skip).limit(limit);
         result = cursor.toArray();
      } finally {
         cursor.close();
      }
   }
  return result;
}

排序和性能

前面关注于分页的实现原理，但忽略了排序。既然分页，肯定是按照某个顺序进行分页的，所以必须要有排序的。

MongoDB的sort和find组合

db.getCollection('file').find().sort({'createTime':1}).limit(5)
db.getCollection('file').find().limit(5).sort({'createTime':1})

这两个都是等价的，顺序不影响执行顺序。即，都是先find查询符合条件的结果，然后在结果集中排序。

我们条件查询有时候也会按照某字段排序的，比如按照时间排序。查询一组时间序列的数据，我们想要按照时间先后顺序来显示内容，则必须先按照时间字段排序，然后再按照id升序。

db.getCollection('file').find({productId:5}).sort({createTime:1, _id:1}).limit(5)

我们先按照createTime升序，然后createTime相同的record再按照_id升序，如此可以实现我们的分页功能了。

多字段排序

db.getCollection('file').sort({taskRole:1,appId:-1})

表示先按照taskRole升序，再按appId降序

示例：

db.getCollection('file').find({});

结果：
/* 1 */
{
    "_id" : ObjectId("5e7179de0af8595d0bbe243f"),
    "fileName" : "test.apk",
    "fileCTime" : NumberLong(1584495748123),
    "version" : "1"
}
/* 2 */
{
    "_id" : ObjectId("5e7dc423e20bc4b7fa6c205a"),
"fileName" : "b.html",
"version" : "2"
}
/* 3 */
{
    "_id" : ObjectId("5e7dc423e20bc4b7fa6c205b"),
"fileName" : "b.html",
"version" : "3"
}

按照fileName升序，然后按照version降序

db.getCollection('file').find({}).sort({fileName:1,version:-1})

结果：
/* 1 */
{
    "_id" : ObjectId("5e7dc423e20bc4b7fa6c205a"),
"fileName" : "b.html",
"version" : "2 "
}
/* 2 */
{
    "_id" : ObjectId("5e7dc423e20bc4b7fa6c205b"),
"fileName" : " b.html",
"version" : "3"
}
/* 3 */
{
    "_id" : ObjectId("5e7179de0af8595d0bbe243f"),
    "fileName" : "test.apk",
    "fileCTime" : NumberLong(1584495748123),
    "version" : "1"
}

Mongo慢查询优化

监控

mongodb可以通过profile来监控查询，查出耗时查询，然后进行优化。

profile常用命令：

db.getProfilingLevel();//查看当前是否开启profile功能用命令，返回level等级，值为0-关闭、1-慢命令、2-全部

db.setProfilingLevel(level);//开启profile功能

level为1的时候，慢命令默认值为100ms，更改为db.setProfilingLevel(level,slowms)
如db.setProfilingLevel(1,50);//更改慢命令值为50ms

db.system.profile.find() //当前的监控日志。

db.system.profile.find({millis:{$gt:500}});//返回查询时间在500毫秒以上的查询命令。

{
    "op" : "query",
    "ns" : "ones.file",//慢日志是所在库和集合
    "command" : {    //具体查询命令
        "find" : "file",
        "filter" : {
            "qbuildCid" : 449557
        },
        "projection" : {},
        "limit" : 1,
        "singleBatch" : true,
        "$db" : "ones",
        "lsid" : {
            "id" : UUID("a9086c77-b0ae-4de1-b0d2-9db19a455762")
        }
    },
    "keysExamined" : 0,
    "docsExamined" : 221258,//此次查询遍历文档个数
    "cursorExhausted" : true,
    "numYield" : 1728,
    "nreturned" : 1,
    "locks" : {
        "Global" : {
            "acquireCount" : {
                "r" : NumberLong(1731)
            }
        },
        "Database" : {
            "acquireCount" : {
                "r" : NumberLong(1729)
            }
        },
        "Collection" : {
            "acquireCount" : {
                "r" : NumberLong(1729)
            }
        }
    },
    "storage" : {},
    "responseLength" : 712,
    "protocol" : "op_msg",
    "millis" : 220,//查询耗时
    "planSummary" : "COLLSCAN",
    "execStats" : {
        "stage" : "LIMIT",
        "nReturned" : 1,
        "executionTimeMillisEstimate" : 10,
        "works" : 221260,
        "advanced" : 1,
        "needTime" : 221258,
        "needYield" : 0,
        "saveState" : 1728,
        "restoreState" : 1728,
        "isEOF" : 1,
        "invalidates" : 0,
        "limitAmount" : 1,
        "inputStage" : {
            "stage" : "COLLSCAN",
            "filter" : {
                "qbuildCid" : {
                    "$eq" : 449557
                }
            },
            "nReturned" : 1,
            "executionTimeMillisEstimate" : 10,
            "works" : 221259,
            "advanced" : 1,
            "needTime" : 221258,
            "needYield" : 0,
            "saveState" : 1728,
            "restoreState" : 1728,
            "isEOF" : 0,
            "invalidates" : 0,
            "direction" : "forward",
            "docsExamined" : 221258
        }
    },
    "ts" : ISODate("2020-05-27T10:50:15.394Z"),//命令执行时间
    "client" : "10.10.10.10",
    "allUsers" : [ 
        {
            "user" : "mongo",
            "db" : "admin"
        }
    ],
    "user" : "mongo@admin"
}

millis为查询耗时，如果发现时间比较长，那么就需要作优化。

docsExamined代表查询遍历文档数，如果该值很大，或者接近记录总数，那么可能没有用到索引查询。

索引

如果发现查询的时间较长，那么可能需要为待查询的字段建立索引。

索引的原理是通过建立指定字段的B-Tree，通过搜索B-Tree来查找对应document的地址。如果需要查询超过一半的集合数据，那直接遍历效率反而会更高，因为省去了搜索B-Tree的过程。

结果集在原集合中所占的比例越大，查询效率越慢。因为使用索引需要进行两次查找：一次查找索引条目，一次根据索引指针去查找相应的文档。而全表扫描只需要进行一次查询。在最坏的情况，使用索引进行查找次数会是全表扫描的两倍。效率会明显比全表扫描低。例如，在文件表中，我们拥有一个"type"列索引，如果在"type"列中，android占了50%，如果现在要查询一个类型为android，文件名为“test.apk"的文件，我们则需要在表的50%的数据中查询，这样有索引的性能会降低。

而相反在提取较小的子数据集时，索引就非常有效，这就是我们为什么会使用分页。

索引设计原则

**8.控制字段数：**如果你设计的索引例如含有7、8个字段通常需要考虑设计是否合理

Explain查询计划

命令：

>db.getCollection(‘file’).find({qbuildId:441557}).explain()

Explain结果

explain 结果将查询计划以阶段树的形式呈现。

每个阶段将其结果（文档或索引键）传递给父节点。

中间节点操纵由子节点产生的文档或索引键。

根节点是MongoDB从中派生结果集的最后阶段。

在看查询结果的阶段树的时候一定一定是从最里层一层一层往外看的，不是直接顺着读下来的。

在查询计划中出现了很多stage，下面列举的经常出现的stage以及他的含义：

**TEXT：**使用全文索引进行查询时候的stage返回通过这些信息就能判断查询时如何执行的了

其他

如果数据文件大于系统内存，查询速度会下降几个数量级，因为mongodb是内存数据库。1000万数据的时候没有索引情况下查询可能会几秒钟甚至更久。

另外一点是数据索引如果大于内存，速度也会下降很多。而且对于多条件查询，如果你查询的顺序和索引顺序不同，也不能使用索引。

如果你使用了replica set，这个会影响写入速度的，三个replica set，速度会降低到三分之一。