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] [Commented] (HBASE-6427) Pluggable compaction policies via coprocessors
Date Mon, 30 Jul 2012 02:38:34 GMT

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

Andrew Purtell commented on HBASE-6427:

bq. I understand the goal for this JIRA and am in support of it. [...] This illustrates the
intricacies of scanner chaining. If a scanner is designed for some specific purpose, I wouldn't
expect it to function correctly when an arbitrary number of scanners are chained (both) upstream
and downstream.

Pardon Ted but I think this is an X-Y argument. I'm not sure we are discussing the chaining
of _arbitrary_ scanners (unless I have this wrong.) Each CP hook is dealing with a constrained
set of scanners. Flushes will be dealing with memstore scanners. Compactions will be dealing
with store scanners. The question has been what kind of interface should input parameters
and return types share, there's some design give-and-take there. But we are not talking about,
for example, combining memstore scanners with store scanners. (At least, I am not.)
> 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
> 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