理性选择key-value Store

前言

开源产品固然好，但是各种场景的数据需求确实多少有些差距，利用现有的软硬件资源面对现有的问题快速做出调整是才是数据库工程师的真正价值。

综述

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']->get($key))){ //Cache中没有,则从My SQL中查询

$query = $this->query($key,$type);

while($item = $this->fetch_array($query)){

$result[] = $item;

}

$value = $result;

//将Key和Value写入MemCache

$_SGLOBAL['memcache']->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听上去很霸气

总结：
可见开发和运维人员对与数据库系统是不一样的，短期和中长期的效益都很重要。

选择

KVDB产品非常多，很难对他们所有都很了解，故这里引用篇对比： http://asyty.iteye.com/blog/1202106

表一 主流NOSQL简单对比

参考：http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis


Cassandra
Mongodb
CouchDB
Redis
Riak
HBase

开发语言
J***A
C++
Erlang
C / C++
Erlang/ C / J***ASCRIPT
J***A

特点

分布式与复制的权衡

根据列和键范围进行查询

BigTable类似的功能：列，列族

写比读快很多

主从复制

查询利用javascript表达式

比CouchDB更容易就地升级

内置Sharding

数据存储使用的是内存映射文件

数据库崩溃后需要对表进行修复

持久性更好

双向复制

主主复制(master-master replication)

冲突检测

多版本并发控制，写操作不会阻塞读取

通用的技术文档

只崩溃设计Crash-only

需要经常压缩

视图：嵌入式map/reduce

格式化视图：lists & shows

服务器端文档验证可行

身份验证可行

通过_changes实时更新

附件处理

内存数据库

主从复制

简单的Key-Value

操作符较为复杂，如

ZREVRANGEBYS

CORE INCR & 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
Apache
Apache
BSD
Apache
Apache

协议
自定义/Thrift
自定义/BSON
HTTP/REST
Telnet-Like
HTTP/REST

HTTP/REST/Thrift

最佳适用
基于J***A，写操作较多，读少
动态的查询，定义索引而非map/reduce。数据变化快，磁盘不够用，可以使用MongoDB
有大量数据，但更新不大，需要预先定义查询
数据快速变化，数据库大小可以预见（适合内存存取数据）

简单的类似Cassandra

或Dynamo的功能，较强的单点容错性和扩展性

随机数据、实时读取海量数据

应用场景
银行，金融行业。数据分析

MySQL或

PostgreSQL

的替代品

CRM、CMS系统
股价系统，数据分析，实时数据采集以及实时通信场景
销售点数据采集。工厂控制系统。需要零停机时间的场景

喜欢bigTable，需要随即、实时的读写大数据(Big Data)

当然这个对比有很多问题，很多产品是解决不是同一个问题，故不应该列在里面，更奇怪的是没有把mysql列入里面,mysql(注意这里不是指handlersocket plugin)能做很多nosql做不了的事情，用作nosql DB同样的功能更为容易，为什么不拿出来对比下。

测试

之前围绕着Mysql,Redis,LevelDB,Hbase做过一些不同目的的性能测试，也算对这些产品的性能有了大概了解，未来需要对性能数据完善一下！

Mysql 内存访问性能测试







Redis 相应延迟及性能测试




Hbase put稳定性测试





LevelDB SSD性能测试 2000W行数据

总结

select * frrom id=? k-v场景在高性能设备上Mysql绝对超出了你的预期。
Hbase是重量级的KV应用，真正意义上的分布式，性能不减，compaction/split等特性需要深入掌控。
Redis性能最好，支持服务种类较多，成本较高，数据持久化方式太让人崩溃，HA及扩容方案有待完善。
LevelDB可以利用高性能SSD设备，成功应用经验较少，HA及扩容方案未验证。
其他数据库没有入手测试经验，性能问题姑且不谈。
当然这里需要注意的问题是实例承受能力和Cluster的承受能力，如Mysql M-S结构中 Replication成为瓶颈的情况十分常见，如果应用场景无法忍受从库延时，那么实际你的性能指标也会下降很多。
另外性能指标只是系统运维关系的一部分可用性指标，可维护性指标也是非常重要的，这是现在很多kv store欠缺的。

发展

未来KVDB的发展方向（不分先后主次）

1.更少的硬件成本

更高内存利用率、Flash设备SSD的应用
引自一篇博客对Mysql使用SAS磁盘，SSD，FusionIO卡的探讨 http://blog.csdn.net/yanghua_kobe/article/details/7485296







个人认为总结如下：
A点，当数据完全符合缓冲池大小（最佳性能）。数据全在内存中，资源耗费最大，性能最优
B点，坐标出现在当数据刚开始超过缓冲池的大小。内存仅下降了10%，性能下降了2.6倍。这时要做一下抉择，应用需求如果不满足加内存还是SSD?从这条曲线已经能略看出加内存是最节省资源消耗的。
C点展示数据大约是缓冲池三倍的地方。这时你面对的抉择将是，要选择SSD带来两倍的性能提升的开销大，还是增加50%的内存开销大。
数据库要用到的资源包括CPU、内存、存储IO设备、网卡等，只要我们有选择，就应该类似楼上给出一个性能递减和资源消耗的曲线。当然要想完全达到资源利用的最合理化，来回迁移的运维成本也是非常大的，所以未来能自动完成资源设备的过度也是一个重要方向。
从这方面来看不能很好利用现有的高性能设备的kv store也是不完美的

2.更少的维护成本

分布式管理
有关kv store的集群化管理的方案现在已经不在少数了，Couchbase,Hbase,RedisCluster,Aerospike等等
之前接触了两家商业公司描述自己的产品Conchbase及Aerospike，比较关心的还是可用性和扩展性的实现，总结资料如下：

Couchbase：
http://www.couchbase.com/presentations/couchbase-server-24×7-production

http://www.couchbase.com/sites/default/files/uploads/all/whitepapers/Introducing-Couchbase-Server-2_0.pdf




Hbase:这个资料比较多深浅不一，就不详细整理了。
推荐阿里系总结篇：
http://www.alidata.org/archives/1509/comment-page-1





RedisCluster:
http://redis.io/presentation/Redis_Cluster.pdf







Aerospike:
http://www.aerospike.com/performance/architecture/




集群化监控
Ganglia和Nagios是不二之选，选择原因不是由于它本身的强大与否，而是社区累计经验较广。
自动化管理
由于已经采用了集群式的架构，自动化管理方面已经减少了很多人工干预成本，要想高枕无忧，运维系统的开发需要给力！

3.更强控制力度

资源隔离及精细化统计
不同业务间互相干扰是云服务最先面对的问题，CPU/内存/网卡/磁盘带宽都是集群内部应的争抢之地。
要真正做到资源级别的统计，云计算中Iaas层会对资源消耗做精确统计和成本计算，这是未来集群化之后必将面对的。

4.更快的开发周期

由于互联网/游戏公司是kvDB的主要使用方，开发的快速开发支持的越好，在公司内部越容易进行推广。
如MongoDB、CouchBase、Redis都是这方面的典范，所以现在看起来也更流行一点。

5.更加可靠

IDC信息同步、ACID、备份及快速恢复
这是个中长期战略，稍后再进行补充

to be continued

via: http://www.xdata.me/?p=209