找回密码
 骑士注册

QQ登录

微博登录

搜索
❏ 站外平台:

Linux中国开源社区 技术 查看内容

理性选择key-value Store

| 2013-10-11 22:10      

测试

之前围绕着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,比较关心的还是可用性和扩展性的实现,总结资料如下:
Hbase:这个资料比较多深浅不一,就不详细整理了。
推荐阿里系总结篇:
集群化监控
Ganglia和Nagios是不二之选,选择原因不是由于它本身的强大与否,而是社区累计经验较广。
自动化管理
由于已经采用了集群式的架构,自动化管理方面已经减少了很多人工干预成本,要想高枕无忧,运维系统的开发需要给力!

3.更强控制力度

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

4.更快的开发周期

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

5.更加可靠

IDC信息同步、ACID、备份及快速恢复
这是个中长期战略,稍后再进行补充
to be continued
via: http://www.xdata.me/?p=209 
12
查看其它分页:

最新评论

我也要发表评论

返回顶部

分享到微信

打开微信,点击顶部的“╋”,
使用“扫一扫”将网页分享至微信。