[
https://issues.apache.org/jira/browse/HBASE-792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-792.
-------------------------
Resolution: Fixed
Resolving as done for now.
> Rewrite getClosestAtOrJustBefore; doesn't scale as currently written
> --------------------------------------------------------------------
>
> Key: HBASE-792
> URL: https://issues.apache.org/jira/browse/HBASE-792
> Project: HBase
> Issue Type: Bug
> Reporter: stack
> Assignee: stack
> Priority: Blocker
> Attachments: 792.patch
>
>
> As currently written, as a table gets bigger, the number of rows .META. needs
> to keep count of grows.
> As written, our getClosestAtOrJustBefore, goes through every storefile and in
> each picks up any row that could be a possible candidate for closest before.
> It doesn't just get the closest from the storefile, but all keys that are
> closest before. Its not selective because how can it tell at the store file
> level which of the candidates will survive deletes that are sitting in later
> store files or up in memcache.
> So, if a store file has keys 0-10 and we ask to get the row that is closest
> or just before 7, it returns rows 0-7.. and so on per store file.
> Can bet big and slow weeding key wanted.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
