2013-02-26 7 views
0

我有以下情況:只是在查詢中使用MongoDB的指數

  • 我有一個文檔集合像
{a: 1, b: 'some string', c: 5, d: 7 } 
{a: 2, b: 'some another string', c: 5, d: 8 } 
{a: 3, b: 'yet another string', c: 5, d: 9 } 
  • 我允許用戶搜索使用自定義查詢,所以有時我可以搜索:
{a: 2, c:5} 
{c:5, d:8} 
  • 一些使用的字段的是強制性的(例如。 C)
  • 我想到了塞汀指標對C這樣的查詢會工作得更快,當我做:

db.my_collection.find({C:5})

它的偉大工程,但是當我啓動:

db.my_collection.find({C:5,d:8})

它消耗的時間相同ommount時withought索引:(

所以我的問題是:是否有可能建立一些類型的部分索引,以便查詢會排在首位的搜索裏面有索引鍵和比在那些追求他們的人內部?

回答

0

我原來的答案不準確,我沒有正確閱讀。

所以我的問題是:是否有可能建立一些類型的部分索引,以便查詢會在裏面有指標,而且比那些裏面他們withought鑰匙首位的搜索?

MongoDB將已經這樣做,但您可能在選擇性,格式和大小d和文檔整體上有問題。

即使MongoDB的已經過濾c通過索引它需要ScanObjects實際的數據,在分頁文件。

d的選擇性可能是這樣的,你是從c子句返回大量的文件並導致d的巨大掃描。

所以這些因素一起可能會讓您的查詢變慢。

通常解決這個問題的最好方法是不要在這裏使用部分索引,而只需要創建一個完整的複合索引。

+0

嗨我是不準確的 - 在我的例子中的索引只是在關鍵:c – 2013-02-26 12:22:02

+0

@WitekAdamus啊我認爲我最初實際上是誤讀,我只是假設了一些,並沒有完全閱讀它。我現在明白了;嗯是的,這可能是真的,一個'c'上的索引和'c'和'd'上的查詢會很慢,這取決於'd'是什麼以及'c'的選擇性,這是解決這個問題的典型方法是使用他們的複合索引 – Sammaye 2013-02-26 12:26:54

+0

@WitekAdamus好吧,我添加了一個答案,實際上回答了這個問題 – Sammaye 2013-02-26 12:47:08