理性选择key-value Store
| 2013-10-11 22:10
前言
开源产品固然好，但是各种场景的数据需求确实多少有些差距，利用现有的软硬件资源面对现有的问题快速做出调整是才是数据库工程师的真正价值。
综述
需求
业务篇
- 提高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听上去很霸气
选择
表一 主流NOSQL简单对比
参考：http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
| Cassandra | Mongodb | CouchDB | Redis | Riak | HBase | |
| 开发语言 | JAVA | C++ | Erlang | C / C++ | Erlang/ C / JAVASCRIPT | JAVA |
| 特点 |
分布式与复制的权衡 根据列和键范围进行查询 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 |
| 最佳适用 | 基于JAVA，写操作较多，读少 | 动态的查询，定义索引而非map/reduce。数据变化快，磁盘不够用，可以使用MongoDB | 有大量数据，但更新不大，需要预先定义查询 | 数据快速变化，数据库大小可以预见（适合内存存取数据） |
简单的类似Cassandra 或Dynamo的功能，较强的单点容错性和扩展性 |
随机数据、实时读取海量数据 |
| 应用场景 | 银行，金融行业。数据分析 |
MySQL或 PostgreSQL 的替代品 |
CRM、CMS系统 | 股价系统，数据分析，实时数据采集以及实时通信场景 | 销售点数据采集。工厂控制系统。需要零停机时间的场景 |
喜欢bigTable，需要随即、实时的读写大数据(Big Data) |
测试
之前围绕着Mysql,Redis,LevelDB,Hbase做过一些不同目的的性能测试，也算对这些产品的性能有了大概了解，未来需要对性能数据完善一下！
总结
发展
1.更少的硬件成本
2.更少的维护成本
3.更强控制力度
4.更快的开发周期
5.更加可靠
 );){kind=link}