Mahout的優化：多線程TopItems.getTopUsers（）和TopItems.getTopItems（）

Question

我們已制訂了以下系統：
沒有用戶的：〜500K
沒有項目的：〜100K

UserSimilarity userSimilarity = new TanimotoCoefficientSimilarity(dataModel);  
UserNeighborhood neighborhood = new NearestNUserNeighborhood(neighborHoodSize,userSimilarity, dataModel); 
GenericBooleanPrefUserBasedRecommender recommender = new GenericBooleanPrefUserBasedRecommender(dataModel, neighborhood ,userSimilarity); 

有了上面的推薦人，我們得到了一個響應時間，平均爲600ms爲400個社區大小。

我們試圖做它對小於100ms（在線引擎）和我們做了通過使用自定義TopItems.getTopUsers（）和TopItems.getTopItems（）多線程（等於沒有核心）函數實現這一目標。採取的職能平均時間
TopUsers（）：〜30-40毫秒
TopItems（）：〜50-60毫秒

然而，當我們試圖讓許多併發請求（甚至到了25階），響應時間最高可達秒。

我們可以爲每個用戶預先計算鄰居之類的東西，但TopItems（）仍然是併發請求的明確瓶頸。

你會提出任何方式來提高多線程併發請求的響應時間嗎？

回退選項將存儲預先計算的建議在一些NoSql數據庫。 即使對於不那麼活躍的用戶，我們也會定期進行預先計算，這將會非常昂貴。我們可能比不活躍的用戶更頻繁地選擇活躍用戶和預計算建議。

有什麼想法？

Answer 1

是的，多線程不會增加系統的整體吞吐量。這意味着你可以通過帶來更多的線索來更快地回答一個請求。但是，當併發請求的數量等於你的內核數量時，它會返回到你開始的位置，或多或少;實際上線程的開銷可能會讓它變慢。

當然，您總是可以嘗試添加更多機器並維護此服務的N個實例。

這可能與您將要在基於鄰域的模型上做的相同。項目鄰里版本有更多的槓桿拉：您可以控制考慮的項目數的抽樣。這可以幫助。

除此之外，您可能需要查看可以更好地縮放的模型。我個人更喜歡基於矩陣分解的技術。