理性选择key-value Store

前言

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

综述

key-value store由于本身实现不像成熟RDBMS那么复杂，换句话说开发周期不常，性能更是由于去掉了ACID的约束，从一个个benchmark上看对比起主流开源关系型数据库mysql innodb的曲线都非常好看，op/s号称高一个数量级的不是没有，request latency更是有redis类似的内存性数据库，在高并发的场景下99.95%响应在1ms以下一点也不惊奇。其实对于了解oltp数据系统的同学来说，这其实一点也不神奇。

需求

使用key value store的需求:

业务篇

1. 提高DB端的响应延迟。因为我本身也有计算、多个api调用提交（整体响应时间以最慢api时间为准:-) ）、网络等开销（这个尤其适用于有专有技术平台的公司场景），因为及时我有其他复杂逻辑托我后腿了，我也不想因DB的响应延迟拖后腿，因为这个我们不可控。
2. 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无响应导致百页的情况，应该最为常见。

3. 如果可能请不要Sharding    了解类Mysql DB的同学知道，replication很可能成为DB资源瓶颈，所以我们业务在评估资源的时候发现要面对一堆数据库配置和五花八门的Hash函数，所以我们感叹：你们后端的同学能不能给点力，不让我开发周期一拖再拖。更不能接受的就是因为db要resharding，我们还要花大量时间改造代码。
4. 多数nosql产品对开发友好    面向文档的（mongoDB），直接存储json（Couchbase），多种内存结构hashset,list…(redis) …等等
5. 尝试下新技术    nosql听上去很霸气

系统运维篇

1. TCO的降低    能替代mc+mysql,按照kv的性能测试来看，确实能节省整体TCO
2. 减少部分运维工作    能省去了部分因为性能不足导致的扩容
3. 安全性及可用性    kvDB的大多数都是支持持久化数据的。可用性就是指同步数据的方式，最常见就是replication。效率和可靠性都是需要考量的。
4. 我要尝试下新技术    nosql听上去很霸气

总结：

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

选择

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

表一 主流NOSQL简单对比

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

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

测试

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

Mysql 内存访问性能测试

 原文发布时间为：2013-10-11