MongoDB的架構設計，合併，合併用戶特定的字段默認域

每一個有搜索順序默認的權重（可能是一個普遍的民望）的對象數據庫。

當每個用戶使用這些對象時，用戶對搜索順序的個人加權被存儲在每個項目中（使用任何算法，例如使用頻率等）。

在SQL這是很容易通過連接對象和USER_OBJECTS表和做沿着

select ... coalesce(user_objects.personal_weighting, objects.default_weighting) 
    as sort_key order_by sort_key

線換句話說有事做，用戶可以搜索對象的整個數據庫（假設歌曲例如）。如果有一個用戶以前從未與之交互的對象（他們從未聽過的歌曲），則該對象的搜索順序權重基於爲每個對象存儲的默認值。如果用戶與某個對象進行了交互，那麼該對象的搜索順序權重將基於特定用戶的權重，並超過默認值。

有什麼有效的方法來在MongoDB中建模？使用CouchDB中的map/reduce會相當容易和高效，因爲爲map/reduced視圖存儲了索引，但我還沒有弄清楚如何在MongoDB中做到這一點。

任何想法？

來源

2011-07-08 L H

既然你不能爲這些查詢創建索引，這將是全表掃描......這是離線處理還是交互式查詢？ –

在線數據庫。用戶對標題進行全文搜索。 FTS在對象和user_objects上運行;結果通過object_id加入並按權重排序（默認或特定）。它在SQL或CouchDB中簡單而快速，但是我迷上了MongoDB。大多數其他數據適合文檔DB結構。這個數據庫會不斷增長（每次與一個對象的交互被記錄爲一個單獨的日誌，所以我傾向於遠離CouchDB，因爲我已經讀過它隨着視圖變大而顯着減慢，我可以在Mongo中做到這一點，因爲地圖/減少，但沒有一個索引...緩慢必須有一個優雅的模式設計我失蹤 –

我認爲你可以使這個可擴展的唯一方法是：

爲僅包含了訪問對象的重量每個用戶創建一個單獨的集合。添加索引。然後從該集合中檢索最高權重的ObjectIds +權重。從原始集合中獲取頂級加權元素的ObjectIds +權重。合併這兩個列表並最終檢索所需的元素。

所有的查詢都被索引，所以這應該是快速的。結果集的分頁代碼更復雜（合併步驟），並且如果用戶想要檢查超出範圍，則不會工作得更快。讓我們說第50頁左右（就像google一樣禁用它）。

來源

2011-07-08 13:13:59

謝謝隊友假設加權算法是有效的，用戶通常不會深入到結果頁面深入希望在全文搜索之後不會太長）我一直在思考這些問題，但我只是不太確定在MongoDB中合併結果集，那麼客戶端是否做得最好？我發現「合併「作爲最近添加到MongoDB的函數，但是我在文檔中看到的引用是斯巴達。 –

Yepp，你必須處理合並在cl ient端。我還沒有聽說過這個新的「合併」功能..但 –

http://www.mongodb.org/display/DOCS/MapReduce {merge：「collectionName」} - 此選項將合併新的數據到舊的輸出採集。換句話說，如果結果集和舊集合中都存在相同的鍵，則新鍵將覆蓋舊鍵。不太確定它是相關的。我傾向於和Postgres呆在一起。至少它是已知數量。我與性感的nosql dbs調情，但在一天結束時，它感覺不太舒服。隨着CouchDB的索引視圖，它是現貨，但性能越來越分貝似乎iffy ... –

MongoDB的架構設計，合併，合併用戶特定的字段默認域

回答

相關問題