设为首页 收藏本站
查看: 1079|回复: 0

[经验分享] 比Redis更快:Berkeley DB面面观

[复制链接]

尚未签到

发表于 2015-7-19 14:10:14 | 显示全部楼层 |阅读模式
比Redis更快:Berkeley DB面面观
  Redis很火,最近大家用的多。从两年前开始,Memcached转向Redis逐渐成为潮流;
而Berkeley DB可能很多朋友还很陌生,首先,我们简单的介绍一下。

Berkeley DB介绍


  • 历史悠久。Berkeley DB1991年发行第一版, 2006年被Oracle收购;
  • Berkeley DB是一个嵌入式数据库系统,将其归类到内存数据库范畴没有问题;
  •   使用Key-Value结构存储,本身不支持SQL,5.5版以后整合了SQLite,可使用sql进行查询;官方资料给出的评估是如果原生的bdb能让性能提升10倍,使用SqlLite之后,大概就只有2-3倍;sql的解析及底层的衔接耗时较多;

  •   开源产品,使用的开源协议为: AFFERO GPL (AGPL)。这个协议对商用产品主要的约束是对与使用Berkeley DB的软件,发布软件包时需要付费;举个例子:如果微软的office要使用则必须付费;而腾讯的QQ后台服务器使用则无需付费;


Berkeley DB设计思想
  简单、小巧、可靠、高性能。
DB库和应用运行在同一进程空间,接口为API形式,应用通过API存取DB;

应用范例
  MySQL 5.1版之前的数据事务存储引擎使用的是Berkeley DB;(5.1版之后不再使用更多的可能是出于商业的原因,因为Berkeley DB被Oracle收购了)
Google Accounts选用的Berkeley DB作为存储引擎;

Berkeley DB VS Redis
  除了速度,Berkeley DB的最大的优势是支持多索引(次级索引);支持多索引,使得从关系型DB中移植到内存DB更容易,可有效避免数据膨胀及自行处理索引之间的映射关系;
DSC0000.png
eg:一张学生信息表,以学号为主键(唯一性索引)建立了索引可以查询到指定的学生记录;如果再希望以姓名来查询,可以以姓名为键建立次级索引来查询;
在查询条件比较复杂的情况下,可组合建立多个次级索引来找到同一份数据;
想进一步了解次级索引如何使用,可参考这篇文章:《Berkeley DB多索引查询》

性能测试对比:Berkeley DB VS Redis
  使用环境:

CPU:Intel Core 2 Duo P9xxx 2.0G
MEM:16G
OS:Red Hat Enterprise Linux Server release 6.3  (Santiago) x86_64
  同样是内存数据库,我们对比Berkeley DB和Redis的运行时间(单位:ms)
A表记录:506622条记录:每条记录:96个字节
B表记录:2478条记录;每条记录:10个字节;
C表记录:107221条记录;每条记录:82个字节;
DSC0001.png
重建内存数据库 BDB用4s,Redis 20s;
更新内存数据库,BDB和Redis的实验结果都比较理想
查询记录时,BDB比Redis基本快一个数量级;
缓存、重建整个表操作,BDB性能明显优于Redis;这是因为BDB提供批量读取所有数据的接口,而Redis没有提供类似的接口;

性能对比测试:Berkeley DB VS Oracle
  为了将数据从Oracle中移植出来,我们需要对比关系型数据库和Berkeley DB的查询效率:
首先,我们使用唯一性索引作为Berkeley DB的主键,并因此查询来和oracle对比;
数据规模:

实验数据;1112516条记录:
大小2.8G;
  以查询出最终结果为准:
SQL查询:
SELECT * FROM table_a
WHERE (DATE=to_date(:v, 'YYYYMMDD') AND A =:a AND B =:b AND c>=:c AND D>=:d)  AND ( E=:e)  AND (F=:F) AND (G=:g)  AND H!='C' AND N='N'";
其中>= 、 !=操作无法编入索引,在索引查处数据后需应用再进行筛选过滤;
最终的查询结果为一条记录;
DSC0002.png


     在存取速度上,Berkerley DB比关系型数据库,比redis都快不少,在批量查询及数据导入操作上甚至快上一个数量级。这主要是因为:

1. 全内存操作;数据都在内存中;

2. DB与应用在同一个进程地址空间中;这样,就没有额外的网络开销。

当然,我们会意识到使用Berkerley DB就必须在每个应用物理节点上都开辟一大块内存,来存放Berkerley DB的数据。这方面,分布式的Redis则显得更为实惠。

  如果这篇文章让你对Berkeley DB产生了兴趣,如果你也想着效率那点事,想着将关系数据库转到nosql,试着上手吧。传送门:《Berkeley DB入门篇》。
  Posted by: 大CC | 31OCT,2013
博客:blog.me115.com
微博:新浪微博
  

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-88335-1-1.html 上篇帖子: 缓存子系统如何设计(Cachable tag, Memcache/redis support, xml config support, LRU/LFU/本地缓存 下篇帖子: redis源码分析(1)内存管理
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表