如果數據庫已經提供緩存，爲什麼要使用應用程序級緩存？

Question

現代數據庫提供緩存支持。大多數ORM框架也緩存檢索到的數據。爲什麼這種重複是必要的？

Answer 1

因爲要得到數據庫的緩存中的數據，你還是得：

1. 生成的ORM的「原生」的查詢格式
2. 的SQL做一個網絡往返到數據庫服務器
3. 解析SQL
4. 從緩存中的數據提取數據
5. 連載至數據庫的網上格式
6. 將數據反序列化爲數據庫客戶端庫的格式
7. 將數據庫客戶端庫管理程序的格式轉換爲語言級對象（即一個發現者的集合）

通過緩存在應用程序級別，你不必做任何。通常，這是對內存哈希表的簡單查詢。有時（如果使用memcache進行緩存）仍然有網絡往返，但其他所有內容不再發生。

Answer 2

這裏有幾個原因，你可能希望這樣的：

• 的應用程序緩存只是它所需要的，所以你應該得到更好的緩存命中率
• 訪問本地緩存可能會是一對夫婦數量級比訪問數據庫由於網絡延遲快 - 即使有快速的網絡

Answer 3

即使數據庫引擎緩存數據，索引或查詢結果集，它仍然需要往返數據庫以使應用程序從該緩存中受益。

ORM框架與您的應用程序在相同的空間中運行。所以沒有往返。這只是一個內存訪問，通常要快得多。

該框架還可以決定保持緩存中的數據，只要它需要它。當其他併發客戶端發出利用緩存的請求時，數據庫可能會決定在不可預知的時間使緩存的數據過期。

您的應用程序端ORM框架還可能以數據庫無法返回的形式緩存數據。例如。採用java對象而不是原始數據流的集合形式。如果您依賴數據庫緩存，則您的ORM必須將該轉換重複到對象中，這會增加開銷並降低緩存的優勢。

Answer 4

此外，數據庫的緩存可能不像人們想象的那樣實用。我從http://highscalability.com/bunch-great-strategies-using-memcached-and-mysql-better-together複製 - 這是MySQL特定的，tho。

鑑於MySQL有緩存，爲什麼需要memcached呢？

MySQL緩存僅與一個實例關聯。這將緩存限制爲一臺服務器的最大地址。如果你的系統比一臺服務器的內存大，那麼使用MySQL緩存將不起作用。如果同一個對象從另一個實例中讀取，它不會被緩存。

查詢緩存在寫入時失效。你建立了所有的緩存，當有人寫入時緩存就會消失。取決於使用模式，您的緩存可能根本不是緩存。

查詢緩存是基於行的。 Memcached可以緩存您想要的任何類型的數據，並且不限於緩存數據庫行。 Memcached可以緩存複雜的對象，無需連接即可直接使用。

Answer 5

相關的網絡往返的性能方面的考慮已經正確指出了。

爲此，必須補充說，在dbms（而不是「數據庫」）以外的任何地方緩存數據會產生一個潛在過時數據的問題，這些數據仍然呈現爲「最新」。

讓步，以性能提高的誘惑去在失去絕對可靠，guaranteeably正確的，一致的數據保證（水密或至少接近）的費用。

每次都要考慮到準確性和一致性至關重要。

Answer 6

毫無疑問，現代數據庫提供緩存工具，但是當你有你的網站更多的流量和那個時候你需要執行很多數據庫事務，那麼你就不會得到高performance.So增加在這種情況下Hibernate的緩存性能將通過優化數據庫應用程序幫助你， 。緩存實際上存儲了已經從數據庫加載的數據，這樣當應用程序想要再次訪問數據時，應用程序和數據庫之間的流量將會減少。訪問時間和流量將在應用程序和數據庫之間減少。

Answer 7

這裏有很多很好的答案。我會補充一點：我的知道我的訪問模式，數據庫沒有。

根據我在做什麼，我知道如果數據結束了陳舊，這不是一個真正的問題。數據庫不會，也不得不用新數據重新加載緩存。

我知道我會幾次回來一塊數據在接下來的一段時間，所以保持周圍是很重要的。數據庫必須猜測要保存在緩存中的內容，它沒有我所做的信息。因此，如果我一遍又一遍地從數據庫中讀取數據，那麼如果服務器很忙，它可能不在緩存中。我可能會遇到緩存未命中。有了我的緩存，我可以確定我受到了打擊。對於非平凡的數據（例如一些連接，一些組函數）而非僅僅一行來說，情況尤其如此。獲得7的主鍵對於數據庫來說很容易，但是如果它必須做一些真正的工作，緩存缺失的成本要高得多。

Answer 8

這就是說 - 緩存有時會成爲一種負擔，實際上會減慢服務器的速度。當你的負載很高時，緩存的內容和不匹配的算法可能不適合請求進入......你得到的是一個緩存，在超時時間開始像FIFO一樣運行......這開始使自己知道當坐在後面緩存表有顯著更多的記錄比是以往任何時候都在內存中緩存...

一個很好的權衡將是集羣的數據要緩存的內容。有一臺主服務器將更新信息傳輸到羣集，根據TTL（生存時間）設置，每個表的時間可以根據每個表進行量身定製。

您的用戶節點上的邏輯和數據可以位於內存數據庫中打開的同一臺服務器上，或者如果必須提取數據，則可以將其設置爲使用管道而不是網絡調用。 。

這是一件發生在你想如何使用數據的一些思想和當/如果你再聚集你必須要知道分佈式事務的（超過一個數據庫事務）......但如果數據被高速緩存將自行更新，無需鏈接到其他數據庫空間，那麼你可以擺脫這個......

ORM緩存的問題是，如果數據庫通過另一個應用程序獨立更新那麼ORM緩存可以成爲過時的......此外，它可以變得很棘手，如果你做一個更新的一組...更新可能更新的東西，是在你的緩存，它需要有某種算法來識別哪些記錄需要在內存中刪除/更新（減慢更新！？） - 然後這個算法變得難以置信的棘手和容易出錯！

如果使用ORM緩存則保持於一個簡單的規則...緩存簡單的對象幾乎沒有發生變化（例如用戶/角色的詳細信息），並且尺寸小，並在請求被擊中許多次......如果除此之外，我建議將性能數據集中起來。