理性選擇key-value Store

開源産品固然好，但是各種場景的資料需求确實多少有些差距，利用現有的軟硬體資源面對現有的問題快速做出調整是才是資料庫工程師的真正價值。

<a target="_blank"></a>

key-value store由于本身實作不像成熟rdbms那麼複雜，換句話說開發周期不常，性能更是由于去掉了acid的限制，從一個個benchmark上看對比起主流開源關系型資料庫mysql innodb的曲線都非常好看，op/s号稱高一個數量級的不是沒有，request latency更是有redis類似的記憶體性資料庫，在高并發的場景下99.95%響應在1ms以下一點也不驚奇。其實對于了解oltp資料系統的同學來說，這其實一點也不神奇。

使用key value store的需求:

提高db端的響應延遲。因為我本身也有計算、多個api調用送出（整體響應時間以最慢api時間為準:-) ）、網絡等開銷（這個尤其适用于有專有技術平台的公司場景），因為及時我有其他複雜邏輯托我後腿了，我也不想因db的響應延遲拖後腿，因為這個我們不可控。

memcache隻是緩存

典型的應用場景：

function query_memcache($sql,$type=”){ $key = md5($key); if(!($value = $_sglobal['memcache']-&gt;get($key))){ //cache中沒有,則從my sql中查詢 $query = $this-&gt;query($key,$type); while($item = $this-&gt;fetch_array($query)){ $result[] = $item; } $value = $result; //将key和value寫入memcache $_sglobal['memcache']-&gt;set($key,$result,0,$memcache_lifetime); return $value;

先去mc查詢，沒有就查db，查上來順手種下mc

但是memcache隻能作為緩存，緩存顧名思義，需要預熱、程式邏輯種植，不能持久化存儲。

系統因為各種原因的mc穿透導緻db無響應導緻百頁的情況，應該最為常見。

如果可能請不要sharding    了解類mysql db的同學知道，replication很可能成為db資源瓶頸，是以我們業務在評估資源的時候發現要面對一堆資料庫配置和五花八門的hash函數，是以我們感歎：你們後端的同學能不能給點力，不讓我開發周期一拖再拖。更不能接受的就是因為db要resharding，我們還要花大量時間改造代碼。

多數nosql産品對開發友好    面向文檔的（mongodb），直接存儲json（couchbase），多種記憶體結構hashset,list…(redis) …等等

嘗試下新技術    nosql聽上去很霸氣

tco的降低    能替代mc+mysql,按照kv的性能測試來看，确實能節省整體tco

減少部分運維工作    能省去了部分因為性能不足導緻的擴容

安全性及可用性    kvdb的大多數都是支援持久化資料的。可用性就是指同步資料的方式，最常見就是replication。效率和可靠性都是需要考量的。

我要嘗試下新技術    nosql聽上去很霸氣

總結：

可見開發和運維人員對與資料庫系統是不一樣的，短期和中長期的效益都很重要。

表一 主流nosql簡單對比

cassandra

mongodb

couchdb

redis

riak

hbase

開發語言

java

c++

erlang

c / c++

erlang/ c / javascript

特點

分布式與複制的權衡

根據列和鍵範圍進行查詢

bigtable類似的功能：列，列族

寫比讀快很多

主從複制

查詢利用javascript表達式

比couchdb更容易就地更新

内置sharding

資料存儲使用的是記憶體映射檔案

資料庫崩潰後需要對表進行修複

持久性更好

雙向複制

主主複制(master-master replication)

沖突檢測

多版本并發控制，寫操作不會阻塞讀取

通用的技術文檔

隻崩潰設計crash-only

需要經常壓縮

視圖：嵌入式map/reduce

格式化視圖：lists &amp; shows

伺服器端文檔驗證可行

身份驗證可行

通過_changes實時更新

附件處理

記憶體資料庫

簡單的key-value

操作符較為複雜，如

zrevrangebys

core incr &amp; co

(有利于速率限制和統計)

有集合

(union/diff/inter)

有清單

(a queue; blocking pop)

有散列(多字段對象)

nosql中唯一處理交易的資料庫

分布式與複制的權衡post-commit 和pre-commit hooks

安全性驗證

内置的全文檢索

javascript或

erlang map/reduce

模仿bigtable

map/reduce hadoop

利用伺服器端掃描進行查詢預測疊加并擷取過濾

優化的實時查詢

高性能thrift網關

http支援xml、protobuf和二進制

cascading、hive、

pig source和sink子產品

基于jruby的shell

無單點故障

類似mysql的随機通路性能

證書

apache

bsd

協定

自定義/thrift

自定義/bson

http/rest

telnet-like

http/rest/thrift

最佳适用

基于java，寫操作較多，讀少

動态的查詢，定義索引而非map/reduce。資料變化快，磁盤不夠用，可以使用mongodb

有大量資料，但更新不大，需要預先定義查詢

資料快速變化，資料庫大小可以預見（适合記憶體存取資料）

簡單的類似cassandra

或dynamo的功能，較強的單點容錯性和擴充性

随機資料、實時讀取海量資料

應用場景

銀行，金融行業。資料分析

mysql或

postgresql

的替代品

crm、cms系統

股價系統，資料分析，實時資料采集以及實時通信場景

銷售點資料采集。工廠控制系統。需要零停機時間的場景

喜歡bigtable，需要随即、實時的讀寫大資料(big data)

當然這個對比有很多問題，很多産品是解決不是同一個問題，故不應該列在裡面，更奇怪的是沒有把mysql列入裡面,mysql(注意這裡不是指handlersocket plugin)能做很多nosql做不了的事情，用作nosql db同樣的功能更為容易，為什麼不拿出來對比下。

之前圍繞着mysql,redis,leveldb,hbase做過一些不同目的的性能測試，也算對這些産品的性能有了大概了解，未來需要對性能資料完善一下！

mysql 記憶體通路性能測試

 原文釋出時間為：2013-10-11

本文來自雲栖社群合作夥伴“linux中國”