[
https://issues.apache.org/jira/browse/HBASE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13393589#comment-13393589
]
Matt Corgan commented on HBASE-6222:
------------------------------------
{quote}@Matt So attributes carry in information and we use a new encoding type
to store tags adjacent to KVs if they are labelled?{quote}
Yeah, basically you would be required to use the new encoding format
(TaggedPrefixTrie, for example), and if you switched back to
DataBlockEncoding.NONE, your tags would be erased (we'd want to make that
scenario appropriately difficult of course.). The trie would de-duplicate
them, take up no space if they aren't there, and use >=1 byte per cell index if
they are there.
{quote}Have you had a chance to go through Todd's attempt and see if you were
able to resolve all of the concerns there?{quote}
I was aware Todd tried this at some point but haven't looked into the details
or talked to him about it. I assume he was attempting a full "extract
interface" style refactoring, which I think is probably too big of a change.
My approach is a little different and sets in place a strategy for gradually
migrating to the interface. From the top of the HCell class linked to above,
you can see these methods that require any implementation to be able to create
legacy KeyValues.
{code}
//V1 is the byte[] format of the current KeyValue implementation.
//for building a result to send to client
int getV1KeyLength();
int getV1Length();
byte[] getV1KeyValueArray();
KeyValue getKeyValue();
ByteBuffer getV1KeyBuffer();
int appendKeyToV1ByteArray(byte[] output, int offset);
int appendToV1ByteArray(byte[] output, int offset);
{code}
This lets the interface start in the data block encoders and slowly grow out
into the storefiles, filters, etc, and eventually out to the client.
Eventually we deprecate those methods from the interface and try to finalize
the transition. One problem with this approach with regard to the tags is that
only the storage layer would know about them at first, and it would take some
time to expose them to the client.
All-in-all, the tags raise some interesting questions in my mind like "why
isn't everything in the KV implemented as a tag?" For example, i'd love to see
per-cell TTL's someday. Maybe tags go hand-in-hand with co-processors to
implement features like that?
> Add per-KeyValue Security
> -------------------------
>
> 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
