MongoDB使用优化

时间:2021-09-06 18:40:43

一、监控

mongodb可以通过profile来监控数据,进行优化。

查看当前是否开启profile功能用命令:db.getProfilingLevel()返回level等级,值为0|1|2,分别代表意思:0代表关闭,1代表记录慢命令,2代表全部。

开始profile功能为db.setProfilingLevel(level);

level为1的时候,慢命令默认值为100ms,更改为db.setProfilingLevel(level,slowms)如db.setProfilingLevel(1,50)这样就更改为50毫秒

通过db.system.profile.find() 查看当前的监控日志。

通过执行db.system.profile.find({millis:{$gt:500}})能够返回查询时间在500毫秒以上的查询命令。

这里值的含义是

ts:命令执行时间
info:命令的内容
query:代表查询
order.order: 代表查询的库与集合
reslen:返回的结果集大小,byte数
nscanned:扫描记录数量
nquery:后面是查询条件
nreturned:返回记录数及用时
millis:所花时间

如果发现时间比较长,那么就需要作优化。

比如nscanned数很大,或者接近记录总数,那么可能没有用到索引查询。

reslen很大,有可能返回没必要的字段。

nreturned很大,那么有可能查询的时候没有加限制。

mongo可以通过db.serverStatus()查看mongod的运行状态

二、索引

首选就是为待查询的字段建立索引,不过需要特别注意的是,索引不是万能灵药。如果需要查询超过一半的集合数据,索引还不如直接遍历来的好。

索引的原理是通过建立指定字段的B树,通过搜索B树来查找对应document的地址。这也就解释了如果需要查询超过一半的集合数据,直接遍历省去了搜索B树的过程,效率反而会高。

关于索引,索引列颗粒越小越好,什么叫颗粒越小越好?在索引列中每个数据的重复数量称为颗粒,也叫作索引的基数。如果数据的颗粒过大,索引就无法发挥该有的性能。例如,我们拥有一个"age"列索引,如果在"age"列中,20岁占了50%,如果现在要查询一个20岁,名叫"Tom"的人,我们则需要在表的50%的数据中查询,索引的作用大大降低。所以,我们在建立索引时要尽量将数据颗粒小的列放在索引左侧,以保证索引发挥最大的作用。

由于索引是存储在内存(RAM)中,你应该确保该索引的大小不超过内存的限制。如果索引的大小大于内存的限制,MongoDB会删除一些索引,这将导致性能下降。

索引不能被以下的查询使用:

  • 正则表达式及非操作符,如 $nin, $not, 等
  • 算术运算符,如 $mod, 等
  • $where 子句

三、explain

explain有三种模式,分别是:queryPlanner、executionStats、allPlansExecution:

queryPlanner:不会真正的执行查询,只是分析查询,选出winning plan。

executionStats:返回winning plan的关键数据,executionTimeMillis表示该query查询的总体时间。

allPlansExecution:执行所有的plans。

通常是使用 executionStats 模式
 MongoDB Enterprise > db.batch_info_201903.find({"phone":"","uuid":""}).explain("executionStats")
{
"queryPlanner" : {
"plannerVersion" : ,
"namespace" : "sms.batch_info_201903",
"indexFilterSet" : false,
"parsedQuery" : {
"$and" : [
{
"phone" : {
"$eq" : ""
}
},
{
"uuid" : {
"$eq" : ""
}
}
]
},
"winningPlan" : {
"stage" : "FETCH",
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"phone" : ,
"uuid" :
},
"indexName" : "phone_1_uuid_1",
"isMultiKey" : false,
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : ,
"direction" : "forward",
"indexBounds" : {
"phone" : [
"[\"13631277247\", \"13631277247\"]"
],
"uuid" : [
"[\"123\", \"123\"]"
]
}
}
},
"rejectedPlans" : [ ]
},
"executionStats" : {
"executionSuccess" : true,
"nReturned" : ,
"executionTimeMillis" : ,
"totalKeysExamined" : ,
"totalDocsExamined" : ,
"executionStages" : {
"stage" : "FETCH",
"nReturned" : ,
"executionTimeMillisEstimate" : ,
"works" : ,
"advanced" : ,
"needTime" : ,
"needYield" : ,
"saveState" : ,
"restoreState" : ,
"isEOF" : ,
"invalidates" : ,
"docsExamined" : ,
"alreadyHasObj" : ,
"inputStage" : {
"stage" : "IXSCAN",
"nReturned" : ,
"executionTimeMillisEstimate" : ,
"works" : ,
"advanced" : ,
"needTime" : ,
"needYield" : ,
"saveState" : ,
"restoreState" : ,
"isEOF" : ,
"invalidates" : ,
"keyPattern" : {
"phone" : ,
"uuid" :
},
"indexName" : "phone_1_uuid_1",
"isMultiKey" : false,
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : ,
"direction" : "forward",
"indexBounds" : {
"phone" : [
"[\"13631277247\", \"13631277247\"]"
],
"uuid" : [
"[\"123\", \"123\"]"
]
},
"keysExamined" : ,
"dupsTested" : ,
"dupsDropped" : ,
"seenInvalidated" :
}
}
},
"serverInfo" : {
"host" : "develop",
"port" : ,
"version" : "3.2.11",
"gitVersion" : "009580ad490190ba33d1c6253ebd8d91808923e4"
},
"ok" :
}

对queryPlanner分析

queryPlanner: queryPlanner的返回

queryPlanner.namespace:该值返回的是该query所查询的表

queryPlanner.indexFilterSet:针对该query是否有indexfilter

queryPlanner.winningPlan:查询优化器针对该query所返回的最优执行计划的详细内容。

queryPlanner.winningPlan.stage:最优执行计划的stage,这里返回是FETCH,可以理解为通过返回的index位置去检索具体的文档(stage有数个模式,将在后文中进行详解)。

queryPlanner.winningPlan.inputStage:用来描述子stage,并且为其父stage提供文档和索引关键字。

queryPlanner.winningPlan.stage的child stage,此处是IXSCAN,表示进行的是index scanning。

queryPlanner.winningPlan.keyPattern:所扫描的index内容,此处是did:1,status:1,modify_time: -1与scid : 1

queryPlanner.winningPlan.indexName:winning plan所选用的index。

queryPlanner.winningPlan.isMultiKey是否是Multikey,此处返回是false,如果索引建立在array上,此处将是true。

queryPlanner.winningPlan.direction:此query的查询顺序,此处是forward,如果用了.sort({modify_time:-1})将显示backward。

queryPlanner.winningPlan.indexBounds:winningplan所扫描的索引范围,如果没有制定范围就是[MaxKey, MinKey],这主要是直接定位到mongodb的chunck中去查找数据,加快数据读取。

queryPlanner.rejectedPlans:其他执行计划(非最优而被查询优化器reject的)的详细返回,其中具体信息与winningPlan的返回中意义相同,故不在此赘述。

对executionStats返回逐层分析

    第一层,executionTimeMillis

最为直观explain返回值是executionTimeMillis值,指的是我们这条语句的执行时间,这个值当然是希望越少越好。

其中有3个executionTimeMillis,分别是:

executionStats.executionTimeMillis

该query的整体查询时间。

executionStats.executionStages.executionTimeMillisEstimate

该查询根据index去检索document获得2001条数据的时间。

executionStats.executionStages.inputStage.executionTimeMillisEstimate

该查询扫描2001行index所用时间。

第二层,index与document扫描数与查询返回条目数

这个主要讨论3个返回项,nReturned、totalKeysExamined、totalDocsExamined,分别代表该条查询返回的条目、索引扫描条目、文档扫描条目。

这些都是直观地影响到executionTimeMillis,我们需要扫描的越少速度越快。

对于一个查询,我们最理想的状态是:

nReturned=totalKeysExamined=totalDocsExamined

第三层,stage状态分析

那么又是什么影响到了totalKeysExamined和totalDocsExamined?是stage的类型。类型列举如下:

COLLSCAN:全表扫描

IXSCAN:索引扫描

FETCH:根据索引去检索指定document

SHARD_MERGE:将各个分片返回数据进行merge

SORT:表明在内存中进行了排序

LIMIT:使用limit限制返回数

SKIP:使用skip进行跳过

IDHACK:针对_id进行查询

SHARDING_FILTER:通过mongos对分片数据进行查询

COUNT:利用db.coll.explain().count()之类进行count运算

COUNTSCAN:count不使用Index进行count时的stage返回

COUNT_SCAN:count使用了Index进行count时的stage返回

SUBPLA:未使用到索引的$or查询的stage返回

TEXT:使用全文索引进行查询时候的stage返回

PROJECTION:限定返回字段时候stage的返回

对于普通查询,我希望看到stage的组合(查询的时候尽可能用上索引):

Fetch+IDHACK

Fetch+ixscan

Limit+(Fetch+ixscan)

PROJECTION+ixscan

SHARDING_FITER+ixscan

COUNT_SCAN

不希望看到包含如下的stage:

COLLSCAN(全表扫描),SORT(使用sort但是无index),不合理的SKIP,SUBPLA(未用到index的$or),COUNTSCAN(不使用index进行count)

四、设计优化

如果是插入频繁,修改多,查询较少的,可利用数据库的范式形式保存数据:

{
"_id" : ObjectId("5124b5d86041c7dca81917"),
"title" : "如何使用MongoDB",
"author" : [
ObjectId("144b5d83041c7dca84416"),
ObjectId("144b5d83041c7dca84418"),
ObjectId("144b5d83041c7dca84420"),
]
}

如果是查询频繁,插入修改较少的,可以全部内嵌来设计:

{
"_id" : ObjectId("5124b5d86041c7dca81917"),
"title" : "如何使用MongoDB",
"author" : [
{
     "name" : "丁磊"
     "age" : ,
    "nationality" : "china",
},
{
     "name" : "马云"
     "age" : ,
     "nationality" : "china",
},
{
     "name" : "张召忠"
     "age" : ,
     "nationality" : "china",
},
]
}

折中设计,但是需要考虑到实际业务进行结合来寻找合适的提取字段:

{
"_id" : ObjectId("5124b5d86041c7dca81917"),
"title" : "如何使用MongoDB",
"author" : [
{
    "_id" : ObjectId("144b5d83041c7dca84416"),
     "name" : "丁磊"
},
{
     "_id" : ObjectId("144b5d83041c7dca84418"),
     "name" : "马云"
},
{
     "_id" : ObjectId("144b5d83041c7dca84420"),
     "name" : "张召忠"
},
]
}

五、字段

1、可为不想保存历史数据但又不想删除过多数据的集合添加过期索引,索引可加上过期时间或不添加,插入数据时可在指定字段确定是否添加过期时间

2、组合使用

六、其他

热数据法

可能你的数据集非常大,但是这并不那么重要,重要的是你的热数据集有多大,你经常访问的数据有多大(包括经常访问的数据和所有索引数据)。使用MongoDB,你最好保证你的热数据在你机器的内存大小之下,保证内存能容纳所有热数据。

文件系统法

MongoDB的数据文件是采用的预分配模式,并且在Replication里面,Master和Replica Sets的非Arbiter节点都是会预先创建足够的空文件用以存储操作日志。这些文件分配操作在一些文件系统上可能会非常慢,导致进程被Block。所以我们应该选择那些空间分配快速的文件系统。这里的结论是尽量不要用ext3,用ext4或者xfs。

硬件法

这里的选择包括了对磁盘RAID的选择,也包括了磁盘与SSD的对比选择

七、数据存储方式

1、主从,primary-secondary

2、分片,shard

MongoDB使用优化的更多相关文章

  1. MongoDB 性能优化五个简单步骤

    MongoDB 一直是最流行的 NoSQL,而根据 DB-Engines Ranking 最新的排行,时下 MongoDB 已经击败 PostgreSQL 跃居数据库总排行的第四位,仅次于 Oracl ...

  2. mongodb可以通过profile来监控数据 (mongodb性能优化)

    mongodb可以通过profile来监控数据 (mongodb性能优化)   开启 Profiling  功能 ,对慢查询进行优化: mongodb可以通过profile来监控数据,进行优化. 查看 ...

  3. MongoDB性能优化

    一.索引 MongoDB 提供了多样性的索引支持,索引信息被保存在system.indexes 中,且默认总是为_id创建索引,它的索引使用基本和MySQL 等关系型数据库一样.其实可以这样说说,索引 ...

  4. MongoDB性能优化指南

    一.索引 MongoDB 提供了多样性的索引支持,索引信息被保存在system.indexes 中,且默认总是为_id创建索引,它的索引使用基本和MySQL 等关系型数据库一样.其实可以这样说说,索引 ...

  5. mongodb分页优化

    现在参与一个项目的开发,需要用java查询mongodb数据库,在这里分页用的skip sort 和limit结合,查询语句如下(已经在相关字段建立索引) DBCursor cursor = coll ...

  6. jemalloc Mongodb Nginx 优化

    下载 http://www.canonware.com/jemalloc/download.html 下载 wget http://www.canonware.com/download/jemallo ...

  7. mongodb 参数优化

    1.大部分IO操作为随机IO,建议采用SSD或PCIE,普通硬盘RAID10 2.IO调度算法.普通磁盘:deadline避免IO请求出现“饥饿”现象,SSD/PCIE:noop简单的先进先出处理请求 ...

  8. 开发高性能的MongoDB应用—浅谈MongoDB性能优化(转)

    出处:http://www.cnblogs.com/mokafamily/p/4102829.html 性能与用户量 “如何能让软件拥有更高的性能?”,我想这是一个大部分开发者都思考过的问题.性能往往 ...

  9. 开发高性能的MongoDB应用—浅谈MongoDB性能优化

    关联文章索引: 大数据时代的数据存储,非关系型数据库MongoDB 性能与用户量 “如何能让软件拥有更高的性能?”,我想这是一个大部分开发者都思考过的问题.性能往往决定了一个软件的质量,如果你开发的是 ...

随机推荐

  1. 读深入了解c++内核对象模型小结(1/3/4)

    之前早就听说这本书不错,如果想对c++进一步的了解可以看看,此书是进阶阶段参考,笔者自己看了书的第一.三.四章节,后面会继续.      第一章讲了c++的对象模型的引入,各种模型的对比和现在c++采 ...

  2. go语言 安装版 Windows7安装截图

    这个比较简单的 一路next. 查看:解压版安装go. //http://www.cnblogs.com/osfipin/

  3. SVN 操作指南

    1.安装 和 使用 2.导入导出 2.错误信息 ① svn不知到这样的主机

  4. linux中模块的相关操作

    /lib/modules/[kernel版本]/modules.dep 这个文件记录了模块的依赖关系 modprobe 和 insmod 这两个命令都可以加载模块,但是modeprobe会自动分析模块 ...

  5. 自定义seekbar中,thumb被覆盖掉一部分问题

  6. CentOS7下使用YUM安装MySQL5.6

    (1)检查系统中是否已安装 MySQL. rpm -qa | grep mysql 返回空值的话,就说明没有安装 MySQL . 注意:在新版本的CentOS7中,默认的数据库已更新为了Mariadb ...

  7. UIAlertControllerStyleActionSheet 崩溃。

    即使Devices 设置为iPhone模式,在审核时还是运行在iPad的小屏模式下.因此必须 UIActivityViewController UIAlertControllerStyleAction ...

  8. Mongodb集群与分片 2

    前面我们介绍了简单的集群配置实例.在简单实例中,虽然MongoDB auto-Sharding解决了海量存储问题,和动态扩容问题,但是离我们在真实环境下面所需要的高可靠性和高可用性还有一定的距离. 下 ...

  9. hdu1540 Tunnel Warfare【线段树】

    During the War of Resistance Against Japan, tunnel warfare was carried out extensively in the vast a ...

  10. WebApiClient.AOT.dll 调用api地址 -> 调用方法

    优点:简化api调用过程,WebApiClient.AOT.dll中的IHttpApi接口 缺点:只适用于内部服务之间的调用(没有验证过程) 1.继承IHttpAPi接口 public interfa ...