Redis VS Memcached 轉載

標籤：http   io   ar   os   使用   sp   strong   on   資料   

引子：

    在大資料時代，總希望存在一個Key-value儲存機制，像HashMap一樣在記憶體中處理大量（千萬數量級）的key-value對，以便提高資料尋找、修改速度。

    所以，我們會想到，Memcached和Redis這兩個NoSQL資料庫（嚴格來講二者都不可以算作資料庫）。

    1、Memcached是一個cache機制，當記憶體不足時會採用LRU機制，替換出陳舊資料，因此他不能保證我們的資料像在HashMap中一樣不丟失，且沒有資料持久化機制；

    2、Redis克服了這一缺點，採取磁碟儲存機制實現資料持久化。但是，當資料量達到1千萬左右時，由於記憶體中不能儲存如此大量數目的資料，頻繁同磁碟進行資料交換，導致資料查詢、儲存效能的急劇下降，將導致服務不可用。

     結論：當前還沒有好的產品可以實現key-value保證資料完整性，千萬級條數量級的，高效儲存和查詢支援產品。

     附錄一：如下是轉自其它網友的測試資料：

     附錄二：memcached 和redis的比較，和各自用途

附錄一：

可以猜測到還會有Redis 2.2.1 的測試，相同的測試環境，1K的資料量，使用ServiceStack.Redis用戶端進行如下測試：

　　1) Set操作

　　2) Get操作

　　3) Del操作

　　每一套測試分別使用三個配置進行測試：

　　1) 綠色線條的是開啟Dump方式的持久化，5分鐘持久化一次

　　2) 藍色線條是開啟AOF方式的持久化，每秒寫入磁碟一次

　　3) 紅色線條是關閉任何的持久化方式

　　對於每一個配置都使用相同的其他配置：

　　1) 開啟VM 最大記憶體10GB(128位元組一頁)之後開始換出，VM空間160GB

　　2) 最大使用記憶體15GB，確保在Dump的時候有足夠的剩餘記憶體

　　3) 開啟壓縮，沒有配置主從

　　現在來看一下測試結果：

　　

 

　　從這個圖中可以看出：

　　1) 對於沒有持久化的方式，讀寫都在資料量達到800萬的時候，效能下降幾倍，此時正好是達到記憶體10G，Redis開始換出到磁碟的時候。並且從那以後再也沒辦法重新振作起來，效能比Mongodb還要差很多。

　　2) 對於AOF持久化的方式，總體效能並不會比不帶持久化方式差太多，都是在到了千萬資料量，記憶體佔滿之後讀的效能只有幾百。

　　3) 對於Dump持久化方式，讀寫效能波動都比較大，可能在那段時候正在Dump也有關係，並且在達到了1400萬資料量之後，讀寫效能貼底了。在Dump的時候，不會進行換出，而且所有修改的資料還是建立的新頁，記憶體佔用比平時高不少，超過了15GB。而且Dump還會壓縮，佔用了大量的CPU。也就是說，在那個時候記憶體、磁碟和CPU的壓力都接近極限，效能不差才怪。

　　總結一下：

　　1) Redis其實只適合作為緩衝，而不是資料庫或是儲存。它的持久化方式適用於救救急啥的，不太適合當作一個普通功能來用。對於這個版本的Redis，不建議使用任何的持久化方式。否則到時候可能會死的比較難看。說白了，期望Redis是memcached的升級版，帶有各種資料結構，但是不要期望Redis來和Mongodb/Kt等來比。

　　2) 對於VM其實也是不建議開啟，雖然開啟VM可以讓Redis儲存比記憶體更多的資料，但是如果冷熱資料不是很明顯的話效能會非常差(我的測試都是隨機查詢Key，冷熱不明顯)。當然，對於冷熱明顯的情況下可以設定200% - 400%的記憶體作為VM空間，也不建議設定10倍的記憶體空間作為VM(像我的配置一樣)。

　　3) ServiceStack.Redis用戶端好像有幾個Bug，首先RedisTypedClient的Dispose居然沒有實現，應該是要調用client.Dispose()，其次RedisNativeClient的Info屬性不是每次都擷取最新值的，第三PooledRedisClientManager的WritePoolIndex和ReadPoolIndex只看到加沒看到減的地方，也不知道這是幹啥的，其實每次都取第一個不是Active的Client就可以了，PooledRedisClientManager也沒有把逾時使用的Active的Client強制回收(避免使用的時候忘記Dispose佔用過多的串連)。有關這幾點，我會嘗試聯絡ServiceStack.Redis的作者。

 

附錄二：

這兩年Redis火得可以，Redis也常常被當作Memcached的挑戰者被提到案頭上來。關於Redis與Memcached的比較更是比比皆是。然而，Redis真的在功能、效能以及記憶體使用量效率上都超越了Memcached嗎？ 

下面的內容是來自Redis作者在stackoverflow上的一個回答，對應的問題是《Is memcached a dinosaur in comparison to Redis?》（相比Redis，Memcached真的過時了嗎？） 

• 沒有必要過於關注效能，因為二者的效能都已經足夠高了。由於Redis只使用單核，而Memcached可以使用多核，所以二者比較起來，平均每一個核上，Redis在儲存小資料時比Memcached效能更高。而在100k以上的資料中，Memcached效能要高於Redis。雖然Redis最近也在儲存大資料的效能上進行最佳化，但是比起Memcached，還是稍有遜色。說了這麼多，結論是，無論你使用哪一個，每秒處理請求的次數都不會成為瓶頸。
• 在記憶體使用量效率上，如果使用簡單的key-value儲存，Memcached的記憶體利用率更高。而如果Redis採用hash結構來做key-value儲存，由於其組合式的壓縮，其記憶體利用率會高於Memcached。當然，這和你的應用情境和資料特性有關。
• 如果你對資料持久化和資料同步有所要求，那麼推薦你選擇Redis。因為這兩個特性Memcached都不具備。即使你只是希望在升級或者重啟系統後快取資料不會丟失，選擇Redis也是明智的。
• 當然，最後還得說到你的具體應用需求。Redis相比Memcached來說，擁有更多的資料結構，並支援更豐富的資料操作。通常在Memcached裡，你需要將資料拿到用戶端來進行類似的修改再set回去。這大大增加了網路IO的次數和資料體積。在Redis中，這些複雜的操作通常和一般的GET/SET一樣高效。所以，如果你需要緩衝能夠支援更複雜的結構和操作，那麼Redis會是不錯的選擇。

Redis VS Memcached 轉載