理性选择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中国”