重庆分公司,新征程启航
为企业提供网站建设、域名注册、服务器等服务
这篇文章主要介绍了如何解决正则表示式匹配引起的mongo数据库cpu占用率高问题,具有一定借鉴价值,感兴趣的朋友可以参考下,希望大家阅读完这篇文章之后大有收获,下面让小编带着大家一起了解一下。
成都创新互联长期为上千多家客户提供的网站建设服务,团队从业经验10年,关注不同地域、不同群体,并针对不同对象提供差异化的产品和服务;打造开放共赢平台,与合作伙伴共同营造健康的互联网生态环境。为杨浦企业提供专业的成都网站建设、成都做网站,杨浦网站改版等技术服务。拥有十余年丰富建站经验和众多成功案例,为您定制开发。某一天,监控到mongo数据库cpu使用率高了很多,查了一下,发现是下面这种语句引起的:
db.example_collection.find({ "idField" : { "$regex" : "123456789012345678" } , "dateField" : { "$regex" : "2019/10/10" }})
通常,遇到这种情况,我第一反应是缺少相关字段的索引,导致每执行一次这种语句都会全表扫描一次。
但是我用explain( )语句分析了下,发现上面所涉及的两个字段idField、dateField是有索引的,并且该语句也是有使用到索引的。如下为explain( )的结果:
mgset-11111111:PRIMARY> db.example_collection.find({ "idField" : { "$regex" : "123456789012345678"} , "dateField" : { "$regex" : "2019/10/10"}}).explain("queryPlanner") { "queryPlanner" : { "plannerVersion" : 1, "namespace" : "example_db.example_collection", "indexFilterSet" : false, "parsedQuery" : { "$and" : [ { "idField" : { "$regex" : "123456789012345678" } }, { "dateField" : { "$regex" : "2019/10/10" } } ] }, "winningPlan" : { "stage" : "FETCH", "inputStage" : { "stage" : "IXSCAN", "filter" : { "$and" : [ { "idField" : { "$regex" : "123456789012345678" } }, { "dateField" : { "$regex" : "2019/10/10" } } ] }, "keyPattern" : { "idField" : 1, "dateField" : 1 }, "indexName" : "idField_1_dateField_1", "isMultiKey" : false, "multiKeyPaths" : { "idField" : [ ], "dateField" : [ ] }, "isUnique" : false, "isSparse" : false, "isPartial" : false, "indexVersion" : 2, "direction" : "forward", "indexBounds" : { "idField" : [ "[\"\", {})", "[/123456789012345678/, /123456789012345678/]" ], "dateField" : [ "[\"\", {})", "[/2019/10/10/, /2019/10/10/]" ] } } }, "rejectedPlans" : [ ] }, "ok" : 1 }
查看mongo的日志发现,这种语句执行一次就要800~900ms,的确是比较慢。除非数据库cpu核数很多,要不然只要这种语句每秒并发稍微高一点,cpu很快就被占满了。
之后搜索了下,发现有可能是正则表达式的问题。原来,虽然该语句的确是使用了索引,但是explain( )语句的输出中还有一个字段"indexBounds",表示执行该语句时所需扫描的索引范围。说实话,上面那个输出中,我始终没看明白它那个索引范围。上面的语句对idField、dateField这两个字段都进行了普通的正则表达式匹配,我猜测它应该是扫描了整个索引树,所以导致索引并未实际提升该语句的查询效率。
我看了下数据库里面的数据,发现idField、dateField这两个字段完全没有必要进行正则匹配,进行普通的文本匹配就行。将正则匹配操作$regex去掉之后,再分析一下,结果是这样的:
mgset-11111111:PRIMARY> db.example_collection.find({ "idField" : "123456789012345678", "dateField" : "2019/10/10"}).explain("queryPlanner") { "queryPlanner" : { "plannerVersion" : 1, "namespace" : "example_db.example_collection", "indexFilterSet" : false, "parsedQuery" : { "$and" : [ { "idField" : { "$eq" : "123456789012345678" } }, { "dateField" : { "$eq" : "2019/10/10" } } ] }, "winningPlan" : { "stage" : "FETCH", "inputStage" : { "stage" : "IXSCAN", "keyPattern" : { "idField" : 1, "dateField" : 1 }, "indexName" : "idField_1_dateField_1", "isMultiKey" : false, "multiKeyPaths" : { "idField" : [ ], "dateField" : [ ] }, "isUnique" : false, "isSparse" : false, "isPartial" : false, "indexVersion" : 2, "direction" : "forward", "indexBounds" : { "idField" : [ "[\"123456789012345678\", \"123456789012345678\"]" ], "dateField" : [ "[\"2019/10/10\", \"2019/10/10\"]" ] } } }, "rejectedPlans" : [ ] }, "ok" : 1 }
可以看到,仍然使用到了索引,并且索引扫描范围是仅限于一个值的。
后来跟开发人员确认了下,该语句确实没必要使用正则匹配,就让他把正则匹配去掉了。之后就没有再出现问题了,mongo慢日志中也未再出现该语句。
感谢你能够认真阅读完这篇文章,希望小编分享的“如何解决正则表示式匹配引起的mongo数据库cpu占用率高问题”这篇文章对大家有帮助,同时也希望大家多多支持创新互联网站建设公司,,关注创新互联行业资讯频道,更多相关知识等着你来学习!