• 售前

  • 售后

热门帖子
入门百科

一次因mongo查询不存在字段引发的变乱纪录

[复制链接]
麻辣鸡翅 显示全部楼层 发表于 2021-8-14 15:17:14 |阅读模式 打印 上一主题 下一主题
话说今天的一个小小的查询失误给了我比力深刻的教训,也让我对mongo有了更深刻的明白,下面我们来说说这个事变的原委:
我们常常使用阿里云子账号在DMS上查询线上数据库数据,今天也是平常的一次操作
聚集:
  1. XXXX_message<br>数据量约 600万
复制代码
我实行了下面的mongo查询:
  1. db.XXXX_message.find({"channel_id": "1000000009XXXX700XXXX"}).limit(20);
复制代码
但是上述语句中的 "channel_id" 字段不存在,真实字段应该是channel(有索引),属于失误操作
在实行过程中,我发现查询时间很久,于是中断了查询又重试了两次,还是很久,最后中断了查询,我意识到我想查的字段大概错了,于是看了下聚集索引,使用精确的字段检索得到结果
但就在这时间,一场事故也在悄然酝酿,2分钟后,阿里云监控中心打来告警电话,mongo数据库cpu、iops异常升高

早先并没有意识到是这个查询导致的,还以为是半小时前发布的版本大概有题目,于是立刻回滚了版本并开始项目检查
查了许久,并没有查到大概造成本次数据库异常告警的原因,项目对该库的依靠的操作的地方非常少。
当我们苦苦想不到原因的时间,我们去查了下相关慢sql日志,果然一道耗时约1800000ms的慢sql日志引起了我们的注意
这时间我似乎意识到了点什么,我立马查阿里云控制台查询汗青核对了我刚才查询的时间和数据库cpu、磁盘iops异常升高的时间节点
完全对上了,该起事故连续半小时左右,那条没有被成功中断的sql也实行了半小时左右

这让我很震惊,一次控制台查询居然导致整个数据库出现如此严肃的题目,mongo底层没有思量过不存在字段查扣题目吗?
我逐步平复心情,仔细回顾这件事变,我实验着从mongo和mysql的底层去明白这个题目
mongo自己是聚集型数据库,意味着每个聚集文档都可以有自己独立的数据结构,和mysql等关系型数据库的很告急的区别就是它没有固定的表结构,它包容且随性
当在查询一个不存在的字段的时间,它仍然按照普通查询检索数据,这时间它会全表扫描,也就是说在上述失误语句中,mongo底层检索了整个聚集的数据集,
遍历了该聚集所有的磁盘块,这才导致磁盘iops升高且cpu升高。
这次经历让我觉得我有须要记录下相关心得,大概对于许多高级技能职员,这些东西都是很轻易明白和规避的事变,但大多数人对此大概并没有深刻熟悉
这次事故让我对技能多了一层敬畏,这有助于我在今后的代码实践和操作中更加审慎和多一层思索,盼望大家以此为戒!此文共勉!
到此这篇关于一次因mongo查询不存在字段引发的事故记录的文章就介绍到这了,更多相关mongo查询不存在字段的事故内容请搜刮草根技术分享从前的文章或继承浏览下面的相关文章盼望大家以后多多支持草根技术分享!

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x

帖子地址: 

回复

使用道具 举报

分享
推广
火星云矿 | 预约S19Pro,享500抵1000!
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

草根技术分享(草根吧)是全球知名中文IT技术交流平台,创建于2021年,包含原创博客、精品问答、职业培训、技术社区、资源下载等产品服务,提供原创、优质、完整内容的专业IT技术开发社区。
  • 官方手机版

  • 微信公众号

  • 商务合作