[
https://issues.apache.org/jira/browse/CASSANDRA-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13067816#comment-13067816
]
Sylvain Lebresne commented on CASSANDRA-47:
-------------------------------------------
bq. Are we really going to version compression separately from the "main"
sstable version?
Yeah, I guess using the "main" sstable version is ok.
bq. I'm thinking if we will go with a separate file I will use the same
strategy as I did in v1 - store chunk size at the beginning of the chunk and
re-read it
Just so that we agree, if you have the offsets to the beginning of the chunk,
you don't really need the chunk sizes. That being said, it could be useful to
have the size in front of the chunk to be able to uncompress a data file even
if the 'chunk index' got screwed up (but it will be redundant info).
bq. To extend BRAF we will need to split it into Input/Output classes will
imply refactoring of skip cache functionality and other parts of that class
Why ? Is there something in compressed files that requires to have an Input and
a Output class ? Can't we just have CDF seek() method throw an exception if the
CDF has been opened in "rw" mode ? And if we don't split it (which again, I
don't see why we would have to, but maybe I'm missing something), I'm pretty
sure there is very little parts that will require refactoring (skip cache isn't
one of them, CDF will just set skipCache to false; even though I don't see why
skip cache would be a problem with compression).
In any case, having compression optional is a requirement and in my book, the
more important one. To be clear, I'm -1 on committing anything where
compression is not optional (we cannot ask people to trust compression on day
1, and I strongly think that the "let's commit and fix after" is the wrong way
to go). So we at least need CDF and BRAF to have some common ancestor for that.
> SSTable compression
> -------------------
>
> Key: CASSANDRA-47
> URL: https://issues.apache.org/jira/browse/CASSANDRA-47
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Pavel Yaskevich
> Labels: compression
> Fix For: 1.0
>
> Attachments: CASSANDRA-47-v2.patch, CASSANDRA-47.patch,
> snappy-java-1.0.3-rc4.jar
>
>
> We should be able to do SSTable compression which would trade CPU for I/O
> (almost always a good trade).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
