2009-05-26 109 views
2

我目前正在考慮緩存策略,更重要的是避免緩存內的任何數據重複。我的查詢是一種語言不可知的,但非常多的編程相關。使用分頁/過濾數據的緩存策略

我的問題是關於高效緩存分頁或過濾數據,但更多的是分佈式緩存。後者我決定使用memcached,更具體地說是使用它的.NET端口。我已經看到了NCache的另一個商業選擇,但memcached似乎完全可以接受我,顯然是用在臉書,myspace等...

我的查詢然後是一個策略我可以包含對象緩存和也是對分頁數據的引用。如果我有100個項目並對其進行分頁,則可以將產品1-10的ID保存在緩存中,並分別緩存每個產品。如果我在哪裏對項目進行降序排序,那麼項目1-10將是不同的產品,所以我不希望在每次更改分頁數據/排序/過濾時存儲實際對象,而是存儲對象的ID,以便我可以在數據庫中執行查找操作,如果它們中的一些尚未存在於緩存中或無效。

我最初的想法是這個緩存鍵。

paged_<pageNumber><pageSize><sort><sortDirection>[<filter>] 

然後我將通過緩存鍵進行迭代,並以「paged_」刪除其中任何一個開始我的問題最終是如果關於有關數據的這種模式的緩存straties如分頁數據的任何模式或理念的任何人知道並確保對象不會多次緩存。

memcached是本地代碼,不會有問題以我上面所述的方式清除緩存,但顯然這是一個顯而易見的事實,緩存中的項越多,需要的時間就越多。我很感興趣,如果有人知道任何解決方案或理論,目前正在使用這種類型的問題。我相信會有。感謝您的時間

TIA

安德魯

+0

頁面是動態的,每個頁面上的數據是不斷變化的還是基於用戶查詢?應用程序是否已經寫入並且速度太慢,因此需要使用緩存? 「不成熟的優化是萬惡的根源」 – Gandalf 2009-05-26 19:44:04

回答

0

我曾經嘗試,我認爲,是一個類似的緩存策略,並發現它笨拙。我最終只是緩存組成頁面的對象併爲每個請求生成頁面。構建一個頁面的10次緩存命中將會(希望)成爲第二個響應時間,對於您的服務用戶而言幾乎是瞬間的。

如果您必須緩存整個頁面(我認爲它們是結果集),那麼也許您可以通過散列運行用戶請求並將其用作緩存鍵。用一個具體的例子或代碼(至少對我來說)來形象化是一個很難的問題。