創建索引，而更新的文件

我有收集我更新添加一個新的領域。文件看起來像：創建索引，而更新的文件

{"A": "P145", "B":"adf", "C":[{"df":"14", "color":"blue"},{"df":17}], 
    "_id":ObjectID(....), "Synonyms":{"Synonym1": "value1", 
      "Synonym2": ["value1", "value2"]}}

在更新我加入新的元素到C

我想創建一個在球場上一個指數和B，A和B 20206個的獨特領域。對數據庫的查詢將基於這些字段。「_id」默認設置。

我計劃collection.ensure_index({"A":1, "B":1}, background=True)

多少時間可能需要做的呢？它會比基於「_id」的系統索引更快？

來源

2015-06-23 Llopis

所花費的時間添加索引將取決於您的硬件，但與20206你描述不應該很長，大多數硬件需要記錄一個簡單的索引量。

查詢通過其中指定A和B，或只是一個，但不只是B中的索引（即全覆蓋 - 指數從左至右覆蓋所以，除非你包括A的選擇，指數不能被使用）將更快地檢索結果。除非你用_id搜索，否則_id的默認索引根本不會幫你;對A和B的查詢將不得不執行完整的收集掃描，而不提供您建議的索引，這比索引掃描慢幾個數量級。

插入會稍微慢一點的指數將需要太多更新，但再次與數量相對較少的總的文件，這是不太可能是一個大的開銷。

如果您使用A和B來識別要更新的文檔，更新C更改可能會更快，因爲它們將從更快的搜索中受益，並且一旦找到數據就不會影響更新因爲指數不需要改變。由於絕對性能將針對您的硬件，所以如果您關心它，最好的辦法是在數據副本上（在類似的硬件上）嘗試一下，然後測量性能是否滿足您的需求。 output from explaining the query可以幫助您理解索引如何影響查詢性能。

來源

2015-06-23 08:55:17

我不打算插入新文檔的收集，我會添加更多的字段。但是我最終可能會爲每個領域做兩個索引。謝謝 – Llopis

@Llopis是否做一個或兩個索引取決於你的訪問模式 - 如果你總是用A和B來查詢，那麼單個索引是完美的，如果你正在做兩個索引的混合，那麼對於某些查詢，兩個索引可能會更好，但是當您查詢A和B時，速度會更慢。您始終可以執行兩個索引 - A和B，以及B，這將覆蓋包含A和B以及查詢的查詢與A或B（因爲A被A + B覆蓋，不需要明確索引A）。 –

好，創建索引所用的時間完全取決於硬件（系統）使用的是和記錄數量。對於大約20K條記錄，它應該很快，而且不需要更多時間。在最壞的情況下最多幾秒鐘。很少有話題，但我看到你已經給出了背景真正的選擇，可能它不需要，因爲這些背景選項被用來創建一個非常大的數據集。請在創建索引時考慮一些事情，不僅是對於這個問題，而是一般。

當你前景 CREATE INDEX他們阻止操作，不會讓讀操作和理由的背景真的被使用。 http://docs.mongodb.org/v2.2/administration/indexes/
很大一部分與前景索引是該指數更緊湊，更好的比較背景。因此應該是優選的。
好消息是，在長期來看，無論是背景索引創建和前景提供相同的性能和事一點兒也不哪種方式創建索引。 ...快樂的Mongoing ..;-)

- $

來源

2015-06-23 10:03:22

點號1是我使用背景的主要原因，我現在正在更新它。你能否提供一些關於第2點的參考？編輯：我應該注意到我已經標記了一個答案，因爲我知道我在哪裏得到了這些信息， – Llopis

確實是利奧皮斯。儘管我從少數幾個消息來源讀到，但是現在我沒有回想起那些消息......給我一段時間，我確信我能找到消息來源。 –

[鏈接]（http://docs.mongodb.org/manual/tutorial/build-indexes-on-replica-sets）你可以在下面的內容中找到他們提到在後臺建立的結果是「不太緊湊的索引結構「[比較前景]。「在後臺構建索引需要比前臺索引構建更長的時間，並且導致索引結構不太緊湊，另外，後臺索引構建可能會影響主要的寫入性能，但是，在後臺構建索引允許設置要在MongoDB構建索引時持續進行寫操作「 –

創建索引，而更新的文件

回答

相關問題