2013-02-04 37 views
3

我有一個mongodb數據庫,其中有2個集合。 postsusersmongo db - 用於在webapp中實現相似功能的模式

帖子JSON結構是這樣

{title:"Title", content:"content goes here", postedby: "userid"} 

和用戶是喜歡

{username:"", name:""} 

現在我需要實現一個類似的功能,在用戶喜歡的職位。

解決方案1 ​​

我可以把內部數組中的用戶喜歡

{username:"", name:"", likes:[postid1,postid2..]} 

問題這裏是它很容易地查詢該用戶喜歡的職位。但很難得到喜歡文章的人。

解決方案2

我可以把內部數組中的帖子像

{title:"Title", content:"content goes here", postedby: "userid", like:[userid1,userid2 ..]} 

問題這裏是它容易得到喜歡誰的文章的人。但很難查詢用戶喜歡的帖子。

我該如何解決這個問題? 目前我正在考慮兩種方式。就像保持兩個集合中的內部數組一樣。我知道我保留了冗餘數據,是否是解決此問題的最佳方法?

回答

2

我認爲只要在文檔中保留喜歡的數組就足夠了。

您可以使用類似字段獲得用戶喜歡的帖子。如果你有類似領域的索引,性能也會很好。

唯一的缺點是使用這種方法後對象的大小根據數組的長度而變化。 Mongo在處理這些數據結構方面並不是很擅長,所以如果你有數千人喜歡留言,所有的id可能會降低查詢的性能,但是在一般的帖子中並沒有那麼多人喜歡,系統將工作正常,我相信。您可能會認爲對某個帖子的喜愛ID數量有限制(例如,保留最後的1000個用戶ID),以確保文檔的大小不會顯着增加。

6

我個人不會在這裏找一個類似的數組。

喜歡與一個喜歡太多帖子的人失去控制是太常見了;到這可能會阻礙您可以存儲在該文檔中的頂級用戶數據的數量。

你也必須在這裏考慮你的查詢模式。你很可能想要在多個用戶之間進行某種形式的聚合。目前要動態地做這樣的事情,你必須使用匯總框架:http://docs.mongodb.org/manual/applications/aggregation/(彙總前的報告:http://docs.mongodb.org/manual/use-cases/pre-aggregated-reports/也將是一個有用的工具,但我會跳過),使用$unwind

$unwind是一個存儲器內操作,特別是如果各使用者就座於至少1000個喜歡(50x1000已經推動內存限制$unwind和後$group$sort,其可以是對許多用戶的間隔聚合緩慢,其內存限制爲系統內存的10%)。總而言之,所有的聚合框架都不會使用高級方法來查詢這些喜歡的東西。

MongoDB中可以很容易地evne存儲這種結構雖然在其gorwing形式,因爲子文檔就像是每個條目,所以你可以只使用2種尺寸(http://docs.mongodb.org/manual/reference/command/collMod/#usePowerOf2Sizes)分配的功率來彌補你通常會得到的問題,也許12個字節(碎片)與使用該結構。

所以考慮這個我會保持喜歡在一個單獨的集合。確實,你會失去在用戶文檔中容納喜歡的單一往返標記,但我相信我上面提到的是值得的。

+0

你可以告訴我,我應該有獨立的像收集...嗎? – ravisuhag

+1

@ravisuhag由於用戶可以擁有大量的喜歡,我可能會把這些喜歡的自己放入一個單獨的{'_id :(),user_id:(),media_id:(),collection:(),date_liked :()}「收藏」字段將讓您喜歡多個媒體項目,即牆壁帖子和視頻。 – Sammaye

4

問你自己的重要問題是你需要什麼不同的方式來獲取這些數據?

可以在第一種情況下詢問用戶誰喜歡特定的頁面,user.find({"likes":postId})和第二種情況下的相反查詢。但這是個好主意嗎?你想要避免在MongoDB中持續增長的文檔加上你可能不想知道特定用戶全部他們喜歡的頁面,以及特定頁面全部喜歡它的用戶。

那麼如何將喜歡的東西保存在自己的集合中,只保留用戶和網頁集合中的聚合(即計數)?您還可以選擇在頁面中保留最近的「N」個喜好或其他對您的應用程序及其性能最有用的其他選項。

很少有可能在不知道用例(即讀寫模式)和它周圍的需求的情況下在MongoDB中設計「理想」模式。

相關問題