免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 1804 | 回复: 1

[HBase] hbase读取效率低下疑问 [复制链接]

论坛徽章:
6
IT运维版块每日发帖之星
日期:2015-09-05 06:20:00IT运维版块每日发帖之星
日期:2015-09-06 06:20:00IT运维版块每日发帖之星
日期:2015-10-17 06:20:00IT运维版块每周发帖之星
日期:2015-11-06 19:28:13IT运维版块每日发帖之星
日期:2015-11-07 06:20:00操作系统版块每周发帖之星
日期:2015-12-02 15:01:04
发表于 2015-10-26 13:52 |显示全部楼层
今天在阅读hbase权威指南的时候看到一句话,hbase使用的是LSM存储数据,和b-tree相比:
The stored data is always in an optimized layout. So, you have a predictable and consistent boundary on the number of disk seeks to access a key, and reading any number of records following that key doesn’t incur any extra seeks. In general, what could be emphasized about an LSM-tree-based system is cost transparency: you know that if you have five storage files, access will take a maximum of five disk seeks, whereas you have no way to determine the number of disk seeks an RDBMS query will take, even if it is indexed.

为什么有rowkey在进行数据检索的时候还是依然会耗费大量的cost呢?是因为hbase没有单独记录索引信息么?所以每次数据查询都只有进行全表扫描?所以得出的结论是对少量数据的及时查询效果会很不好,但是对大批量的数据处理和写入性能会有大幅度的提升

论坛徽章:
6
IT运维版块每日发帖之星
日期:2015-09-05 06:20:00IT运维版块每日发帖之星
日期:2015-09-06 06:20:00IT运维版块每日发帖之星
日期:2015-10-17 06:20:00IT运维版块每周发帖之星
日期:2015-11-06 19:28:13IT运维版块每日发帖之星
日期:2015-11-07 06:20:00操作系统版块每周发帖之星
日期:2015-12-02 15:01:04
发表于 2015-10-26 23:16 |显示全部楼层
转载:http://www.tuicool.com/articles/iieIz2
已经明白为啥了,因为:
“前面提到过StoreFile是只读的,一旦创建后就不可以再修改。因此Hbase的更 新其实是不断追加的操作。当一个Store中的StoreFile达到一定的阈值后,就会进行一次合并(major compact),将对同一个key的修改合并到一起,形成一个大的StoreFile,当StoreFile的大小达到一定阈值后,又会对 StoreFile进行split,等分为两个StoreFile。
由于对表的更新是不断追加的,处理读请求时,需要访问Store中全部的 StoreFile和MemStore,将他们的按照row key进行合并,由于StoreFile和MemStore都是经过排序的,并且StoreFile带有内存中索引,合并的过程还是比较快”
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP