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提示。


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

目录
相关文章
|
存储 监控 NoSQL
MongoDB优化的几点原则
这篇文章讨论了MongoDB优化的一些原则,包括查询优化、热数据大小、文件系统选择、硬盘选择、查询方式优化、sharding key设计和性能监控。
380 1
|
存储 NoSQL MongoDB
掌握MongoDB索引优化策略:提升查询效率的关键
在数据库性能调优中,索引是提升查询效率的利器。本文将带你深入了解MongoDB索引的内部工作原理,探讨索引对查询性能的影响,并通过实际案例指导如何针对不同的查询模式建立有效的索引。不仅将涵盖单一字段索引,还会探讨复合索引的使用,以及如何通过分析查询模式和执行计划来优化索引,最终实现查询性能的最大化。
|
9月前
|
NoSQL MongoDB 数据库
微服务——MongoDB实战演练——表结构分析
本文档来源于数据库articledb,展示了一张图片资源。图片宽度为1207像素,高度607像素,采用内联显示方式。内容涉及图像处理与样式设定,适用于文档或网页设计中多媒体元素的布局参考。图片来源为cdn.nlark.com,支持webp格式并附带水印处理。
137 1
微服务——MongoDB实战演练——表结构分析
|
8月前
|
NoSQL MongoDB 数据库
数据库数据恢复——MongoDB数据库服务无法启动的数据恢复案例
MongoDB数据库数据恢复环境: 一台Windows Server操作系统虚拟机上部署MongoDB数据库。 MongoDB数据库故障: 管理员在未关闭MongoDB服务的情况下拷贝数据库文件。将MongoDB数据库文件拷贝到其他分区后,对MongoDB数据库所在原分区进行了格式化操作。格式化完成后将数据库文件拷回原分区,并重新启动MongoDB服务。发现服务无法启动并报错。
|
存储 监控 NoSQL
MongoDB索引解析:工作原理、类型选择及优化策略
MongoDB索引解析:工作原理、类型选择及优化策略
|
10月前
|
存储 NoSQL MongoDB
数据库数据恢复—MongoDB数据库迁移过程中丢失文件的数据恢复案例
某单位一台MongoDB数据库由于业务需求进行了数据迁移,数据库迁移后提示:“Windows无法启动MongoDB服务(位于 本地计算机 上)错误1067:进程意外终止。”
|
存储 NoSQL MongoDB
MongoDB 查询分析
10月更文挑战第21天
126 1
|
NoSQL MongoDB 数据库
python3操作MongoDB的crud以及聚合案例,代码可直接运行(python经典编程案例)
这篇文章提供了使用Python操作MongoDB数据库进行CRUD(创建、读取、更新、删除)操作的详细代码示例,以及如何执行聚合查询的案例。
312 6
|
存储 监控 NoSQL
TDengine 3.3.3.0 版本上线:优化监控、增强 MongoDB 支持
今天我们非常高兴地宣布,TDengine 3.3.3.0 版本正式发布。本次更新引入了多项重要功能和性能优化,旨在为用户提供更高效、更灵活的数据解决方案。
310 0
|
JSON NoSQL MongoDB
MongoDB Schema设计实战指南:优化数据结构,提升查询性能与数据一致性
【8月更文挑战第24天】MongoDB是一款领先的NoSQL数据库,其灵活的文档模型突破了传统关系型数据库的限制。它允许自定义数据结构,适应多样化的数据需求。设计MongoDB的Schema时需考虑数据访问模式、一致性需求及性能因素。设计原则强调简洁性、查询优化与合理使用索引。例如,在构建博客系统时,可以通过精心设计文章和用户的集合结构来提高查询效率并确保数据一致性。正确设计能够充分发挥MongoDB的优势,实现高效的数据管理。
459 3

推荐镜像

更多