hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Hsieh (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-6222) Add per-KeyValue Security, get federal funding for HBase?
Date Sat, 16 Jun 2012 18:00:43 GMT

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

Jonathan Hsieh edited comment on HBASE-6222 at 6/16/12 5:59 PM:
----------------------------------------------------------------

@Andy I'm not proposing we necessarily do it the way accumulo does it -- the more important
point is that we mimic it's semantics to make it easier for users to eventually port to HBase.
:) 

The meta column idea you describe in HBASE-2893 and its use cases seems to also argue for
 restoring the distinction between locality groups and column families from original bigtable
paper. (these are conflated in HBase).  

Using a meta column for cell-granularity visibility seems like a reasonable hbase implementation
option.  I'm not convinced why this approach would save significantly more space.  I do think
 the not changing core argument is more compelling hbase-specific constraint.

The accumulo implementation has a default case that would make it cost the tags cost extra
only on cells with non-default behavior (e.g. only the highly-sensitive or cols with sensitivity
varying cells).  They delta encode their keys (including the visiblity tags) like we do in
0.94.

As a straw man, a core-changing HBase version that modified KV's wouldn't necessarily incur
more space -- we'd could a new KeyValue.Type (TaggedPut?) that had visibility settings, and
use the old Put type that used the default tags. 
                
      was (Author: jmhsieh):
    @Andy I'm not proposing we necessarily do it the way accumulo does it -- the more important
point is that we mimic it's semantics to make it easier for users to eventually port to HBase.
:) 

The meta column idea you describe in HBASE-2893 and its use cases seems to also argue for
 restoring the distinction between locality groups and column families from original bigtable
paper. (these are conflated in HBase).  

Using a meta column for cell-granularity visibility seems like a reasonable hbase implementation
option.  I'm not convinced why this approach would save significantly more space.  I do think
the not changing the not changing core argument is more compelling constriant.

The accumulo implementation has a default case that would make it cost the tags cost extra
only on cells with non-default behavior (e.g. only the highly-sensitive or cols with sensitivity
varying cells).  They delta encode their keys (including the visiblity tags) like we do in
0.94.

As a straw man, a core-changing HBase version that modified KV's wouldn't necessarily incur
more space -- we'd could a new KeyValue.Type (TaggedPut?) that had visibility settings, and
use the old Put type that used the default tags. 
                  
> 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

        

Mime
View raw message