奇怪的MongoDB /节点解释结果 [英] Odd MongoDB/Node Explain Results

问题描述

我想知道这一点...任何帮助将是真棒。

我有相同的查询，我在RoboMongo（CLI）中运行：

  db.post.find（{utc：{$ lte：utc}}）
 .sort ：-1}）。limit（100）.hint（{utc：-1}）
  

我的Node应用程序（使用Native驱动程序）：

  mo.post.find（{utc：{$ lte：utc}} ，{
 fields：{geo：0，bin：0，flg：0，mod：0，edt：0}，
 hint：{utc：-1}，sort：{utc：-1 }，limit：100 
}）。toArray（function（err，result）
  

当我查看解释为快速的一个，我得到：

pre> cursor：BtreeCursor utc_-1，
isMultiKey：false，
n：100，
nscannedObjects： 100，
nscanned：100，
nscannedObjectsAllPlans：100，
nscannedAllPlans：100，
scanAndOrder：false，
indexOnly false，
nYields：0，
nChunkSkips：0，
millis：0，
indexBounds：{
utc
[
ISODate（2015-01-07T00：47：32.786Z），
true
]
]
}，


而对于缓慢的：

  cursor：BtreeCursor utc_-1
 isMultiKey：false 
n：1 
 nscannedObjects：1 
 nscanned：1 
 nscannedObjectsAllPlans：1 
 nscannedAllPlans：1 
 scanAndOrder：false 
 indexOnly：false 
 nYields：0 
 nChunkSkips：0 
 millis：0 
 indexBounds：{
 utc：[1] 
 0：[2] 
 0：2015-01-07T22：50：05.000Z
 1：true 
  -  
  -  
}  -  
  

有没有人知道这里可能发生什么？

解决方案

更新：似乎是一个2.0.x的问题...

我刚刚使用2.0.x和1.4.x运行完全相同的查询。当Limit = 1时，两者都执行快速〜1ms。当Limit = 2时，1.4.x版本保持大约1ms，但2.0.x版本跳转到25ms。

在星期四，2015年1月8日上午9:04:05 UTC- 8，Joshua Abrams写道：
有趣的...使用1.4.x的完全相同的查询产生一个适当的解释，其中n = 2（等等）。这会影响性能吗？当我运行一个查询，其中Limit = 1它是快的（如预期），但当Limit = 2它是100x慢...

2015年1月8日星期四8： 52:28 UTC-8，christkv写道：
不是真的。我的建议是做一个最小的可重复的测试用例（代码和数据），并在jira.mongodb.com上打开一张票。很难知道可能发生什么。它不可能是司机，但一个从来不知道。尝试使用1.4.x分支，至少排除它是一个2.0.x分支问题。

2015年1月8日星期四5:47:45 PM UTC + 1，Joshua Abrams写道：
刚刚检查，我使用的驱动程序2.0.12。任何其他想法？

星期四，2015年1月8日上午8:23:16 UTC-8，christkv写道：
explain只是重新调整所有的结果在驱动程序中而不是部分结果。从而得到计划。有一件事，你可能是因为你在早于1.4.19的驱动程序，其中batchSize设置为1的错误。

1月8日星期四，2015 5:01:42 PM UTC + 1，Joshua Abrams写道：
我最近有一套性能问题的驱动程序。
Limit = 1 = 1ms，Limit> 1 = 150ms（mongo-melt-down）

不知道根本原因是什么 - 当我无法获得正确的解释：
MongoDB本机节点驱动程序：解释是否已损坏？

I'm trying to figure this out... any help would be awesome.

I have identical queries that I'm running in RoboMongo (CLI):

db.post.find({utc:{$lte:utc}})
.sort({utc:-1}).limit(100).hint({utc:-1})

and my Node app (using the Native driver):

mo.post.find({utc:{$lte:utc}},{
  fields:{geo:0, bin:0, flg:0, mod:0, edt:0},
  hint:{utc:-1}, sort:{utc:-1}, limit:100
}).toArray(function(err, result)

For some reason, the performance is crazy different. The top one runs in under 1ms, the bottom takes over 100ms. When I review the 'explain' for the fast one I get:

"cursor" : "BtreeCursor utc_-1",
    "isMultiKey" : false,
    "n" : 100,
    "nscannedObjects" : 100,
    "nscanned" : 100,
    "nscannedObjectsAllPlans" : 100,
    "nscannedAllPlans" : 100,
    "scanAndOrder" : false,
    "indexOnly" : false,
    "nYields" : 0,
    "nChunkSkips" : 0,
    "millis" : 0,
    "indexBounds" : {
        "utc" : [ 
            [ 
                ISODate("2015-01-07T00:47:32.786Z"), 
                true
            ]
        ]
    },

and for the slow one:

cursor: "BtreeCursor utc_-1"
isMultiKey: false
n: 1
nscannedObjects: 1
nscanned: 1
nscannedObjectsAllPlans: 1
nscannedAllPlans: 1
scanAndOrder: false
indexOnly: false
nYields: 0
nChunkSkips: 0
millis: 0
indexBounds: {
utc: [1]
0:  [2]
0:  "2015-01-07T22:50:05.000Z"
1:  true
-
-
}-

Does anyone have any idea what could be going on here? They are running off the same database with the same indexes?

解决方案

Update: seems to be a 2.0.x problem...

I just ran the exact same query with 2.0.x and 1.4.x. When Limit = 1, both perform fast ~1ms. When Limit = 2, the 1.4.x version stays around 1ms but the 2.0.x version jumps to 25ms. So, it's not just an issue with the explain output - that's just a symptom of the problem.

On Thursday, January 8, 2015 9:04:05 AM UTC-8, Joshua Abrams wrote: Interesting... exact same query using 1.4.x yields a proper explain where n = 2 (and so on). Could this be affecting performance? When I run a query where Limit = 1 it's fast (as expected) but when Limit = 2 it's 100x slower...

On Thursday, January 8, 2015 8:52:28 AM UTC-8, christkv wrote: not really. My suggestion is to make a minimal reproducible test case (code and data) and open a ticket on jira.mongodb.com. kind of hard to know what could be happening. it's unlikely to be the driver but one never knows. try with the 1.4.x branch aswell just to at least rule out that it's a 2.0.x branch issue.

On Thursday, January 8, 2015 5:47:45 PM UTC+1, Joshua Abrams wrote: Just checked and I'm using 2.0.12 of the driver. Any other thoughts?

On Thursday, January 8, 2015 8:23:16 AM UTC-8, christkv wrote: explain is just retuning all the results in the driver instead of partial results. thus you get the plan. One thing that comes to mind might be that you are on a driver earlier than 1.4.19 that had an error where batchSize was set to 1.

On Thursday, January 8, 2015 5:01:42 PM UTC+1, Joshua Abrams wrote: I've been having a suite of performance issues lately with the driver. Limit = 1 = 1ms, Limit > 1 = 150ms (mongo-melt-down)

Not sure what the root cause it - and it's impossible to debug when I can't get a proper explain: MongoDB Native Node Driver: Explain is Broken?

这篇关于奇怪的MongoDB /节点解释结果的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！