2011-02-07 88 views
0

我正在構建一個數據密集型應用程序(分析),我正在考慮設計緩存機制是否會帶來性能優勢。應用程序執行大量頻繁的寫入/更新。在這種情況下有一個緩存是有道理的,因爲更新更頻繁,查找的?僅當寫入大小較小但頻繁時才用於大容量應用程序中的緩存?一般而言,如果數據很熱(最常訪問),寫入大小是否很好?緩存設計問題

+1

這個問題的答案如此嚴重依賴於你的實現,所以很難回答。數據庫中的數據是什麼?哪一個(SQL/Oracle /等)交易有多大?我認爲在大多數情況下,您會發現主要的RDBMS和分析平臺(OBIEE,Microsoft Dynamics)已經提供了類似於您所描述的優化。 – 2011-02-07 18:32:06

+0

看來你在這裏問了很多不同的問題,所以很難給出一個答案。嘗試改寫你的問題,你會得到更好的迴應。 – 2011-02-07 18:34:26

回答

0

緩存提高了傳輸性能。增加的一部分同樣來自於多次小額轉賬將合併爲一個大塊的可能性。但是主要的性能增益發生是因爲很可能多次讀取同一個數據,或者很快就會讀取寫入的數據。緩存的唯一目的是減少對底層較慢存儲的訪問。因此,您應該非常注意實際緩存的時間和內容。

+0

也許你應該添加一些例子。 – kohlehydrat 2011-02-07 22:11:31

0

它確實取決於很多因素,但總的來說,當讀取次數(對於給定數據)遠遠超過寫入次數時,緩存策略會提供最大的好處。 EHCache documentation對介紹性緩存原則有很好的概述。

1

緩存是讀取密集型應用程序中最常使用的緩存。如果應用程序以任何方式崩潰新的更新/寫入丟失,使用緩存來存儲更新/寫入是有風險的b/c。出於這個原因,緩存需要經常寫入磁盤(取決於寫入/更新的頻率)。

您可以寫入緩存並使異步進程將緩存寫入磁盤並定期刷新緩存(再次取決於寫入/更新的頻率)。如果這是異步的,緩存仍然可以用於讀取/新寫入。

寫入的頻率(而非大小)通常表示高速緩存的熱度。

4

這是我的經驗,「緩存設計」是黑色藝術和硬科學的混合物。雖然硬科學往往是非常可預測的,但這會讓你覺得有一個公式,或者至少是一個好的經驗法則,你可以申請獲得有用的結果。黑色藝術部分意味着這是真實的,但在完全保持真實的同時完全被僞造。

然而,仍然不變的一件事是需要全面的指標。您必須無條件地使用真實世界™數據根據您的應用程序分析大量數據。沒有這個,你只是猜測。數十年的實踐經驗已經一次又一次地表明,如果作爲一名程序員,你正在猜測「性能問題在哪裏」的性質,那麼你百分之百地保證錯誤。因此需要堅實的經驗數據。

如果你決定追求這個目標,那麼在你開始「解決問題之前」,你必須做的第一件事就是找到收集經驗指標的方法。由於您沒有提及您使用的語言或工具,因此我無法提出具體的建議,但幾乎每個工具鏈都有一些專門設計的分析工具,可幫助您瞭解程序花費的時間。

接下來,在這種情況下你的直覺可能是正確的。您已經確定您的訪問模式可能「有偏見」。寫作的一個非常普遍的特徵是「在做任何事情之前他們必須發生」。如果這涉及將數據寫入磁盤,則通常會在等待磁盤I/O操作完成時遇到瓶頸,這通常是真正的性能殺手。在這種情況下,緩存不太可能有所幫助,因爲它不像你可以「緩存寫入」,因爲它必須發生。

有些情況下,「寫入緩存」可以提供幫助。如果您的設計和要求允許內存版本的數據暫時與磁盤版本的數據不一致,則通常可以「寫入組合」。這基本上包括延遲將數據提交到磁盤,這是基於以下事實:對於某些訪問模式,某些非連續寫入將「更新」「刷新到磁盤」窗口中的相同「塊」。

必須要做的另一件事設計一個緩存系統時,需要掌握所有指標,並且理解緩存的工作方式,然後編寫與您的設計選擇最爲正交的性能測試。理想情況下,即使在最壞的情況下,您的緩存系統也不應該明顯降低性能,並且始終存在最糟糕的情況。

編輯

重新閱讀您的問題後,目前還不清楚這是否是你現在正在經歷,你認爲你「可能」遇到性能問題,或一個。如果是後者,請在我的回答中重新閱讀至少三次。該只有時候你應該考慮建立一個緩存系統是當你已經確定,與堅硬的經驗數據,你有一個性能問題。