從性能角度來看，嵌入MongoDB與參考相比

Question

從性能的角度看，嵌入效果更好： 「如果性能是一個問題，嵌入」。 （http://www.mongodb.org/display/DOCS/Schema+Design）和大多數指南總是說包含應嵌入。

但是我不確定是這種情況。假設我們有兩個對象：Blog和Post。博客包含帖子。

現在正在嵌入博客將有以下問題的所有帖子：

1. 尋呼。由於無法過濾嵌入對象，因此我們將始終獲取所有帖子，並需要在應用程序中將其過濾掉。
   
2. Filtering。與之前一樣，當在帖子內搜索單詞時，將無法從MongoDB過濾嵌入的收藏集。
   
3. 插入。我認爲插入到集合比插入到嵌入對象更快。它是否正確？這是寫在任何地方？
   
4. 更新。和以前一樣，小文檔（Post）內嵌入更新字段可能會更快，然後內聯更新Blog的大文檔內的帖子。它是否正確？

考慮到上述所有情況，我會選擇在引用Blog的單獨集合中發佈帖子。這是正確的結論嗎？

（注：請不要因素文件大小限制在響應中，假設每個博客都會有最多1000個）

Answer 1

1.Paging可能與$slice操作：

db.blogs.find({}, {posts:{$slice: [10, 10]}}) // skip 10, limit 10 

2.Filtering也可能的：

db.blogs.find({"posts.title":"Mongodb!"}, {posts:{$slice: 1}}) //take one post 

3,4。一般來說，我猜你是在談論小的性能差異。這不是火箭科學，它最多隻有1000個博客。

你說：

Is this the correct conclusion? 

沒有，如果你關心性能（一般來說，如果系統將是小，你可以用單獨的文件去）。

我已經做了關於3,4-小的性能測試，這裏是結果：

----------------------------------------------------------------- 
| Count/Time | Inserting posts | Adding to nested collection | 
-------------|--------------------------------------------------    
| 1  | 1 ms    | 28 ms      | 
| 1000  | 81 ms   | 590 ms      | 
| 10000 | 759 ms   | 2723 ms     | 
--------------------------------------------------------------- 

Answer 2

1. 可以嵌入元素
與 「$切片」分頁
2. 您可以用「field1.field2」進行搜索：/ aRegex/ with aRegex是您搜索的詞。但照顧性能。

約3.和4.我沒有證據數據。

BTW 2集合可以更容易編碼/使用/管理。你可以簡單的每個 '博客' 文件中註冊blogId並添加「blogId」： 「1234ABCD」在所有查詢

Answer 3

至於3 & 4，如果你插入一個嵌套的文件，它基本上是一個更新。

這對於您的性能可能會非常糟糕，因爲插入通常會附加到數據的結尾，而且工作正常且快速。另一方面，更新可能會更棘手。

如果你的更新沒有改變文檔的大小（意味着你有一個鍵\值對，只是將值更改爲佔用相同空間量的新值），那麼你會沒事的，但是當您開始修改文檔並添加新數據，則會出現問題。

問題是，雖然MongoDB爲每個文檔分配的空間比它需要的多，但可能還不夠。如果您插入的文檔大小爲1K，則MongoDB可能會爲文檔分配1.5k，以確保對文檔的微小更改有足夠的空間進行擴展。如果您使用的分配空間不止一個，MongoDB必須獲取整個文檔並在數據的尾部重新寫入。

在獲取和重寫數據時會有明顯的性能影響，這些數據會被這種操作的頻率放大。更糟糕的是，當發生這種情況時，最終會在數據文件中留下空洞或未使用的空間。

這最終被複制到內存中，這意味着您最終可能會使用2GB的RAM來存儲您的數據集，而實際上數據本身只佔用1.5GB，因爲有0.5GB的口袋。這種碎片可以通過插入而不是更新來避免。它也可以通過修復數據庫來修復。

在下一個版本的MongoDB中將會有一個在線壓縮功能。