[
https://issues.apache.org/jira/browse/CASSANDRA-8895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14965998#comment-14965998
]
Jeff Jirsa commented on CASSANDRA-8895:
---------------------------------------
On the variable chunk size: explicit compression chunk size allows an operator
to balance between performance and compression ratios, where they can drop
block size to be much smaller for faster reads, or increase it to save disk
usage (larger chunks = better ratios). We manually balance this - assessing
exactly those tradeoffs - on clusters today, and I would be sad to see that
turned into magic under the hood. I would encourage the project to let
operators decide what compression chunk size they want, imo.
> Compressed sstables should only compress if the win is above a certain
> threshold, and should use a variable block size
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-8895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8895
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Paulo Motta
> Labels: performance
> Fix For: 3.x
>
>
> On performing a flush to disk, we should assess if the data we're flushing
> will actually be substantively compressed, and how large the page should be
> to get optimal compression ratio versus read latency. Decompressing 64Kb
> chunks is wasteful when reading small records.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
