在過去的幾年中，NoSQL數據庫一度成爲高併發、海量數據存儲解決方案的代名詞，與之相應的產品也呈現出雨後春筍般的生機。然而在衆多產品中能夠脫穎而出的卻屈指可數，如Redis、MongoDB、BerkeleyDB和CouchDB等。由於每種產品所擁有的特徵不同，因此它們的應用場景也存在着一定的差異，下面僅給出簡單的說明：
1). BerkeleyDB是一種極爲流行的開源嵌入式數據庫，在更多情況下可用於存儲引擎，比如BerkeleyDB在被Oracle收購之前曾作爲MySQL的存儲引擎，由此可以預見，該產品擁有極好的併發伸縮性，支持事務及嵌套事務，海量數據存儲等重要特徵，在用於存儲實時數據方面具有極高的可用價值。然而需要指出的是，該產品的Licence爲GPL，這就意味着它並不是在所有情況下都是免費使用的。
2). 對MongoDB的定義爲Oriented-Document數據庫服務器，和BerkeleyDB不同的是該數據庫可以像其他關係型數據庫服務器那樣獨立的運行並提供相關的數據服務。從該產品的官方文檔中我們可以獲悉，MongoDB主要適用於高併發的論壇或博客網站，這些網站具有的主要特徵是併發訪問量高、多讀少寫、數據量大、邏輯關係簡單，以及文檔數據作爲主要數據源等。和BerkeleyDB一樣，該產品的License同爲GPL。
3). Redis，典型的NoSQL數據庫服務器，和BerkeleyDB相比，它可以作爲服務程序獨立運行於自己的服務器主機。在很多時候，人們只是將Redis視爲Key/Value數據庫服務器，然而事實並非如此，在目前的版本中，Redis除了Key/Value之外還支持List、Hash、Set和Ordered Set等數據結構，因此它的用途也更爲寬泛。對於此種誤解，Redis官網也進行了相應的澄清。和以上兩種產品不同的是，Redis的License是Apache License，就目前而言，它是完全免費。
4). memcached，數據緩存服務器。爲什麼在這裏要給出該產品的解釋呢？很簡單，因爲筆者認爲它在使用方式上和Redis最爲相似。畢竟這是一篇關於Redis的技術系列博客，有鑑於此，我們將簡要的對比一下這兩個產品。首先說一下它們之間的最大區別，memcached只是提供了數據緩存服務，一旦服務器宕機，之前在內存中緩存的數據也將全部消失，因此可以看出memcached沒有提供任何形式的數據持久化功能，而Redis則提供了這樣的功能。再有就是Redis提供了更爲豐富的數據存儲結構，如Hash和Set。至於它們的相同點，主要有兩個，一是完全免費，再有就是它們的提供的命令形式極爲接近。
二、Redis的優勢：
1). 和其他NoSQL產品相比，Redis的易用性極高，因此對於那些有類似產品使用經驗的開發者來說，一兩天，甚至是幾個小時之後就可以利用Redis來搭建自己的平臺了。
2). 在解決了很多通用性問題的同時，也爲一些個性化問題提供了相關的解決方案，如索引引擎、統計排名、消息隊列服務等。
三、目前版本中Redis存在的主要問題：
1). 在官方版本中沒有提供Windows平臺的支持，已發佈的正式版本中只是支持類Unix和MacOSX平臺。
2). 沒有提供集羣的支持，然而據官網所述，預計在2.6版本中會加入該特徵。
3). Publication/Subscription功能中，如果master宕機，slave無法自動提升爲master。
四、和關係型數據庫的比較：
在目前版本(2.4.7)的Redis中，提供了對五種不同數據類型的支持，其中只有一種類型，既string類型可以被視爲Key-Value結構，而其他的數據類型均有適用於各自特徵的應用場景，至於具體細節我們將會在該系列後面的博客中予以說明。
相比於關係型數據庫，由於其存儲結構相對簡單，因此Redis並不能對複雜的邏輯關係提供很好的支持，然而在適用於Redis的場景中，我們卻可以由此而獲得效率上的顯著提升。即便如此，Redis還是爲我們提供了一些數據庫應該具有的基礎概念，如：在同一連接中可以選擇打開不同的數據庫，然而不同的是，Redis中的數據庫是通過數字來進行命名的，缺省情況下打開的數據庫爲0。如果程序在運行過程中打算切換數據庫，可以使用Redis的select命令來打開其他數據庫，如select 1，如果此後還想再切換回缺省數據庫，只需執行select 0即可。
在數據存儲方面，Redis遵循了現有NoSQL數據庫的主流思想，即Key作爲數據檢索的唯一標識，我們可以將其簡單的理解爲關係型數據庫中索引的鍵，而Value則作爲數據存儲的主要對象，其中每一個Value都有一個Key與之關聯，這就好比索引中物理數據在數據表中存儲的位置。在Redis中，Value將被視爲二進制字節流用於存儲任何格式的數據，如Json、XML和序列化對象的字節流等，因此我們也可以將其想象爲RDB中的BLOB類型字段。由此可見，在進行數據查詢時，我們只能基於Key作爲我們查詢的條件，當然我們也可以應用Redis中提供的一些技巧將Value作爲其他數據的Key，這些知識我們都會在後面的博客中予以介紹。
五、如何持久化內存數據：
缺省情況下，Redis會參照當前數據庫中數據被修改的數量，在達到一定的閾值後會將數據庫的快照存儲到磁盤上，這一點我們可以通過配置文件來設定該閾值。通常情況下，我們也可以將Redis設定爲定時保存。如當有1000個以上的鍵數據被修改時，Redis將每隔60秒進行一次數據持久化操作。缺省設置爲，如果有9個或9個以下數據修改是，Redis將每15分鐘持久化一次。
從上面提到的方案中可以看出，如果採用該方式，Redis的運行時效率將會是非常高效的，既每當有新的數據修改發生時，僅僅是內存中的緩存數據發生改變，而這樣的改變並不會被立即持久化到磁盤上，從而在絕大多數的修改操作中避免了磁盤IO的發生。然而事情往往是存在其兩面性的，在該方法中我們確實得到了效率上的提升，但是卻失去了數據可靠性。如果在內存快照被持久化到磁盤之前，Redis所在的服務器出現宕機，那麼這些未寫入到磁盤的已修改數據都將丟失。爲了保證數據的高可靠性，Redis還提供了另外一種數據持久化機制--Append模式。如果Redis服務器被配置爲該方式，那麼每當有數據修改發生時，都會被立即持久化到磁盤。