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

[经验分享] (分析比较到位)NoSql 分析 hbase,mongodb,redis

[复制链接]

尚未签到

发表于 2016-12-21 08:12:17 | 显示全部楼层 |阅读模式
hbase,mongodb,redis都属于nosql型存储方案。在实际的项目实践上看,他们的系统存储及处理的数量由大到小。HBase基于列存储,提供<key, family:qualifier, timestamp>三项坐标方式定位数据,由于其qualifier的动态可扩展型(无需schema设计,可存储任意多的qualifier),特别适合存储稀疏表结构的数据(比如互联网网页类)。HBase不支持二级索引,读取数据方面只支持通过key或者key范围读取,或者全表扫描。
 
  MongoDb在类SQL语句操作方面目前比HBase具备更多一些优势,有二级索引,支持相比于HBase更复杂的集合查找等。BSON的数据结构使得处理文档型数据更为直接。MongoDb也支持mapreduce,但由于HBase跟Hadoop的结合更为紧密,Mongo在数据分片等mapreduce必须的属性上不如HBase这么直接,需要额外处理
HBase与Mongodb的读写性能正好相反,HBase写优于随机读,MongoDB似乎写性能不如读性能。

Redis为内存型KV系统,处理的数据量要小于HBase与MongoDB
 
 
  1.Mongodb bson文档型数据库,整个数据都存在磁盘中,hbase是列式数据库,集群部署时每个familycolumn保存在单独的hdfs文件中。 
2.Mongodb 主键是“_id”,主键上面可以不建索引,记录插入的顺序和存放的顺序一样,hbase的主键就是row key,可以是任意字符串(最大长度是 64KB,实际应用中长度一般为 10-100bytes),在hbase内部,row key保存为字节数组。存储时,数据按照Row key的字典序(byte order)排序存储。设计key时,要充分排序存储这个特性,将经常一起读取的行存储放到一起。 
字典序对int排序的结果是1,10,100,11,12,13,14,15,16,17,18,19,2,20,21,…,9,91,92,93,94,95,96,97,98,99。要保持整形的自然序,行键必须用0作左填充。 
3.Mongodb支持二级索引,而hbase本身不支持二级索引 
4.Mongodb支持集合查找,正则查找,范围查找,支持skip和limit等等,是最像mysql的nosql数据库,而hbase只支持三种查找:通过单个row key访问,通过row key的range,全表扫描 
5.mongodb的update是update-in-place,也就是原地更新,除非原地容纳不下更新后的数据记录。而hbase的修改和添加都是同一个命令:put,如果put传入的row key已经存在就更新原记录,实际上hbase内部也不是更新,它只是将这一份数据已不同的版本保存下来而已,hbase默认的保存版本的历史数量是3。 
6.mongodb的delete会将该行的数据标示为已删除,因为mongodb在删除记录时并不是真把记录从内存或文件中remove,而是将该删除记录数据置空(写0或特殊数字加以标识)同时将该记录所在地址放到一个list列表“释放列表”中,这样做的好就是就是如果有用户要执行插入记录操作时,mongodb会首先从该“释放列表”中获取size合适的“已删除记录”地址返回,这种方法会提升性能(避免了malloc内存操作),同时mongodb也使用了bucket size数组来定义多个大小size不同的列表,用于将要删除的记录根据其size大小放到合适的“释放列表”中。Hbase的delete是先新建一个tombstonemarkers,然后读的时候会和tombstonemarkers做merge,在 发生major compaction时delete的数据记录才会真真删除。 
7.mongodb和hbase都支持mapreduce,不过mongodb的mapreduce支持不够强大,如果没有使用mongodb分片,mapreduce实际上不是并行执行的 
8.mongodb支持shard分片,hbase根据row key自动负载均衡,这里shard key和row key的选取尽量用非递增的字段,尽量用分布均衡的字段,因为分片都是根据范围来选择对应的存取server的,如果用递增字段很容易热点server的产生,由于是根据key的范围来自动分片的,如果key分布不均衡就会导致有些key根本就没法切分,从而产生负载不均衡。 
9.mongodb的读效率比写高,hbase默认适合写多读少的情况,可以通过hfile.block.cache.size配置,该配置storefile的读缓存占用Heap的大小百分比,0.2表示20%。该值直接影响数据读的性能。如果写比读少很多,开到0.4-0.5也没问题。如果读写较均衡,0.3左右。如果写比读多,果断默认0.2吧。设置这个值的时候,你同时要参考hbase.regionserver.global.memstore.upperLimit,该值是memstore占heap的最大百分比,两个参数一个影响读,一个影响写。如果两值加起来超过80-90%,会有OOM的风险,谨慎设置。 
10.hbase采用的LSM思想(Log-Structured Merge-Tree),就是将对数据的更改hold在内存中,达到指定的threadhold后将该批更改merge后批量写入到磁盘,这样将单个写变成了批量写,大大提高了写入速度,不过这样的话读的时候就费劲了,需要merge disk上的数据和memory中的修改数据,这显然降低了读的性能。mongodb采用的是mapfile+Journal思想,如果记录不在内存,先加载到内存,然后在内存中更改后记录日志,然后隔一段时间批量的写入data文件,这样对内存的要求较高,至少需要容纳下热点数据和索引。

运维网声明 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-317096-1-1.html 上篇帖子: 用Redis实现分布式锁完善思路 下篇帖子: 美团在Redis上踩过的一些坑-2.bgrewriteaof问题
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

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

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

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

扫描微信二维码查看详情

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


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


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


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



合作伙伴: 青云cloud

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