將評論和文章放在一起，這里我有一個疑問，當評論數量很大以后，會不會導致在查詢文章列表頁的時候效率低下？如果將comments剝離到另一個collection里，這樣是不是能緩解只顯示文章列表的情況下的壓力{ "_id" : ObjectId(), "author" : "", "comment_num" : "", "comments" : [
{ "text" : "", "created" : ISODate(), "author" : ""
},
], "created" : ISODate(), "text" : "", "title" : ""
}
2 回答
白板的微信
TA貢獻1883條經驗 獲得超3個贊
最重要的有兩基本出發點： 1. 硬盤太慢； 2. 只要數據在內存里，就沒問題。
find
數據特別大了之后，在磁盤上讀好多數據，因為Memory Mapped File都會放在內存里，可是我們只需要里面的一小部分，最主要的問題是可能OS會把別的數據換頁到硬盤上。單就列出文章列表來說，內存就沒有被有效地利用。insert
在磁盤文件上，如果一個document一直長啊長，好多次，這不是一個好事。因為 如果新加入數據后，比如加了一個新評論，document變大了，原來的地方放不下了，就要找新的地方，以前的空洞會被重新利用。但是問題是，document位置變了，所有跟它有關的索引都要變。如果你還有個數組上的索引，比如發表評論的用戶名，那更新的索引就跟這個數組長度成線性關系。size
樓上在這點上說得很好。16MB的上限。
綜上，評論特別多的時候，會影響性能。
總結，schema設計要考慮
數據規模，經常訪問的數據只要在內存里，對訪問來說沒什么問題。上面第一條
find里提到的內存利用不充分，其實不是大問題。因為熱門文章的評論總有不少人看，放內存里也不錯。如果document一直長呀長，MongoDB會自動地在分配磁盤空間時多分配一些。與Access Pattern相適應。寫評論相對看文章看評論，太小了，Twitter的數據是平均發tweet 5K/s, 讀timeline 300K/s. 60倍呀！只要讀請求在內存里能滿足就好了。用MongoDB就可以不用另搞caching了。不是訪問真得特別大，寫特別多這樣極端的情況，都好說。真得到了那一天，MongoDB的sharding就派上用場了。
開發方便 產品的成本不僅僅是機器硬件、網絡的成本，更重要的是程序員的開發成本，工資都那么高……所以，寫著快捷方便，不容易出錯也是很重要的一點，對不？這也就解釋了為什么MongoDB文檔模型的靈活性廣受好評了。
慕神8447489
TA貢獻1780條經驗 獲得超1個贊
首先確認一點：當評論數量很大以后，不大會導致在查詢文章列表頁的時候效率低下。你可以再指定查詢結果集的document只返回部分field的數據(需要注意的是，如果對這種只包含部分field數據的document進行更新再保存時，有可能會出錯)，推薦這樣做，能夠很好的節省網絡帶寬。
此外，目前mongodb對于單個document的大小是有限制的，如果評論數量過多時，會有可能超過document的默認大小限制，這個時候就需要剝離comment了。
- 2 回答
- 0 關注
- 241 瀏覽
添加回答
舉報
0/150
提交
取消