牵着老婆满街逛

严以律己,宽以待人. 三思而后行.
GMail/GTalk: yanglinbo#google.com;
MSN/Email: tx7do#yahoo.com.cn;
QQ: 3 0 3 3 9 6 9 2 0 .

导航

<2011年7月>
262728293012
3456789
10111213141516
17181920212223
24252627282930
31123456

统计

公告

言论:
1.每日自省;
2.享受人生;
3.尽力而为;
4.坚持不懈;
5.切莫急躁;
6.慎言敏行;
7.动心忍性;
8.上善若水。

常用链接

留言簿(11)

随笔分类(466)

随笔档案(1513)

文章分类(46)

文章档案(45)

相册

收藏夹(39)

工具官网

技术网站

开源网站

其他窝点

收藏网站

银行官网

友情链接

资源共享

搜索

积分与排名

最新评论

阅读排行榜

来自Riak的LevelDB与InnoDB性能对比测试

转载自:http://blog.nosqlfan.com/html/2305.html

Riak默认采用的是Bitcask的数据引擎,Bitcask能够提供高效,高可用的,防崩溃的数据存储。但是它有一个弱点,就是其内存消耗与存储的数据数量成正比(尽管比例系数比较小)。也就是说如果你使用Bitcask引擎来存储大量小体积的数据,可能会比较浪费空间。

而Riak实时了同时提供了Innostore作为InnoDB引擎的封装,以提供对大量小体积数据的存储,但由于InnoDB引擎固有的一些特点,使得其有一些问题,比如相对Bitcask来说,备份InnoDB会比较困难,还有协议上的问题等等。

在Google发布了其Key-Value存储LevelDB后,引起了Riak的注意,他们发现LevelDB好像正好能够弥补Bitcask和InnoDB在大量小体积数据存储中的缺点,于是他们做了如下几个InnoDB和LevelDB的性能测试

机器配置都是普通的低配机:

a fairly basic 2-CPU Linux server with 4G of RAM, mid-range SATA disks

1.以自增的数字为key顺序的写入1亿条数据

2.对上面写入的1亿条数据进行读取,读取策略采用帕累托分布(帕累托分布即大部分数据请求是对小部分数据集的,这更接近到真实应用场景)

3.同时对上面数据进行读写操作,读写比为90:10

4.单纯的写入操作,同样采用帕累托分布,且分布更严重,也就是操作针对的数据集更小

当然,上面的测试场景仅供参考,具体的性能差别最好还是根据自己的应用场景来做测试。

来源:blog.basho.com


posted on 2011-07-29 10:32 杨粼波 阅读(1153) 评论(0)  编辑 收藏 引用


只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   博问   Chat2DB   管理