[
https://issues.apache.org/jira/browse/CASSANDRA-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13067868#comment-13067868
]
Pavel Yaskevich commented on CASSANDRA-47:
------------------------------------------
bq. I don't understand that argument. BRAF and CDF do the same thing, they only
differ in that CDF has a decompression/compression step while moving data
in/out of the buffer and has a slight translation between which part of the
file to buffer. The rest of the code is the exact same, all the buffer
manipulation, when to sync, when to rebuffer, etc.. is the same. And it's not
the simplest code ever, not a place where having code duplication sound like a
good idea.
The argument is - I am willing to do a "merge" but would like to do that in the
separate task because that would involve refactoring for BRAF (I wrote that
previously), I don't like to use BRAF in the current state where Input/Output
operations aren't split.
bq. I don't see why adding a new component adds any complexity.
Because having a new component for metadata means that you won't be able to
open and read a compressed file without previously open and read metadata, this
is not better then holding information about chunks in the INDEX component.
> 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
