[
https://issues.apache.org/jira/browse/CASSANDRA-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13062730#comment-13062730
]
Pavel Yaskevich commented on CASSANDRA-47:
------------------------------------------
bq. Why would the uncompressed size for -C 250 be different from the
uncompressed size for -C 50: 3.8 GB vs the 1.7 GB from before?
I did simply choose the largest files from individual compactions.
Also I don't know why you getting only 3.7GB of data after `-S 1024 -n 1000000
-C 250 -V` because in all of my tests I get about 5.1GB which current trunk
code and with patch applied.
My results:
||build||disk volume (bytes)||write runtime (s)||read runtime (s)||read ops/s||
||trunk||5,241,718,144||166||2210||~450||
||#47||5,090,003,162 (1.2GB of blocks aka real size)||156||480||~2100||
Both sizes are after last major compaction, cassandra with default
configuration running on Quad-Core AMD Opteron(tm) Processor 2374 HE with
4229730MHz on each core, 2GB RAM - Debian 5.0 (Lenny) (kernel 2.6.35.4-rscloud)
hosted on rackspace.
> 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.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
