zhu*_*eng 8 performance hbase filter database-scan
如果我使用prefixfilter进行查询,我不知道为什么它会很慢.有人可以解释一下查询HBase的最佳方法,谢谢.
hbase(main):002:0> scan 'userlib',{FILTER=>org.apache.hadoop.hbase.filter.PrefixFilter.new(org.apache.hadoop.hbase.util.Bytes.toBytes('0000115831F8'))}
ROW COLUMN+CELL
0000115831F8001 column=track:aid, timestamp=1339121507633, value=aaa
1 row(s) in 41.0700 seconds
hbase(main):002:0> scan 'userlib',{STARTROW=>'0000115831F8',ENDROW=>'0000115831F9'}
ROW COLUMN+CELL
0000115831F8001 column=track:aid, timestamp=1339121507633, value=aaa
1 row(s) in 0.1100 seconds
Run Code Online (Sandbox Code Playgroud)
Sum*_*man 16
HBase过滤器 - 甚至行过滤器 - 非常慢,因为在大多数情况下,这些过滤器会进行完整的表扫描,然后对这些结果进行过滤.看一下这个讨论:http://grokbase.com/p/hbase/user/115cg0d7jh/very-slow-scan-performance-using-filters
然而,行键范围扫描确实要快得多 - 它们相当于过滤后的表扫描.这是因为行键按排序顺序存储(这是HBase的基本保证之一,这是类似BigTable的解决方案),因此行键上的范围扫描速度非常快.更多解释如下:http://www.quora.com/How-feasible-is-real-time-querying-on-HBase-Can-it-be-achieved-through-a-programming-language-such-as- Python的PHP-OR-JSP
[更新1]事实证明,PrefixFilter会执行全表扫描,直到它通过过滤器中使用的前缀(如果找到它).使用PrefixFilter的快速性能建议似乎是指定除 PrefixFilter 之外的start_row参数.请参阅有关hbase-user邮件列表的2013年相关讨论.
[更新2,来自@ aaa90210]关于上述更新,现在有一个高效的行前缀过滤器比PrefixFilter快得多,请参阅以下答案:https://stackoverflow.com/a/38632100/150050
| 归档时间: |
|
| 查看次数: |
18148 次 |
| 最近记录: |