hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-6428) Pluggable Compaction policies
Date Mon, 23 Jul 2012 16:19:35 GMT

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

Andrew Purtell edited comment on HBASE-6428 at 7/23/12 4:18 PM:
----------------------------------------------------------------

Is there a use case where there could be multiple receivers for a getSmallestReadPoint call?
Where you want that kind of stacking, the CP API upcall approach is good; where you have a
global behavior that you might want to override, a plug makes sense. For consistency's sake,
those pluggable points should all work the same way. We have HBASE-4050's ServiceLoader, but
I think we should also look at Guice (HBASE-6407). 

Edit: Another consideration is performance. I'd like to draw a distinction between coarse
grained extension and fine grained extension. The former is where large sections of functionality
are replaced, for example using CPs to replace default compaction selection with another strategy.
The latter certainly applies to single method calls on hot code paths. For the latter, ideally
we want an extension mechanism that will still allow the JVM to inline what's plugged in.

                
      was (Author: apurtell):
    Is there a use case where there could be multiple receivers for a getSmallestReadPoint
call? Where you want that kind of stacking, the CP API upcall approach is good; where you
have a global behavior that you might want to override, a plug makes sense. For consistency's
sake, those pluggable points should all work the same way. We have HBASE-4050's ServiceLoader,
but I think we should also look at Guice (HBASE-6407). 
                  
> Pluggable Compaction policies
> -----------------------------
>
>                 Key: HBASE-6428
>                 URL: https://issues.apache.org/jira/browse/HBASE-6428
>             Project: HBase
>          Issue Type: New Feature
>            Reporter: Lars Hofhansl
>
> For some usecases is useful to allow more control over how KVs get compacted.
> For example one could envision storing old versions of a KV separate HFiles, which then
rarely have to be touched/cached by queries querying for new data.
> In addition these date ranged HFile can be easily used for backups while maintaining
historical data.
> This would be a major change, allowing compactions to provide multiple targets (not just
a filter).

--
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

        

Mime
View raw message