Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 30 Apr 2015 18:17:07 +0000 (UTC)
From: "Josh Elser (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12822514.1429577611000.37641.1430417827136@Atlassian.JIRA>
In-Reply-To: <JIRA.12822514.1429577611000@Atlassian.JIRA>
References: <JIRA.12822514.1429577611000@Atlassian.JIRA>
 <JIRA.12822514.1429577611972@arcas>
Subject: [jira] [Commented] (HBASE-13519) Support coupled compactions with
 secondary index
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Josh Elser commented on HBASE-13519:
------------------------------------

bq. In other words, it does not change existing HBase codebase. In this case, does it make sense to make patch?

IMO, I think it's easier to keep this external to HBase. It's already hard enough to write and maintain the primitives in a key-value store that your project uses. Also, since your project is already cleanly separated into using the expected client-facing code HBase provides, I don't much immediate value in pulling it into HBase.

If you do really want to include this in HBase itself, it would be good to outline answers to some basic where/why/how questions (e.g. where does this fit into HBase itself? why should it be included in HBase? how would you technically go about including it?). If the community can come to agreement that it would be a worthwhile endeavor to pursue, only then would it make sense to do start investigating the necessary incubator/code-grant steps.

> Support coupled compactions with secondary index 
> -------------------------------------------------
>
>                 Key: HBASE-13519
>                 URL: https://issues.apache.org/jira/browse/HBASE-13519
>             Project: HBase
>          Issue Type: New Feature
>            Reporter: tristartom
>
> Hi,
> DELI (DEferred Lightweight Indexing) is our research prototype from Syracuse University with collaboration from Georgia Tech and IBM Research. 
> In DELI, we propose that when supporting secondary index on HBase, the index-to-base-table sync-up should be coupled with compaction. The benefit of this is that online Put stays to be append-only and performance would be guaranteed. 
> The code of DELI is shared in github: https://github.com/tristartom/nosql-indexing
> Details can be found in the following research paper published in CCGrid 2015: http://tristartom.github.io/docs/ccgrid15.pdf
> We are grateful for the HBase community, and any comments/suggestions are appreciated.
> Yuzhe


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)