【性能最佳实践】跟着我们一起玩转查询模式与性能分析!

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
云数据库 Redis 版,社区版 2GB
推荐场景:
搭建游戏排行榜
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
简介: MongoDB系列技术文章精选

欢迎阅读我们博客系列的第四篇,本文将深入探讨MongoDB的性能优化最佳实践。在这个系列里,我们会从多个重要维度讨论实现规模性能的关键考虑因素,包括:

  • 数据建模和内存大小,即工作集
  • 查询模式和性能分析(本期讨论内容)
  • 索引
  • 分片
  • 事务和读/写关注
  • 硬件和操作系统配置
  • 基准测试

为了确保应用程序的流畅运行,设计合适的查询模式并分析查询性能是至关重要的,同时,性能分析还能帮助您挑选出最合适的索引(您可以在本系列的上一篇文章中了解有关索引的深入探讨)。

使用最新的驱动程序

MongoDB的官方驱动程序是由负责核心数据库开发的同一个专业团队打造的。这些驱动程序的更新通常比数据库本身更频繁,大概每几个月就会发布一次新版本。我们建议您尽可能使用最新版本的驱动程序,并在您使用的编程语言中安装可用的本地扩展。为了确保这一过程能够顺利融入开发周期,您可以建立一个标准化的流程来测试和升级驱动程序。

您可以在MongoDB的官方网站上找到驱动程序的文档和源代码。此外,还可以通过加入MongoDB社区的邮件列表来获取关于更新的最新消息。

避免创建大型、无界限的文档

正如我们在本博客系列的第一篇文章中关于数据建模的讨论,MongoDB的文档大小上限为16MB。然而,在实际应用中,大部分文档的大小通常只有几KB或更小。

在应用程序设计中,应避免让文档大小无限增长。以电子商务应用为例,由于很难预测到每个产品将获得的顾客评价数量,因此通常只将一部分评价展示给顾客,如最受欢迎或最新的评价。
与其将产品和所有评价建模为一个单独的文档,更佳的做法是将其中一部分关键评价嵌入到产品文档中,以便快速访问。而其他不那么重要的评价则可以存放在独立的文档中,并通过引用或使用$lookup操作与产品文档关联。(有关更多具体的数据建模方法,可以在本系列的第一期文章中查看。)

只更新已更改的字段

相较于先在应用程序中检索整个文档并更新字段后,再将整个文档保存回数据库,更推荐直接对特定字段进行更新操作。这样做可以有效减少网络带宽的占用,并降低数据库的负载。

通过单个操作更新多个数组元素

您可以通过使用数组的完整表达式来执行复杂的数组操作,这包括对嵌套数组中的元素进行匹配和修改。通过在单个更新操作中应用 arrayFilters 选项,您可以精确指定哪些元素应该在数组字段中被修改。

使用阿里云MongoDB只读节点

如果您的应用程序需要执行复杂或耗时的任务,例如生成报告或进行ETL(提取、转换、加载)操作,那么您可能需要将这些分析型查询与其他业务操作隔离。通过这样的隔离,您可以确保不同类型的查询不会竞争系统资源,并且避免分析型查询导致工作数据集被驱逐出内存。
阿里云MongoDB可以提供具备独立连接地址的只读节点,适合独立系统直连访问,以减轻大量读请求给主从节点造成的压力。

使用解释计划来分析查询

您可以通过MongoDB的 explain( ) 方法测试应用程序中的查询,并显示关于查询解释计划的详细信息,包括查询是如何被解析和执行的。
使用了哪些索引
查询是否被索引覆盖
是否执行了内存排序,这表明索引是有效的
扫描的索引条目数量
返回的文档数量,以及读取的数量
查询解析所需的时间(以毫秒为单位)
拒绝的备用查询计划(使用allPlansExecution模式)

如果查询在不到1毫秒内完成,那么在典型的查询优化情况下,解释计划会显示耗时为0毫秒。
点击了解更多如何使用查询解释计划。

使用阿里云MongoDB慢查询分析

阿里云MongoDB支持查看实例的慢日志信息,帮助您发现、分析、诊断、跟踪慢日志,为您构建索引提供参考依据,从而提升实例资源的利用率。(默认情况下,只有执行时长超过100毫秒的操作会被认为是慢操作,您可以通过operationProfiling.slowOpThresholdMs参数来修改该时间阈值)

您可以进入阿里云MongoDB控制台,在目标实例页面的左侧导航栏,单击 CloudDBA > 慢日志。在慢日志页面可以查看实例的慢日志趋势、节点列表、慢日志统计和慢日志明细。

慢日志趋势:默认展示近15分钟的慢日志趋势图,最多支持查看近3小时的慢日志趋势图。
节点列表:展示各个节点的慢请求数量。

慢日志统计:展示慢日志的统计信息,包括执行总数、平均执行时间(毫秒)、最大执行时间(毫秒)、平均返回行和最大返回行等。

慢日志明细:展示慢日志的明细,包括执行完成时间、数据库、请求内容、客户端和执行时间(毫秒)等。

其他工具和实用程序

MongoDB数据库分析器可以收集详尽的信息,这些信息涉及到对正在运行的mongod实例的操作和命令。所有分析器收集的数据都会被写入到admin数据库中的system.profile集合,这是一个大小有限的集合。您可以查询这个集合以获得洞察,并且根据 要分析的数据粒度来调整日志级别。

mtools是一系列脚本工具,旨在帮助用户对MongoDB的日志文件进行解析、筛选和可视化。其中的mloginfo工具可以分析针对各个集合的查询,并对常见的查询模式进行分组,这有助于您识别出那些在资源消耗上最为显著的查询。(您可以在本系列的上一篇文章中了解有关索引的深入探讨)

阿里云MongoDB也提供了全面的监控功能,可以对实例各节点资源的运行情况进行监控,您可以点击查阅阿里云MongoDB的监控文档以获取全面的概述。

更多内容

以上是本期性能最佳实践系列的内容。在本系列的下一篇文章中,我们将讨论事务和读/写关注点。

点击了解更多关于性能优化的内容。

1月10日,阿里云MongoDB重磅发布了7.0版本,点击观看发布会回放:https://developer.aliyun.com/topic/mongodb_release

更多阿里云MongoDB内容介绍请访问官网了解:
https://www.aliyun.com/product/mongodb?utm_content=g_1000376457

相关实践学习
MongoDB数据库入门
MongoDB数据库入门实验。
快速掌握 MongoDB 数据库
本课程主要讲解MongoDB数据库的基本知识,包括MongoDB数据库的安装、配置、服务的启动、数据的CRUD操作函数使用、MongoDB索引的使用(唯一索引、地理索引、过期索引、全文索引等)、MapReduce操作实现、用户管理、Java对MongoDB的操作支持(基于2.x驱动与3.x驱动的完全讲解)。 通过学习此课程,读者将具备MongoDB数据库的开发能力,并且能够使用MongoDB进行项目开发。   相关的阿里云产品:云数据库 MongoDB版 云数据库MongoDB版支持ReplicaSet和Sharding两种部署架构,具备安全审计,时间点备份等多项企业能力。在互联网、物联网、游戏、金融等领域被广泛采用。 云数据库MongoDB版(ApsaraDB for MongoDB)完全兼容MongoDB协议,基于飞天分布式系统和高可靠存储引擎,提供多节点高可用架构、弹性扩容、容灾、备份回滚、性能优化等解决方案。 产品详情: https://www.aliyun.com/product/mongodb
相关文章
|
5月前
|
存储 算法 编译器
【霍罗维兹数据结构】数据抽象化 | 时间复杂度 | 性能分析与性能度量
【霍罗维兹数据结构】数据抽象化 | 时间复杂度 | 性能分析与性能度量
41 0
|
存储 监控 Oracle
定位任意时刻性能问题,持续性能分析实践解析
定位任意时刻性能问题,持续性能分析实践解析
定位任意时刻性能问题,持续性能分析实践解析
|
Web App开发 监控 前端开发
前端如何进行网站性能分析及优化性能
前端如何进行网站性能分析及优化性能
|
机器学习/深度学习 Web App开发 JSON
Paddle模型性能分析工具Profiler:定位瓶颈点、优化程序、提升性能
1.Paddle模型性能分析工具Profiler:定位瓶颈点、优化程序、提升性能
|
Web App开发 程序员 SEO
关于web性能的思考与分享[03]——常用性能分析工具
关于web性能的思考与分享[03]——常用性能分析工具
115 0
关于web性能的思考与分享[03]——常用性能分析工具
|
Java 测试技术 Go
|
监控 关系型数据库 MySQL
eBCC性能分析最佳实践(0) - 开启性能分析新篇章
BCC是基于4.x kernel版本上的ebpf发展出来的一套性能分析工具集; eBCC,顾名思义则是extended BCC的缩写,是阿里巴巴内核团队在Aliyun Linux上对BCC项目的拓展,包含BCC本身已有的工具集,和我们新开发的一些小的工具; eBCC则是基于在最新的BCC版本0.9之上做了一些拓展。
2268 0
|
网络协议 Linux
eBCC性能分析最佳实践(2) - 一个简单的eBCC分析网络函数的latency
线上TCP链接是无处不在,经常出现的网络latency,究竟是发生在kernel的网络协议栈上?还是发生在网络本身链路上?静看eBCC如何分析?
1372 0
|
Linux
eBCC性能分析最佳实践(1) - 线上lstat, vfs_fstatat 开销高情景分析
最近,在某个业务线上,发现 lstat 对cpu sys的开销占用比较大,需要查找凶手...
1436 0