accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Turner (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-980) support pluggable codecs for RFile
Date Fri, 01 Feb 2013 23:30:13 GMT

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

Keith Turner commented on ACCUMULO-980:
---------------------------------------

bq. Actually, it will always do this, as each file has a separate key.

I realize this, because each RFile has its own internal key encrypted with an external key.
 I was wondering about this external key, if you could have different ones for reading and
writing.  Need to establish some firm terminology for the different classes of keys, so discussion
is clear.  Maybe add something to the proposal naming each key type and defining it.  Then
that name could be referenced in discussion.

bq. Overall, then, Keith, does the proposal make sense? Seems workable?

What you are proposing for RFile sounds good.  It would be nice to outline how you are thinking
of integrating this rfile capability into Accumulo.  I suppose these are some of the questions
that I have been asking.   When a major compaction happens, how does it get its keys? What
does that interaction look like?
                
> support pluggable codecs for RFile
> ----------------------------------
>
>                 Key: ACCUMULO-980
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-980
>             Project: Accumulo
>          Issue Type: Improvement
>            Reporter: Adam Fuchs
>            Assignee: Adam Fuchs
>             Fix For: 1.6.0
>
>         Attachments: RFile-Changes-Proposal-V1.pdf
>
>
> As part of the encryption at rest story, RFile should support pluggable modules where
it currently has hardcoded options for compression codecs. This is a natural place to add
encryption capabilities, as the cost of encryption would likely not be significantly different
from the cost of compression, and the block-level integration should maintain the same seek
and scan performance. Given the many implementation options for both encryption and compression,
it makes sense to have a plugin structure here.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message