Chinaunix首页 | 论坛 | 博客
  • 博客访问: 172479
  • 博文数量: 13
  • 博客积分: 1660
  • 博客等级: 上尉
  • 技术积分: 688
  • 用 户 组: 普通用户
  • 注册时间: 2008-08-04 16:38
文章分类
文章存档

2014年(2)

2013年(11)

分类: 大数据

2013-04-07 18:39:33

最近要用提供上十亿的数据查询,目前主流的几种NoSQL并不能拿来就用。找了几个相关的db考察了一番,记录一下。

业务需求:
1.key-value数据结构,随机读,低延时。
2.数据量大(10亿+),机器紧张。
3.一次性写(一天一次),多次读。
4.支持主要的协议,高可用,易扩展。

入选:
一,redis
优点:纯内存,读取性能很好,但是占内存。rehash机制可以保证更新数据数据时,不影响读性能。
缺点:需要几台机器才能放下。 如果要提供热备,机器数x2。  同时分布式管理不方便。

测试结果:读写性能应该最好,但是没有机器资源,放弃。

二,leveldb
优点:leveldb为随机写做了很多优化,比如log和memtable
缺点:随机读性能一般,相比下面的kyoto cabinet 和lmdb。


测试后的结论:leveldb比其他数据库稳定,而且数据量增大后,读写性能下降平缓。
10亿数据平均下来12ms/req

三,kyoto cabinet(HashDB ,TreeDB)
优点:mmap可以减少read,write 等从内核拷贝数据。 同时hashDB直接hash,应该会比leveldb快
缺点:随机写和批量写性能低

测试后的结论:HashDB和TreeDB的入库太慢,完全无法忍受。尤其到后面几亿的时候,没有反应了,一个晚上没有入库成功,放弃。
但发现kyoto tycoon性能不错,支持各种协议。

四,lmdb
优点:看kc和leveldb对比报告时,发现该作者号称性能搞过leveldb很多倍。
缺点:除了openldap在用,好像没有其他使用者,而且是12年整出来的。

测试后的结论:小数据时,由于mmap的作用性能很好,过5亿后急剧下降。切换确实是个大问题。
10亿数据平均下来14ms/req,和leveldb相差不大。


最后选择了kyoto tycoon+leveldb。
具体测试数据因机器不同,写了也没有意义,不贴了,大概4G内存情况下,性能在5ms/req左右。
阅读(8237) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~