Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 30 Jul 2012 02:59:34 +0000 (UTC)
From: "Zhihong Ted Yu (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <1812076446.115046.1343617174750.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <1881046060.74299.1342671815215.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Commented] (HBASE-6427) Pluggable compaction policies via
 coprocessors
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Zhihong Ted Yu commented on HBASE-6427:
---------------------------------------

There is no intersection between memstore scanners and store scanners.

The arbitrary number of scanners is due to the following construct:
{code}
+    for (RegionEnvironment env: coprocessors) {
+      if (env.getInstance() instanceof RegionObserver) {
+        ctx = ObserverContext.createAndPrepare(env, ctx);
+        try {
+          s = ((RegionObserver) env.getInstance()).preCompactScannerOpen(ctx, store, scanners,
+              scanType, earliestPutTs, s);
{code}
I think we should reduce the complexity (due to scanner chaining) for preCompactScannerOpen().
If we don't provide a working model for scanner chaining, there is no need to introduce construct for chaining scanners.
                
> 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-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 pluggable.
> 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