子文檔

Question

我一直在尋找到陣列上的MongoDB（多鍵）索引的陣列上了解的指標，我有以下幾個問題，我一直沒能找到在多文檔：

子文檔

的數組索引上所以，如果我有一個陣列場，看起來像：

{field : [ 
    {a : "1"}, 
    {b : "2"}, 
    {c : "3"} 
    ] 
} 

我對field.a和field.c individ只查詢ually（不是兩個一起），相信我有以下選項之間進行選擇：

1. db.Collection.ensureIndex({field : 1});
2. db.Collection.ensureIndex({field.a : 1}); db.Collection.ensureIndex({field.c : 1});

即：在整個陣列上的索引;或嵌入字段中的兩個索引。現在，我的問題是：

• 你如何選擇1整個陣列上的可視化指數（它甚至有用）？什麼查詢是這樣一個有用的索引？
• 鑑於我所描述的查詢情況，上面兩個選項哪個更好，爲什麼？

Answer 1

你是正確的，如果你只在一個領域數組中的值查詢，這兩個指標會，在某種意義上，幫助您使您的查詢更好的性能。

然而，看看以下3個疑問：

> db.zaid.save({field : [{a: 1}, {b: 2}, {c: 3}] }); 
> db.zaid.ensureIndex({field:1}); 
> db.zaid.ensureIndex({"field.a":1}); 

#Query 1 
> db.zaid.find({"field.a":1}) 
{ "_id" : ObjectId("50b4be3403634cff61158dd0"), "field" : [ { "a" : 1 }, { "b" : 2 }, { "c" : 3 } ] } 
> db.zaid.find({"field.a":1}).explain(); 
{ 
    "cursor" : "BtreeCursor field.a_1", 
    "nscanned" : 1, 
    "nscannedObjects" : 1, 
    "n" : 1, 
    "millis" : 0, 
    "nYields" : 0, 
    "nChunkSkips" : 0, 
    "isMultiKey" : true, 
    "indexOnly" : false, 
    "indexBounds" : { 
     "field.a" : [ 
      [ 
       1, 
       1 
      ] 
     ] 
    } 
} 

#Query 2 
> db.zaid.find({"field.b":1}).explain(); 
{ 
    "cursor" : "BasicCursor", 
    "nscanned" : 1, 
    "nscannedObjects" : 1, 
    "n" : 0, 
    "millis" : 0, 
    "nYields" : 0, 
    "nChunkSkips" : 0, 
    "isMultiKey" : false, 
    "indexOnly" : false, 
    "indexBounds" : { 

    } 
} 

#Query 3 
> db.zaid.find({"field":{b:1}}).explain(); 
{ 
    "cursor" : "BtreeCursor field_1", 
    "nscanned" : 0, 
    "nscannedObjects" : 0, 
    "n" : 0, 
    "millis" : 0, 
    "nYields" : 0, 
    "nChunkSkips" : 0, 
    "isMultiKey" : true, 
    "indexOnly" : false, 
    "indexBounds" : { 
     "field" : [ 
      [ 
       { 
        "b" : 1 
       }, 
       { 
        "b" : 1 
       } 
      ] 
     ] 
    } 
} 

注意到第二個查詢不會有它的指數，即使你索引的數組，但第三個查詢確實。根據您打算如何查詢數據來選擇索引與考慮索引本身是否是您需要的一樣重要。在Mongo中，如果您不小心，索引的結構可以並且確實會對查詢的性能產生很大的影響。我認爲這解釋了你的第一個問題。

你的第二個問題是更開放一點，但我認爲答案也在於你期望如何查詢你的數據。如果你只會對匹配「fields.a」的值感興趣，那麼你應該在內存中爲你可能需要的其他索引節省空間。但是，如果您同樣可能查詢數組中的任何項目，並且您確信該數組無法無限增長（從不索引數組，這可能隨着時間的推移而增長到未綁定的大小。當數組達到1024字節時，將無法索引文件。），那麼你應該索引整個數組。一個例子可能是一張撲克牌的文件，其中包含一個數組描述用戶手中的每張牌。你可以在這個數組上索引，而不用擔心索引大小的邊界溢出，因爲一個手牌的數量不能超過52張。