【轉載】分散式快取能否作為NoSQL資料庫？

對於文件、物件圖、鍵值對這樣的非關係型資料型別，NoSQL資料庫為它們提供了另一種可選的資料儲存方式。分散式快取能被用作NoSQL資料庫嗎？Ehcache的Greg Luck撰文描述了分散式快取與NoSQL資料庫的相似性。InfoQ就此採訪了他，討論了該方案的利弊之處。

InfoQ：你能否就分散式快取解決方案與NoSQL資料庫做個對比？

Greg Luck：分散式快取通常會把資料放在記憶體裡，用於降低延時。NoSQL資料庫是沒有R的DBMS（即沒有關係的資料庫管理系統），一般也缺乏對事務和其他高階特性的支援。對於不支援關係的系統，表關係的關聯是SQL裡最麻煩的部分，這也正是NoSQL這個名字的起源。

其中一種NoSQL資料庫是鍵值儲存。典型的例子包括Dynamo、Oracle NoSQL Database和Redis。快取也是鍵值儲存，因此說這兩者是相關的。很多快取實現能被配置為可持久化的，之所以很多時候不那麼做，是因為快取是要提升效能而不是做持久化。而NoSQL資料庫則與此相反，它是用來做持久化的。

持久化快取也可當作鍵值NoSQL資料庫來使用。NoSQL也提到了，通常是指比能放進一個單獨的RDBMS節點的量要大的資料，一般從幾TB到幾PB。

分散式快取通常用於降低事務性資料的延時，這些資料開始時並不大，但慢慢就會往Big Data這個方向發展。由於快取將資料儲存在記憶體裡，這提高了儲存的成本，而且需要限制資料的大小。如果依賴於堆儲存，每個伺服器節點可能只有可憐的2GB。如果依賴於分散式快取，Ehcache還提供了堆外儲存，每臺伺服器可以儲存幾百GB資料，可以用作TB級別的快取。

持久化、分散式的快取可以適用於一些NoSQL的場景。NoSQL資料庫也可以應對一些快取的場景，只是延時稍高而已。

InfoQ：從架構角度來看，分散式快取和NoSQL資料庫有什麼相似之處嗎？

Greg：它們都想提供優於RDBMS的TPS和可擴充套件性。為此，它們都在功能上做了簡化，拋開了那些麻煩的問題，比如表關聯、儲存過程和ACID事務。

雖然Java快取領域裡有，它為Spring和Java EE程式設計師提供了一套標準的快取API，但是比起標準化介面，它們都更傾向於使用私有介面。

它們都採用對客戶端透明的方式對資料進行分割槽，做向外擴充套件。非Java產品向上擴充套件做得也很好。擁有Terracotta ，我們在Java平臺上的向上擴充套件方面也做得很特別。最後，兩者都可以部署在常見的硬體和作業系統上，這讓它們都能理想地執行於雲端。

InfoQ：架構上這兩項技術又有何不同呢？

Greg：NoSQL和RDBMS通常使用的是磁碟。磁碟是機械裝置，延時很厲害，因為尋道時間是磁頭移動到正確的磁軌的時間，讀寫時間依賴於磁碟的RPM。NoSQL嘗試最佳化磁碟的使用，例如，僅僅在磁頭當前位置追加日誌，偶爾才重新整理到磁碟上。相反，快取主要都把資料放記憶體裡。

NoSQL和RDBMS的客戶端很薄（想想Thrift或JDBC），只是在網路中傳輸資料，而像Ehcache這樣的快取使用程式記憶體儲和遠端儲存，因此常用請求在本地就能被成功處理。在分散式快取上下文中，每個應用程式伺服器的程式記憶體儲中都會快取熱點資料，增加伺服器數量並不會增加網路或後端的負載。

RDBMS專注於成為通用的SOR（System of Record）。NoSQ希望成為某類特定資料型別的SOR，比如鍵值對、文件、稀疏表（寬表）或圖。快取著眼於效能，一般會與RDBMS或NoSQL資料庫結合使用，資料型別就是SOR。往往快取中會儲存Web服務呼叫的結果，業務物件的計算結果，這個結果可能需要成百SOR呼叫才能得到。

像Ehcache這樣的快取部分執行在應用程式的作業系統程式裡，部分執行在網路那頭自己機器的程式裡。但也不是全部分散式快取都這樣：memcache就是一個例子，所有的資料都跨網路儲存。

InfoQ：哪類應用程式最適合這種方式？

Greg：這還得從先前的問題說起，要將分散式快取用於你現有的應用程式，通常只需要很小的工作量，而NoSQL則需要做很多事，還有大的架構變更。

因此適用分散式快取的第一類應用程式是現有系統，特別是有以下需要的：

• 由於使用量或負載激增而需要向外擴充套件
• 為達到SLA而需要有更低的延時
• 為了將大型機這樣的昂貴基礎設施的使用減到最低
• 減少Web服務呼叫而帶來的費用
• 應對極端負載高峰（比如黑色星期五一樣的促銷）

InfoQ：這種方式有什麼侷限麼？

Greg：快取，置於記憶體之中，在大小上有制約，它們的技術侷限受限於有多少記憶體給它們使用（下面還會具體展開說明）。

快取，就算它提供持久化功能，也未必算的上作為SOR的上選。快取故意迴避了備份到磁碟和從中還原的複雜功能，儘管也有簡單的。RDMBS在過去30年裡開發了豐富的備份、還原、遷移、報表和ETL特性。而NoSQL則介於兩者之間。

快取提供了改變資料與訪問資料的程式設計API。NoSQL和RDBMS則提供了工具，可以執行指令碼化語言（比如SQL、UnSQL和Thrift）。

但關鍵一點是要記住快取並不想成為你的SOR。它能輕鬆地與你的RDBMS和睦相處，為此它並不需要RDBMS所有用的複雜功能。

InfoQ：以後分散式快取解決方案、NoSQL資料庫和傳統RDBMS互相協同工作，你有何看法？

Greg：速度大幅快於RDBMS，依賴於部署拓撲的NoSQL，還有資料訪問模式，分散式快取可以位於這三者之間的任意位置。那些需要更低延時的人可以將快取作為NoSQL的一個補充，就像現在對待RDBMS那樣。

稍有不同的是，在你想將RDBMS擴充套件到多個節點時，經常會難於擴充套件，或者影響程式設計契約，或者受制於做出權衡；而使用NoSQL，就算只使用一個節點，你也可以簡單地將其視為多節點安裝。如果是向上擴充套件就沒有這些問題。在RDBMS中，新增快取是為了避免向外擴充套件會遇到的麻煩。通常快取能解決系統的容量問題，你不用費太多力氣。因此當需要向外擴充套件時，加入快取吧。

對於NoSQL而言，內建了向外擴充套件的能力，在需要低延時的時候使用快取吧。

檢視英文原文：