mongodb优化

最新推荐文章于 2024-05-29 11:42:27 发布
最新推荐文章于 2024-05-29 11:42:27 发布
阅读量513 收藏
点赞数
分类专栏： mongoDB 文章标签： mongodb
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/uevol14/article/details/53895920
版权

优化服务器硬件

mongodb内存使用方式

  1. mongodb使用内存映射文件I/O访问存储文件，系统将按需把需要的文件映射到RAM中。
  2. 工作集大小。这个大小代表着mongodb实例中存储的数据量。对大多数mongodb实例而言，常规操作通常只会访问到其中一部分数据。了解工作集大小可以帮助正确计算硬件大小。
  3. 确定硬件是最需要注意的是RAM的大小。不需要在服务器上安装512G的内存，因为可以通过分片将数据分散到多台服务器。

评估查询性能

mongodb有两个用于优化查询性能的工具：

  • mongodb分析器：查找查询性能不佳的查询以及选择查询用于进一步检查的好工具。

  • explain():研究单个查询，通过explain()可以判断查询的执行性能。

    mongodb分析器

    分析器级别

    MongoDB数据库分析器可以在实例级别打开，也可以在数据库级别打开。
    MongoDB数据库分析器可以设置三个级别：

  • 0 - 分析器处在关闭状态，不收集任何数据
  • 1 - 仅仅收集较慢操作的分析数据。默认情况下如果一个操作花费的时间超过100ms，就认为是较慢的操作。

  • 2 - 收集所有数据库操作的分析数据。

    system.profile集合

    MongoDB数据库分析器收集的数据将存放在system.profile集合中。system.profile是一个固定大小的集合，数据将循环写入该集合。当用完所有分配的空间后，MongoDB将会覆盖集合中最老的文档。默认情况下，system.profile集合大小为4M。开启分析器后，对应的数据库下创建system.profile集合，可以通过以下方式查看该集合信息：

> db.system.profile.stats()
{
    "ns" : "test.system.profile",
    "size" : 0,
    "count" : 0,
    "storageSize" : 4096,
    "capped" : true,
    "max" : -1,
    "maxSize" : 1048576,
    "sleepCount" : 0,
    "sleepMS" : 0,
    "wiredTiger" : {
        "metadata" : {
            "formatVersion" : 1
        },
        .......
}

启用和禁用mongodb分析器

启用（数据库级别）

> use test
switched to db test
> db.setProfilingLevel(1)
{ "was" : 0, "slowms" : 100, "ok" : 1 }
  • “slowms”:100 指超过100ms的查询都被列为慢查询

禁用 （数据库级别）

db.setProfilingLevel(0)
{ "was" : 1, "slowms" : 100, "ok" : 1 }

指定特定时间的查询启用分析器

> use test
switched to db test
> db.setProfilingLevel(1,500)
{ "was" : 0, "slowms" : 100, "ok" : 1 }
> db.getProfilingStatus()
{ "was" : 1, "slowms" : 500 }

查看分析器Level

> db.getProfilingLevel()
1

查找慢查询

db.system.profile.find()

{
    "op" : "query",
    "ns" : "test.col",
    "query" : {
        "find" : "col",
        "filter" : {

        }
    },
    "keysExamined" : 0,
    "docsExamined" : 2,
    "cursorExhausted" : true,
    "numYield" : 0,
    "locks" : {
        "Global" : {
            "acquireCount" : {
                "r" : NumberLong(2)
            }
        },
        "Database" : {
            "acquireCount" : {
                "r" : NumberLong(1)
            }
        },
        "Collection" : {
            "acquireCount" : {
                "r" : NumberLong(1)
            }
        }
    },
    "nreturned" : 2,
    "responseLength" : 165,
    "protocol" : "op_command",
    "millis" : 0,
    "planSummary" : "COLLSCAN",
    "execStats" : {
        "stage" : "COLLSCAN",
        "nReturned" : 2,
        "executionTimeMillisEstimate" : 0,
        "works" : 4,
        "advanced" : 2,
        "needTime" : 1,
        "needYield" : 0,
        "saveState" : 0,
        "restoreState" : 0,
        "isEOF" : 1,
        "invalidates" : 0,
        "direction" : "forward",
        "docsExamined" : 2
    },
    "ts" : ISODate("2016-12-27T05:35:27.941Z"),
    "client" : "127.0.0.1",
    "appName" : "MongoDB Shell",
    "allUsers" : [ ],
    "user" : ""
}

查找执行时间大于某个特定时间的查询

db.system.profile.find({millis:{$gt:10}}).sort({millis:-1})

system.profile只是一个普通的集合，在普通集合的查询方式在此都可用。可结合更多的字段进行筛选。

增大分析集合的大小

顺序如下：
1. 禁用目标数据库上的分析器

 db.setProfilingLevel(0)
  1. 删除现有的system.profile集合
 db.system.profile.drop()
  1. 创建新的分析器集合system.profile，并使用目标字节大小作为参数。通过db.system.profile.stats()命令可以看到”capped” : true，说明该集合是一个固定大小的集合。
db.createCollection('system.profile',{capped:true,size:50*1024*1024})
  1. 成功创建集合后，重新启用分析器
db.setProfilingLevel(1)

使用explain分析特定的查询

插入测试数据


>use test
switched to db test
> for (var i=1;i<=10000;i++) db.col.insert({a:i,b:i+1})
WriteResult({ "nInserted" : 1 })

执行计划分析详解

现版本explain有三种模式，分别如下：

  1. queryPlanner
  2. executionStats
  3. allPlansExecution
queryPlanner

queryPlanner是现版本explain的默认模式，queryPlanner模式下并不会去真正进行query语句查询，而是针对query语句进行执行计划分析并选出winning plan。

> db.test.find({a:{$gt:8000}}).explain()
{
    "queryPlanner" : {
        "plannerVersion" : 1,
        "namespace" : "test.test",
        "indexFilterSet" : false,
        "parsedQuery" : {
            "a" : {
                "$gt" : 8000
            }
        },
        "winningPlan" : {
            "stage" : "FETCH",
            "inputStage" : {
                "stage" : "IXSCAN",
                "keyPattern" : {
                    "a" : 1
                },
                "indexName" : "a_1",
                "isMultiKey" : false,
                "multiKeyPaths" : {
                    "a" : [ ]
                },
                "isUnique" : false,
                "isSparse" : false,
                "isPartial" : false,
                "indexVersion" : 2,
                "direction" : "forward",
                "indexBounds" : {
                    "a" : [
                        "(8000.0, inf.0]"
                    ]
                }
            }
        },
        "rejectedPlans" : [ ]
    },
    "serverInfo" : {
        "host" : "iz2zecqalqk7c59mfkog6gz",
        "port" : 27017,
        "version" : "3.4.1",
        "gitVersion" : "5e103c4f5583e2566a45d740225dc250baacfbd7"
    },
    "ok" : 1
}

关键字段解释：
1. explain.queryPlanner：queryPlanner的返回
2. explain.queryPlanner.namespace：该值返回的是该query所查询的表名
3. explain.queryPlanner.indexFilterSet：针对该query是否有indexfilter
4. explain.queryPlanner.winningPlan：查询优化器针对该query所返回的最优执行计划的详细内容
5. explain.queryPlanner.winningPlan.stage：最优执行计划的stage，这里返回是FETCH，可以理解为通过返回的index位置去检索具体的文档
如下几类介绍

COLLSCAN：全表扫描
IXSCAN：索引扫描
FETCH：根据索引去检索指定document
SHARD_MERGE：将各个分片返回数据进行merge

  1. explain.queryPlanner.winningPlan.inputStage：explain.queryPlanner.winningPlan.stage的child stage，此处是IXSCAN，表示进行的是index scanning
  2. explain.queryPlanner.winningPlan.keyPattern：所扫描的index内容，此处是a:1
  3. explain.queryPlanner.winningPlan.indexName：winning plan所选用的index
  4. explain.queryPlanner.winningPlan.isMultiKey：
    是否是Multikey，此处返回是false，如果索引建立在array上，此处将是true
executionStats
> db.test.find({a:{$gt:8000}}).explain('executionStats')
{
    "queryPlanner" : {
        "plannerVersion" : 1,
        "namespace" : "test.test",
        "indexFilterSet" : false,
        "parsedQuery" : {
            "a" : {
                "$gt" : 8000
            }
        },
        "winningPlan" : {
            "stage" : "FETCH",
            "inputStage" : {
                "stage" : "IXSCAN",
                "keyPattern" : {
                    "a" : 1
                },
                "indexName" : "a_1",
                "isMultiKey" : false,
                "multiKeyPaths" : {
                    "a" : [ ]
                },
                "isUnique" : false,
                "isSparse" : false,
                "isPartial" : false,
                "indexVersion" : 2,
                "direction" : "forward",
                "indexBounds" : {
                    "a" : [
                        "(8000.0, inf.0]"
                    ]
                }
            }
        },
        "rejectedPlans" : [ ]
    },
    "executionStats" : {
        "executionSuccess" : true,
        "nReturned" : 1999,
        "executionTimeMillis" : 5,
        "totalKeysExamined" : 1999,
        "totalDocsExamined" : 1999,
        "executionStages" : {
            "stage" : "FETCH",
            "nReturned" : 1999,
            "executionTimeMillisEstimate" : 10,
            "works" : 2000,
            "advanced" : 1999,
            "needTime" : 0,
            "needYield" : 0,
            "saveState" : 15,
            "restoreState" : 15,
            "isEOF" : 1,
            "invalidates" : 0,
            "docsExamined" : 1999,
            "alreadyHasObj" : 0,
            "inputStage" : {
                "stage" : "IXSCAN",
                "nReturned" : 1999,
                "executionTimeMillisEstimate" : 0,
                "works" : 2000,
                "advanced" : 1999,
                "needTime" : 0,
                "needYield" : 0,
                "saveState" : 15,
                "restoreState" : 15,
                "isEOF" : 1,
                "invalidates" : 0,
                "keyPattern" : {
                    "a" : 1
                },
                "indexName" : "a_1",
                "isMultiKey" : false,
                "multiKeyPaths" : {
                    "a" : [ ]
                },
                "isUnique" : false,
                "isSparse" : false,
                "isPartial" : false,
                "indexVersion" : 2,
                "direction" : "forward",
                "indexBounds" : {
                    "a" : [
                        "(8000.0, inf.0]"
                    ]
                },
                "keysExamined" : 1999,
                "seeks" : 1,
                "dupsTested" : 0,
                "dupsDropped" : 0,
                "seenInvalidated" : 0
            }
        }
    },
    "serverInfo" : {
        "host" : "iz2zecqalqk7c59mfkog6gz",
        "port" : 27017,
        "version" : "3.4.1",
        "gitVersion" : "5e103c4f5583e2566a45d740225dc250baacfbd7"
    },
    "ok" : 1
}

executionStats.executionSuccess:是否执行成功

executionStats.nReturned:查询的返回条数

executionStats.executionTimeMillis:整体执行时间

executionStats.totalKeysExamined:索引扫描次数

executionStats.totalDocsExamined:document扫描次数

executionStats.executionStages.stage:这里是FETCH去扫描对于documents

executionStats.executionStages.nReturned:由于是FETCH，所以这里该值与executionStats.nReturned一致

executionStats.executionStages.docsExamined:与executionStats.totalDocsExamined一致

allPlansExecution

allPlansExecution模式是将所有的执行计划均进行executionStats模式的操作

对Explain返回逐层分析
第一层，executionTimeMillis

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

有3个executionTimeMillis，分别是:

  1. executionStats.executionTimeMillis
    该query的整体查询时间
  2. executionStats.executionStages.executionTimeMillis
    该查询根据index去检索document获取具体数据的时间
  3. executionStats.executionStages.inputStage.executionTimeMillis
    该查询扫描index所用时间
第二层，index与document扫描数与查询返回条目数

这里主要谈3个返回项，nReturned，totalKeysExamined与totalDocsExamined，分别代表该条查询返回的条目、索引扫描条目和文档扫描条目。

很好理解，这些都直观的影响到executionTimeMillis，我们需要扫描的越少速度越快。

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

nReturned=totalKeysExamined & totalDocsExamined=0
（cover index，仅仅使用到了index，无需文档扫描，这是最理想状态。）

或者

nReturned=totalKeysExamined=totalDocsExamined(需要具体情况具体分析)
（正常index利用，无多余index扫描与文档扫描。）

如果有sort的时候，为了使得sort不在内存中进行，我们可以在保证nReturned=totalDocsExamined的基础上，totalKeysExamined可以大于totalDocsExamined与nReturned，因为量级较大的时候内存排序非常消耗性能。

第三层，Stage状态分析

stage的类型:

COLLSCAN

IXSCAN

FETCH

SHARD_MERGE

SORT

LIMIT

SKIP

IDHACK

SHARDING_FILTER

COUNT

COUNTSCAN

COUNT_SCAN

SUBPLA

TEXT

PROJECTION

对于普通查询，我们最希望看到的组合有这些：

Fetch+IDHACK

Fetch+ixscan

Limit+（Fetch+ixscan）

PROJECTION+ixscan

SHARDING_FILTER+ixscan

对于count查询，希望看到的有：

COUNT_SCAN

不希望看到的有:

COUNTSCAN

uevol14
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
MongoDB 性能调优
悦分享
01-12 895
Profiling 功能肯定是会影响效率的，但是不太严重，原因是他使用的是 system.profile 来记录，而 system.profile 是一个 capped collection 这种 collection 在操作上有一些限制和特点，但是效率更高。MongoDB 从一面世就得到众多开源爱好者和团队的重视，在常用的监控框架如 cacti、Nagios、Zabbix 等基础上进行扩展，进行 MongoDB 的监控都是非常方便的，有兴趣的朋友可以自已试试。如果读量很大，那么创建索引还是比较划算的。
mongodb性能优化
itliwei的博客
12-24 303
一.范式化与反范式化 范式的优点： 1）范式化的数据库更新起来更加快； 2）范式化之后，只有很少的重复数据，只需要修改更少的数据； 3）范式化的表更小，可以在内存中执行； 4）很少的冗余数据，在查询的时候需要更少的distinct或者group by语句。 范式的缺点： 1）范式化的表，在查询的时候经常需要很多的关联，因为单独一个表内不存在冗余和重复数据。这导致，稍微复杂一些的查询
MongoDB优化与一些需要注意的细节
dp83166019po的博客
12-09 664
这里总结下这段时间使用mongo的心得，列出了几个需要注意的地方。 系统参数及mongo参数设置 mongo参数主要是storageEngine和directoryperdb，这两个参数一开始不选定后续就无法再更改。directoryperdb主要是将数据库分文件夹存放，方便后续的备份及数据迁移。storageEngine（存储引擎）默认使用的是MMAPv1，推荐使用3.0新加入的引擎wired...
提高MongoDB效率十大优化方式
最新发布
jia12216的专栏
05-29 1297
第一：单次批量查询比循环逐条查询更快； 第二：尽量避免嵌入不断增加的数据； 第三：预填充数据； 第四：尽可能预先分配空间； 第五：文档要自给自足； 第六：避免使用$where； 第七：编写代码处理数据完整性问题； 第八：使用正确的类型； 第九：用简单唯一的id替换掉_id。
MongoDB 性能优化五个简单步骤
frank1998819
10-14 603
MongoDB 一直是最流行的 NoSQL，而根据 DB-Engines Ranking 最新的排行，时下 MongoDB 已经击败 PostgreSQL 跃居数据库总排行的第四位，仅次于 Oracle、MySQL 和 Microsoft SQL Server，此文中总结了如何对 MongoDB 进行性能调优，本文系OneAPM工程师编译整理。大家在使用 MongoDB 的时候有没有碰到过性能问...
MongoDB优化
wuxingge的博客
03-24 559
MongoDB 的优化可以涉及多个方面，包括查询优化、索引优化、数据模型设计、服务器配置和集群策略。
MongoDb优化指南
12-16
1、为什么选择MongoDB？ 1、性能 在大数据时代中，大数据量的处理已经成了考量一个数据库最重要的原因之一。而MongoDB的一个主要目标就是尽可能的让数据库保持卓越的性能，这很大程度地决定了MongoDB的设计。在一个...
MongoDB优化心得分享
12-16
在本文中，我们将深入探讨一些关键的MongoDB优化策略，这些策略来自于实际使用中的心得体验。 1. **存储引擎的选择**： MongoDB 默认的存储引擎是MMAPv1，但在3.0版本后，引入了wiredTiger引擎，它提供了显著的...
mongodb之优化
q936889811的博客
03-13 354
1、慢查询 开启： use ntrailcenter db.setProfilingLevel(1,1000) 关闭： db.setProfilingLevel(0) operationProfiling： mode: slowOp slowOpThresholdMs： 100 基于上述配置，MongoDB 会将超过 100ms 的请求记录到对应DB 的 system.profile ...
MongDB优化
centaurusR的博客
10-07 282
#MongDB优化 ​ MongoDB 是高性能数据，但是在使用的过程中，偶尔还会碰到一些性能问题。MongoDB和其它关系型数据库相比，例如 SQL Server 、MySQL 、Oracle 相比来说，相对较新，所以很多开发、DBA往往是注重功能的实现，而忽视了性能的要求。其实，MongoDB和 SQL Server 、MySQL 、Oracle 一样，一个 数据库对象的设计调整、索引的创建、语句的优化，都会对性能产生巨大的影响。 为充分挖掘MongoDB性能，简单列举以下Mongodb优化方式：
mongdb性能优化
08-11
自己整理的mongodb性能优化文档,包括监控和优化两部分
MongoDB优化浅析
雪辉博客
12-01 810
文章目录MongoDB优化浅析一、MongoDB优化整体思路二、慢查询日志分析2.1 简介2.2 慢查询日志的使用2.3 慢查询日志内容详解三、执行计划分析3.1 简介3.2 执行计划内容详解四、索引分析4.1 基本命令4.2 索引分类4.2 索引的属性五、总结 MongoDB优化浅析 一、MongoDB优化整体思路   MongoDB的查询语句优化与关系型数据库类似，简单来说就是通过慢查询日志找...
MongoDB使用和优化
b0207191的博客
04-08 473
一、前言 遇到问题可以先查看官方的用户手册。 # 当前最新版本用户手册 https://docs.mongodb.com/manual/ # v3.2版本用户手册 https://docs.mongodb.com/v3.2/ 官方命令表 https://docs.mongodb.com/master/reference/command/ GitHub Awesome MongoDB...
关于MongoDB使用的优化总结
B_e_a_u_tiful1205的博客
11-03 1386
在画像平台人群圈选模块中，人群包的计算和存储是在CilckHouse引擎中完成的。但是基于CilckHouse在并发查询、集群压力方面的考虑，在数据输出模块中，并不是直接从CilckHouse中查询获取数据，而是在人群包数据计算完成后，通过数据同步模块将数据从CilckHouse同步到MongoDB中。MongoDB作为数据输出模块的底层数据存储和查询引擎，需要满足高效的数据写入和读取性能。同时人群包并不必保存全部的历史数据，mongoDB中只需保留最近N个版本的人群包数据即可，所以为了删除无效数据，还需要
MongoDB索引与性能优化
禅与计算机程序设计艺术
01-18 927
1.背景介绍 MongoDB是一种高性能、灵活的NoSQL数据库，它支持文档存储和查询。索引是MongoDB中性能优化的关键因素之一，它可以加速数据查询和排序操作。在本文中，我们将深入探讨MongoDB索引的核心概念、算法原理、具体操作步骤和数学模型公式，并通过实例代码来详细解释。 1.1 MongoDB索引的重要性 MongoDB中的数据存储为BSON文档，文档结构灵活，可以存储不同类型的...
mongodb优化步骤
qq_42407941的博客
06-07 475
1、弄清楚数据库的现状：数据库里存储的是什么类型的数据、做了哪些索引，有多少数据，数据库结构，主要操作；2、确定优化的目的；3、分析配置文件相关设置；4、使用db.serverStatus()获得状态，然后针对优化目的相关的内容进行分析；...
mongodb详细优化策略方案
Felix_CB的博客
01-11 6911
本文包括以下几个方面： – 安全措施 – 部署架构 – 系统优化 – 索引设计 – 备份监控 – 模式设计 – 程序配置 一、安全措施 1.1 为MongoDB集群启用认证鉴权 MongoDB服务器在默认安装下不启用鉴权。这意味着每个人都可以直接连接到mongod实例并执行任意数据库操作。建议按照文档启用鉴权 http://docs.mongoing.com/manual-zh/tutorial/...
MongoDB智能查询优化的问题
07-01 611
自动查询优化是MongoDB一个专门设计的功能。简言之，这个功能就是通过对查询进行分析，从而判断出更有利的索引使用策略。而这个智能的功能，实际潜伏着一些问题。 传统的查询优化是通过对语句进行语义分析来进行索引使用的预判，而MongoDB使用了一种更简单粗暴的方式，对查询的实际执行情况进行分析，它同时执行多条查询，每一条查询使用不同的索引，当其中一条返回时，终止其它的查询，并记录这次的结果，以
mongodb 优化
09-22
MongoDB的优化可以从以下几个方面考虑： 1. 索引优化：为频繁查询的字段创建索引，可以加快查询速度和提高性能。在选择索引字段时，需要根据业务需求和查询模式进行权衡。 2. 数据模型设计优化：合理设计文档结构...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值