「高速緩存」過程的強大計算替代方案

背景：我已經在Spring中進行了一些關於緩存的研究，它似乎是節省常見讀取操作時間的好方法。我的代碼目前有大量項目的循環，我正在執行邏輯以查看某些其他對象是否通過公共項目連接。思考這個問題的方法與購物網站在查看特定商品時顯示的相關商品類似。我用來確定這個值很複雜，但這是基本的想法。「高速緩存」過程的強大計算替代方案

在加載項目頁面時，會有很長的加載時間來嘗試計算並找出哪些其他項目以某種方式關聯以顯示指向它們的鏈接。與其每次加載項目頁面時計算此列表，我都已開始「緩存」帶有其推薦項目列表的項目。系統中的很多事情可以觸發一個需要重新計算這些關係：添加/刪除屬性項目，添加/刪除項目等

問題：我的「緩存」僅僅是包含項目地圖的單一對象和他們的相關對象。當需要對緩存進行任何更改時，遍歷系統中每個項目的過程非常耗時並且過程密集。由於對項目的不斷更改，Java緩存似乎不是正確的答案。有沒有其他設計模式可以讓我忽略這個設計？緩存看起來很接近，但我不確定這個問題是否適合緩存的模型，因爲它比單個項目的大量讀取複雜一點。

緩存是否與此一致？如果緩存不是正確的解決方案，那是什麼？

來源

2017-02-14 Walls

我可能是錯的，但這更像是一個問題，你應該找到最有效的方法來*模型*你的對象使用*數據結構*最適合這些問題。 Cache是最終引用的地方，但保存數據的結構需要適當考慮。 – CKing

我同意@CKing那裏。你似乎有一個問題，因爲你只有一個物理實體（'Item'），並且你有一個邏輯實體'ItemRelation'（帶有類型屬性和其他任何內容）。由於「ItemRelation」數據中存在如此大的需求，爲什麼不將關係實現爲物理實體以存儲在物品所存儲的相似媒體中？通過這種方式，只有在發生某些更改時才能通過計算關係來節省麻煩，而其餘時間您只需閱讀關係數據存儲中可用的內容即可。 –

@CKing @ m-prokhorov我會盡量保持它的通用性：'Item'有一個'Set '。 'Property'跟蹤或多或少的一個鍵/值對，可以像'Color：Blue'這樣的線來考慮，其中'Color'是'Attribute'，'Blue'是'Value'。「Attribute」和「Value」自身存在（複雜的數據庫是複雜的），因此所有內容都鏈接在一起。我只是在東西發生變化時更新這個「緩存」，但問題是它仍然循環遍歷系統中的每個「Item」以重新檢查其「Property」以查看新變更是否影響「緩存」（添加/刪除/不管）。 'Property'持有'Item'等的句柄。 – Walls

緩存似乎並不是解決您的問題的方法，但它們可能會幫助您達成解決方案。

例如，不是緩存創建的項目，另一種方法是緩存很少更改但對創建列表至關重要的信息。

基於Spring函數的緩存（即@Cachable）可能派上用場，無論是緩存還是失效。

下一級是檢查不同類型的緩存（即redis）以及它們在算法，排序和Pub/Sub方面提供的功能。

來源

2017-02-14 15:14:47 gkatzioura

「高速緩存」過程的強大計算替代方案

回答

相關問題