Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 23 Jul 2012 16:19:35 +0000 (UTC)
From: "Andrew Purtell (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <1152349189.91514.1343060375069.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <372407485.74306.1342672174956.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Comment Edited] (HBASE-6428) Pluggable Compaction policies
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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