Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 16 Jun 2012 19:34:42 +0000 (UTC)
From: "Andrew Purtell (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <1601257057.21977.1339875282862.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <1104092684.21359.1339824642708.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Comment Edited] (HBASE-6222) Add per-KeyValue Security, get
 federal funding for HBase?
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Andrew Purtell edited comment on HBASE-6222 at 6/16/12 7:33 PM:
----------------------------------------------------------------

Thus far we have various hooks and a proposal for an out of band approach: HBASE-2893, HBASE-4477, API object attributes (HBASE-3811, HBASE-3931, etc.). The impetus (as I understand it) for an out of band approach is the special nature of KV and the desire to avoid adding additional conditionals/complexity in code wherever it touches KV. That is balanced by the problems an out of band approach causes for minimizing overheads when tags are present, as Jon mentions, without locality groups (a significant change) there is extra IO. I see this as a more conservative approach that won't perturb performance sensitive members of our community, because there is zero overhead unless configuration is toggled on, coprocessors are loaded, and such.

However I am not arguing for or against any particular approach. The suggestions by Jon, Lars, and Jimmy are the start of a design proposal but should be pulled together into an actual proposal (as another JIRA?). This is my point. Adding even only one byte to every KV has a very significant effect on storage and IO when the data set is large. Adding a new type avoids that but what is the impact in the code? And it wouldn't be one new type right, there would be a tagged analogue for every mutator? A convincing exploration of these issues would go a long way here IMHO.
                
      was (Author: apurtell):
    Thus far we have various hooks and a proposal for an out of band approach: HBASE-2893, HBASE-4477, API object attributes (HBASE-3811, HBASE-3931, etc.). The impetus (as I understand it) for an out of band approach is the special nature of KV and the desire to avoid adding additional conditionals/complexity in code wherever it touches KV. That is balanced by the performance impact of an out of band approach, as Jon mentions, without locality groups (a significant change) there is extra IO. I see this as a more conservative approach that won't perturb performance sensitive members of our community, because there is zero overhead unless configuration is toggled on, coprocessors are loaded, and such.

However I am not arguing for or against any particular approach. The suggestions by Jon, Lars, and Jimmy are the start of a design proposal but should be pulled together into an actual proposal (as another JIRA?). This is my point. Adding even only one byte to every KV has a very significant effect on storage and IO when the data set is large. Adding a new type avoids that but what is the impact in the code? And it wouldn't be one new type right, there would be a tagged analogue for every mutator? A convincing exploration of these issues would go a long way here IMHO.
                  
> Add per-KeyValue Security, get federal funding for HBase?
> ---------------------------------------------------------
>
>                 Key: HBASE-6222
>                 URL: https://issues.apache.org/jira/browse/HBASE-6222
>             Project: HBase
>          Issue Type: New Feature
>          Components: security
>            Reporter: stack
>
> Saw an interesting article: http://www.fiercegovernmentit.com/story/sasc-accumulo-language-pro-open-source-say-proponents/2012-06-14
> "The  Senate Armed Services Committee version of the fiscal 2013 national defense authorization act (S. 3254) would require DoD agencies to foreswear the Accumulo NoSQL database after Sept. 30, 2013, unless the DoD CIO certifies that there exists either no viable commercial open source database with security features comparable to [Accumulo] (such as the HBase or Cassandra databases)..."
> Not sure what a 'commercial open source database' is, and I'm not sure whats going on in the article, but tra-la-la'ing, if we had per-KeyValue 'security' like Accumulo's, we might put ourselves in the running for federal contributions?

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