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-6427) Pluggable compaction policies via coprocessors
Date Mon, 30 Jul 2012 20:57:35 GMT

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

Lars Hofhansl commented on HBASE-6427:

Thanks Ted and Andy, and thanks for the discussion.
I think we have two (maybe three) take-aways: (1) We need to look at the various scanner interface
and see why we have so many diverging interfaces and (2) add more coprocessor documentation
(maybe with some more examples) and potentially (3) think generally about what it means to
extend HBase and when coprocessors are a good mechanism for that.

It seems to me that coprocessors are a good solution to effect existing processing at certain
(including critical) spots, but maybe not suited to replace the entire logic. In that this
issue represents a corner case - which is probably what spawned the longer discussion here
(the creation of the StoreScanner is replaced, and this is done in the context of a bigger
In the future we might be able to use Guice to replace entire subsystems.

For this issue I'll fix up the Javadoc issues that Ted mentions and commit this to trunk and
also make a 0.94 patch.

Thanks again for the review and the discussion.
> Pluggable compaction policies via coprocessors
> ----------------------------------------------
>                 Key: HBASE-6427
>                 URL: https://issues.apache.org/jira/browse/HBASE-6427
>             Project: HBase
>          Issue Type: New Feature
>            Reporter: Lars Hofhansl
>            Assignee: Lars Hofhansl
>            Priority: Minor
>         Attachments: 6427-notReady.txt, 6427-v1.txt, 6427-v10.txt, 6427-v2.txt, 6427-v3.txt,
6427-v4.txt, 6427-v5.txt, 6427-v7.txt
> When implementing higher level stores on top of HBase it is necessary to allow dynamic
control over how long KVs must be kept around.
> Semi-static config options for ColumnFamilies (# of version or TTL) is not sufficient.
> This can be done with a few additional coprocessor hooks, or by makeing Store.ScanInfo
> Was:
> The simplest way to achieve this is to have a pluggable class to determine the smallestReadpoint
for Region. That way outside code can control what KVs to retain.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message