Mongodb性能問題

Question

我正在使用mongodb，我需要更新我的文檔，說總共有1000個。我的文檔具有如下基本結構：

{ 
People:[1,2,3,4], 
Place:"Auckland" 
Event:"Music Show" 
} 

我在另一個虛擬機中同時運行10,000個線程。每個線程都會查找這些文檔（1000），查看這1000個文檔是否與查詢匹配並在People數組中推送一個數字。假設如果線程100在這1000個相關文檔中找到了500個，那麼它會將所有500個文檔的People數組中的數字100推送出去。 爲此，

我使用每個線程（10000）命令

update.append("$push",new BasicDBObject("People",serial_number)); 
updateMulti(query,update); 

我觀察這些就地升級（多查詢）表現不佳。 這是由於寫入鎖定引起的問題嗎？ 每個線程（10000）都會更新與查詢相關的文檔？ - 所以似乎有很多「等待」 有沒有更有效的方法來做這些「推」操作？ 「UpdateMulti」是否是正確的方法？

釷ANK你很大的反響 - 編輯和添加一些更多的信息

一些設計背景：

您是我們的問題的理解是正確的。我們有10000個線程，每個線程代表一個「演員」，每次更新多達1000個實體（基於適當的查詢），每次推送一次。

反轉模型導致我們導致一些破碎的用例（從我們的領域的角度來看）導致我們加入主要實體的「狀態」（現在將分散在許多集合中） - 例如：這些操作中的每一個都是該實體的狀態變化 - E具有狀態（e1，e2，e3，e4，e5） - 因此e1至e5表示爲由10,000個線程/進程更新的聚合數組，這些線程/進程表示外部應用程序的動作。

我們需要接近實時聚合，因爲另一組「演員」查看e1到e5的這些「狀態」，然後通過另一個通道適當地響應「陣列中的元素」。

在這種情況下，什麼應該是「理想」的設計策略 - 加快寫入速度。 將分片的幫助 - 是否有一個「量級」的啓發式 - 在什麼鎖定％我們應該碎片等。

Answer 1

這是一個問題，因爲你的模式設計。

$push對多個文檔（尤其是來自多個線程）的多個值的效率極低。寫鎖不是問題，而是你的設計成爲問題。此外，您持續增長的文檔意味着更新不「到位」，您的收藏快速分散。

看起來你的模式是「顛倒」。您有10,000個主題希望將數字代表人物（我假設人數非常多）添加到少量文檔（1000），這些文檔將變得非常龐大。在我看來，如果你想將某些東西嵌入其他東西中，你可能會考慮代表人物的集合，然後嵌入這些人被發現的事件 - 至少你將每個人的數組大小限制在1000人以內，更新將分佈在大量文檔中，顯着減少爭用。

另一種方法是簡單地記錄出席的事件/人員，然後再對原始數據進行彙總，但不知道您對此應用程序的要求是什麼，很難知道哪種方式會產生最佳結果 - 你選擇的方式絕對不可能給你帶來好的表現。