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