MongoDB涉及的业务比较慢--慢查询优化分析案例--以及参数说明

描述:该优化案例是想表达要了解各个参数的含义,结合业务的分析以及逻辑实现、以及创建索引和列顺序是如何选择的等(这里不再叙述)

环境描述一下

MongoDB版本 3.0.9,副本集3节点,内存64G,cpu 16 core,磁盘2TB SSD,使用WT存储引擎。。。

该表数据量2.6亿多。

大致分析如下:

  1. 通过mloginfo统计查看日志中慢查询的分类(将生产系统日志scp到测试服务器做的)

# mloginfo --queries mongod.log-20160427  

namespace    operation  pattern                                            count    min (ms) max (ms)  mean (ms)  95%-ile (ms) sum (ms)

数据库.集合  query     {"gender": 1, "icial": 1, "stVal": 1, "version": 1}  997090   366      3961      802        n/a         51923475

2.抓取程序在慢的时间点日志信息

……

2016-04-26T14:28:48.536+0800 I COMMAND  [conn241925] query 数据库.集合 query: { orderby: { goals: 1, diff: 1 }, $query: { version: true, icial: true, stVal: { $gte: 20 }, gender: "f" } } planSummary: IXSCAN { gender: 1.0, goals: 1.0, difficulty: 1.0, stateValue: 1.0, version: -1.0 } ntoreturn:1000 ntoskip:0 nscanned:145640 nscannedObjects:145628 keyUpdates:0 writeConflicts:0 numYields:1137 nreturned:10 reslen:510 locks:{ Global: { acquireCount: { r: 2276 }, acquireWaitCount: { r: 28 }, timeAcquiringMicros: { r: 22753 } }, Database: { acquireCount: { r: 1138 } }, Collection: { acquireCount: { r: 1138 } } } 1675ms

这样的SQL语句很多,只拿一条分析。

分析各个参数的含义

(1)目前该查询sql使用的索引:IXSCAN { gender: 1.0, goals: 1.0, diff: 1.0, stVal: 1.0, version: -1.0 }

(2)ntoreturn:1000  期望返回数量,query语句期望返回的数量,如limit(40)

(3)nreturned:10  实际返回的数量

(4)ntoskip:0     skip()方法跳过的记录数

(5)nscanned:145640

   扫描次数,当扫描次数大于返回的数量(ntoreturn),考虑使用索引

   nscanned和nscannedObjects区别:

   1、nscanned:根据索引扫描文档,扫描的可能返回实际返回的数量(nreturned:10)

   2、nscannedObjects:扫描完整的文档,扫描实际返回的数据(nscannedObjects:145628)

    http://stackoverflow.com/questions/13910097/explain-in-mongodb-differences-between-nscanned-and-nscannedobjects 

说明

nscanned审议了项目(文件或索引项)的数量。项目可能是对象或索引键。如果一个“覆盖索引”参与, nscanned可能比nscannedObjects高

【nscanned Number of items (documents or index entries) examined. Items might be objects or index keys. If a "covered index" is involved, nscanned may be higher than nscannedObjects.】

nscannedObjects:扫描的文档数量.

(6)acquireCount: 特定模式下获取锁的操作次数

(7)millis: 1675ms  操作执行时间

说明:

没有该值,说明一下,这个值也特别重要

scanAndOrder:布尔值,当为true时,表明排序未使用到索引,只有true时该字段才显示

(8)numYields:1137 

就是查询等待插入的次数

查询是需要给写操作让路的

numYields是报告的次数的操作已经产生,以允许其它操作来完成的数量的计数器。

https://docs.mongodb.org/manual/reference/method/db.currentOp/

通常情况下,操作产生时,他们需要访问的MongoDB还没有完全读入内存中的数据。

这允许在内存中的数据,以快速完成,而在MongoDB的数据屈服操作读取等操作。

[

numYields is a counter that reports the number of times the operation has yielded to allow other operations to complete.

Typically, operations yield when they need access to data that MongoDB has not yet fully read into memory. 

This allows other operations that have data in memory to complete quickly while MongoDB reads in data for the yielding operation.

]

可能还有其他操作,比如索引建的有问题,即使走索引,需要扫描整个索引,

并且索引不覆盖查询,需要回行加载数据。另外看是不是排序没有用上索引,

导致很多需要单独放内存排序,耗性能耗内存。

另外如果有in查询,数据分散,加载数据可能需要多次随机IO等等。。

(9)观察执行计划、慢日志如下参数(不在说明)

nscannedObjects

nscanned

scanAndOrder

millis

3.在secondary(业务不忙时)分析该sql执行计划

说明:如果该表数据量特别大,比如上亿,加入allPlansExecution参数会执行的非常慢,谨慎在线上数据库执行(我是在测试数据库执行的)。

db.集合.find({ version: true, icial: true, stVal: { $gte: 20 }, gender: "f" }).sort({ goals: 1, diff: 1 }).explain("allPlansExecution")

……"gender": 1, "icial": 1, "stVal": 1, "version": 1

 [

{

"stage" : "FETCH",

"filter" : {

"icial" : {

"$eq" : true

}

},

"inputStage" : {

"stage" : "IXSCAN",

"keyPattern" : {

"gender" : 1,

"goals" : 1,

"diff" : 1,

"stVal" : 1,

"version" : -1

},

"indexName" : "gender_1_goals_1_diff_1_stVal_1_version_-1",

"isMultiKey" : false,

"direction" : "forward",

……

}

]

……

索引没有正确添加:执行计划

"executionStats" : {

"executionSuccess" : true,

"nReturned" : 10,  实际返回行数

"executionTimeMillis" : 2000,执行的毫秒

"totalKeysExamined" : 3030000,扫描索引行数

"totalDocsExamined" : 2910000,扫描文档行数

而且有filter过滤操作(即回表操作)。目前该sql选择了gender_1_goals_1_diff_1_stVal_1_version_-1索引。

4.建议

结合业务分析,该sql在业务中每天执行了997090次;分析了该业务和相关sql后,决定违反mongodb建议的联合索引最多5个列的限制:

建议创建如下索引:

db.集合.createIndex({gender:1,version:1,icial:1,goals:1,diff:1,stVal:1},{background:true});

我这边大概执行了90分钟(业务不繁忙时执行的,这边业务晚上比较忙。。。)

再次执行执行计划

……

{

"stage" : "FETCH",

"inputStage" : {

"stage" : "IXSCAN",

"keyPattern" : {

"gender" : 1,

"version" : 1,

"icial" : 1,

"goals" : 1,

"diff" : 1,

"stVal" : 1

},

"indexName" : "gender_1_version_1_icial_1_goals_1_diff_1_stVal_1",

"isMultiKey" : false,

"direction" : "forward",

       ……

}

}

……

"executionStats" : {

"executionSuccess" : true,

"nReturned" : 10,

"executionTimeMillis" : 0,

"totalKeysExamined" : 10,

"totalDocsExamined" : 10,

访问数据量明显减少了30W倍左右。

在业务实现中使用了hint提示。

创建索引建议:先做等值查询,在做排序,在做范围查询。

时间: 2024-09-21 04:12:24

MongoDB涉及的业务比较慢--慢查询优化分析案例--以及参数说明的相关文章

MongoDB查询优化分析

在MySQL中,慢查询日志是经常作为我们优化查询的依据,那在MongoDB中是否有类似的功能呢?答案是肯定的,那就 是开启Profiling功能.该工具在运行的实例上收集有关MongoDB的写操作,游标,数据库命令等,可以在数据库级别开 启该工具,也可以在实例级别开启.该工具会把收集到的所有都写入到system.profile集合中,该集合是一个capped collection.更多的信息见:http://docs.mongodb.org/manual/tutorial/manage-the-

库克出席太阳谷峰会:或涉及电视机业务

苹果CEO蒂姆·库克新浪科技讯 北京时间7月13日上午消息,苹果CEO蒂姆·库克(Tim Cook)在接受媒体采访时表示,他将借助太阳谷峰会的机会,与媒体行业的高管展开沟通.业内人士 认为,这有可能涉及传言中的 苹果电视机.由于已故苹果联合创始人史蒂夫·乔布斯(Steve Jobs)很少参加太阳谷峰会,因此库克的出席实为罕见,这也是他本人第一次参加太阳谷峰会.他接受<纽约邮报>采访时说:"我们将在这里与很多人沟通."虽然库克拒绝透露原因,但有消息称,这些 对话可能与传言中的

《港囧》火爆,徐峥收益多少?体验一下“业务思维×资本思维”的分析方法

这篇文章是根据前段时间和一些互联网创业者们的交流内容完善而成.过去几年,我讲了很多关于上市公司资本运作和并购成长的方法论,提出上市公司可以通过并购+核爆业务实现千亿市值的成长. 最近的几次交流中,我将关注点从上市公司的资本运作前移到非上市公司的资本化.证券化,或者更前移到创业公司该如何建立资本思维实现企业跨越式成长.资本思维不是上市公司专利,创业公司更需要资本思维. 我认为:新三板是创业企业和资本市场门槛最低的连接,是中国资本市场给创业企业一次难遇难求的制度红利.创业企业在苦练内功的同时,更要主

持续近7个小时的索引扫描的查询优化分析

昨天客户的DBA反映有一个数据抽取的任务持续了很长时间最后超时退出了,让我看看有什么地方可以调优一下. 找到了对应的日志,发现在一个大表抽取的时候,抽取持续了将近7个小时,最后超时退出了.对于这个问题,有以下几个方面需要考虑一下. 1)为什么这个问题之前没有发现过 2)是否是由某些变化导致了这个问题 3)这个问题的调优方向 这个数据抽取的服务之前一直没有问题,抽取速度都是比较快的,结果这次竟然持续了7个小时还没有抽取完.首先抓取到了对应的日志,把相关的sql语句也抓取到了. 同时从系统负载的角度

mysql limit查询优化分析_php技巧

Limit语法: 复制代码 代码如下: SELECT * FROM table LIMIT [offset,] rows | rows OFFSET offset LIMIT子句可以被用于强制 SELECT 语句返回指定的记录数.LIMIT接受一个或两个数字参数.参数必须是一个整数常量.如果给定两个参数,第一个参数指定第一个返回记录行的偏移量,第二个参数指定返回记录行的最大数目.初始记录行的偏移量是 0(而不是 1).为了与 PostgreSQL 兼容,MySQL 也支持句法:LIMIT # O

MongoDB中 同时使用$or和sort()查询性能分析

 代码如下 复制代码 mongos> db.find({ "user" : "jhon"}).sort({"name" : 1}).limit(100).explain() {         "cursor" : "BtreeCursor user_1",         "nscanned" : 10100,         "nscannedObjects"

SQLServer-TEMPDB性能问题排查

SQLServer-TEMPDB性能问题排查 问题描述 实例卡慢-金融云用户-RT敏感 问题分析 现场 首先看下进程状态: select * from sys.sysprocesses where spid>50 and lastwaittype<>'MISCELLANEOUS' and status<>'sleeping' and spid<>@@SPID 500+的进程挂起,必然会卡慢,但这是结果我们看看能否找到原因: 可以注意到很多session都被bloc

论MongoDB索引选择的重要性

线上某业务,频繁出现IOPS 使用率100%的(每秒4000IOPS)现象,每次持续接近1个小时,从慢请求的日志发现是一个 getMore 请求耗时1个小时,导致IOPS高:深入调查之后,最终发现竟是一个索引选择的问题. 2017-11-01T15:04:17.498+0800 I COMMAND [conn5735095] command db.mycoll command: getMore { getMore: 215174255789, collection: "mycoll"

MongoDB迎来原生数据分析功能

为了让大家更轻松地将分析机制引入自己的大数据存储体系当中,Pentaho公司今天公布了其业务分析与数据集成平台的最新版本已经正式进入通用阶段. Pentaho 5.1版本的设计目的在于为"数据与分析两个独立领域"架起一道往来的桥梁,从而为全部Pentaho用户--从开发人员到数据科学家再到商务分析师--提供支持.Pentaho 5.1为直接为MongoDB数据存储体系带来了运行无需使用代码的分析机制,并利用新的数据科学工具包作为相关专业人士的"个人助手".除此之外,