[
https://issues.apache.org/jira/browse/HBASE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13393380#comment-13393380
]
Matt Corgan commented on HBASE-6222:
------------------------------------
DataBlockEncoding gives us the opportunity to add features to a KeyValue
interface but create different implementations that have the option of ignoring
some of the features. For HBASE-4676 (PrefixTrie), I need to create an
interface so that I can store the different parts of a KeyValue in different
backing arrays:
https://github.com/hotpads/hbase-prefix-trie/blob/master/src/org/apache/hadoop/hbase/cell/HCell.java
This discussion reminds me of the memstoreTS in the current KeyValue which is
more of an afterthought and has negative performance implications. With
DataBlockEncoding I'm able to treat it as a first class citizen when it is
needed and encode it away when it's not needed. I suppose there is a small cpu
cost, but really small relative to what else is happening.
In the future, I think we're going to want to treat the legacy KeyValue and
legacy LinkedList<KeyValue> style data blocks as just another DataBlockEncoding
(DataBlockEncoding.NONE), and instead do most operations through a KeyValue
interface. After a lot of benchmarking and research on compiler optimizations,
I'm pretty sure we are far away from any performance issues with an interface
if people are worried about that... i can comment more on that later if anyone
wants.
> 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
