hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12311) Version stats in HFiles?
Date Sat, 28 Feb 2015 07:28:05 GMT

    [ https://issues.apache.org/jira/browse/HBASE-12311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14341400#comment-14341400
] 

Lars Hofhansl commented on HBASE-12311:
---------------------------------------

Tested some more with KVs with 10, 100, and 10000 versions. The more version we have the more
likely it becomes that we would seek past the next indexed key of the top scanner in the heap
and hence keep the seek. So this appears to work fine with few and many versions, as well
as few and many columns, and all cases it will estimate whether a SKIP or a SEEK is better.


> Version stats in HFiles?
> ------------------------
>
>                 Key: HBASE-12311
>                 URL: https://issues.apache.org/jira/browse/HBASE-12311
>             Project: HBase
>          Issue Type: Brainstorming
>            Reporter: Lars Hofhansl
>         Attachments: 12311-indexed-0.98.txt, 12311-v2.txt, 12311-v3.txt, 12311.txt, CellStatTracker.java
>
>
> In HBASE-9778 I basically punted the decision on whether doing repeated scanner.next()
called instead of the issueing (re)seeks to the user.
> I think we can do better.
> One way do that is maintain simple stats of what the maximum number of versions we've
seen for any row/col combination and store these in the HFile's metadata (just like the timerange,
oldest Put, etc).
> Then we estimate fairly accurately whether we have to expect lots of versions (i.e. seek
between columns is better) or not (in which case we'd issue repeated next()'s).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message