对不起我的英文,我需要有关mongodb索引的帮助。我有一个上限集合(大小:10GB),其中包含我的应用程序日志的一些字段。 示例结构:记录[_id,userId,sum,type,time,response,request]。我创建了复合索引:[userId,time,type]。我得到两个数组是userId为今天分组的记录,其中'type'是“null”和“1”。我的两个查询示例:
$group = array(
array(
'$match' => array(
'userId' => $userId,
'time' => array(
'$gt' => date("Y-m-d")
),
'type' => array('$ne' => null)
)
),
array(
'$group' => array(
"_id" => '$userId',
"total" => array('$sum' => '$sum'),
"count" => array('$sum' => 1)
),
)
);
$results = $collections->aggregate($group);
$group = array(
array(
'$match' => array(
'userId' => $userId,
'time' => array(
'$gt' => date("Y-m-d")
),
'type' => 1
)
),
array(
'$group' => array(
"_id" => '$userId',
"count" => array('$sum' => 1)
),
)
);
$results2 = $collections->aggregate($group);
如果当前用户今天收集了更多100000个文档 - 我的查询速度非常慢(超过10秒)。请给我一些关于创建正确索引的建议,谢谢。
答案 0 :(得分:0)
根据您发布的说明,正在使用正确的索引(BtreeCursor
),它只使用索引(即它是一个覆盖索引查询 - indexOnly
为真)并且没有在这种情况下匹配(n = 0
)。所以,一般都会检查出来,尽管$ne
作为第一个例子中的一个子句并不会非常有效。
然而,基于解释的主要问题可能是索引似乎没有完全在内存中。列出了13个产量,并且这样的查询产生的最常见原因是当它必须故障到磁盘以寻找内容时。因为,如前所述,它只使用索引,这些产量意味着磁盘的故障索引,因此表明整个索引不在内存中。
如果在此之后立即重新运行查询,它应该更快(假设索引实际上可以适合可用内存),因为索引将在第一次运行时被分页。如果它在第二次运行时仍然很慢并显示产量,那么你要么没有足够的内存来将索引保存在内存中,要么其他东西正在从内存中驱逐它,你基本上会有内存争用导致性能问题。