distributed key-value store是當下比較流行的話題，尤其在構建諸如搜索引擎、IM、P2P、遊戲服務器、SNS等大型互聯網應用以及提供雲計算服務的時候，怎樣保證系統在 海量數據環境下的高性能、高可靠性、高擴展性、高可用性、低成本成爲所有系統架構們挖苦心思考慮的重點，而怎樣解決數據庫服務器的性能瓶頸是最大的挑戰。
按照分佈式領域的CAP理論 （Consistency、 Availability、Tolerance to network Partitions這三部分在任何系統架構實現時只可能同時滿足其中二點，沒法三者兼顧）來衡量，傳統的關係數據庫的ACID只滿足了 Consistency、Availability，因此在Partition tolerance上就很難做得好。另外傳統的關係數據庫處理海量數據、分佈式架構時候在Performance、Scalability、 Availability等方面也存在很大的侷限性。
而key-value store更加註重對海量數據存取的性能、分佈式、擴展性支持上，並不需要傳統關係數據庫的一些特徵，例如：Schema、事務、完整SQL查詢支持等 等，因此在分佈式環境下的性能相對於傳統的關係數據庫有較大的提升。當然不同的key-value store根據應用需求的不同，在設計理念並不完全相同，例如以Google BigTable 、Amazon Dynamo 爲例：
BigTable is a CA system; it is strongly consistent and highly available, but can be unavailable under network partitions. BigTable has no replication at the database level, rather replication is handled underneath by GFS.
Dynamo is an AP system; it is highly available, even under network partitions, but eventually consistent. Data is replicated within a single cluster, so even under partitions most data is available, however one node’s latest version might not match that of another, so every reader is only guaranteed to see every write eventually.
其實使用key-value store的歷史已經很久了，以前在做電信計費時候的Radius服務器就採用Berkeley DB這樣經典的key-value store作爲用戶數據庫，只不過早期使用這樣的key-value store關注的重點主要在性能上，對於分佈式、海量數據的處理並非考慮的重點。
1、key-value store與RDBMS的區別
摘自:Is the Relational Database Doomed?
2、一些常用的key-value的開源項目
這些項目的設計思路大多是參考Google BigTable 、Amazon Dynamo
除了以上羅列的產品外，還有如下一些產品
Flare
其中Tokyo cabinet 、Redis 、MongoDB 各有特色，可以作爲項目使用key-value store時候的重點評估對象。
3、與工作相關的一些可以使用key-value store的應用場合
Cache：Memcachedb、Tokyo Tyrant
網絡通信：做IM、P2P時候做單點登錄服務器、狀態服務器；消息隊列服務器（Tokyo Tyrant）
交易系統：計費系統cdr及預處理後的賬單數據；交易系統風控系統（內存數據庫,redis）
日誌：服務器訪問日誌，用於web analytics使用；呼叫中心的呼叫數據；
爬蟲及搜索引擎：爬取頁面日誌；爬取任務；索引庫
SNS社區及CMS站點：可以大規模應用Tokyo Cabinet+Tokyo Tyrant，結合Solr/Lucene或這樣的Sphinx搜索引擎搞定查詢問題
雲存儲：
4、參考資料
Towards Robust Distributed Systems
