[ https://issues.apache.org/jira/browse/CASSANDRA-10520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16183606#comment-16183606 ]
Paulo Motta edited comment on CASSANDRA-10520 at 9/28/17 3:19 AM: ------------------------------------------------------------------ Tagging this as {{client-impacting}} to support the new {{min_compression_ratio}} option. (cc [~aholmber] [~omichallat] [~adutra]). Please disconsider if this was already taken care of, but I haven't found any ticket to support this, and the new option doesn't seem to be available on trunk cqlsh/stress. was (Author: pauloricardomg): Tagging this as {{client-impacting}} to support the new {{min_compression_ratio}} option. (cc [~aholmber] [~omichallat] [~adutra]). Please disconsider if this was already taken care of, but I haven't found any ticket to support this, and the new option doesn't seem to be working on trunk cqlsh/stress. > Compressed writer and reader should support non-compressed data. > ---------------------------------------------------------------- > > Key: CASSANDRA-10520 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10520 > Project: Cassandra > Issue Type: Improvement > Components: Local Write-Read Paths > Reporter: Branimir Lambov > Assignee: Branimir Lambov > Labels: client-impacting, messaging-service-bump-required > Fix For: 4.0 > > Attachments: ReadWriteTestCompression.java > > > Compressing uncompressible data, as done, for instance, to write SSTables > during stress-tests, results in chunks larger than 64k which are a problem > for the buffer pooling mechanisms employed by the > {{CompressedRandomAccessReader}}. This results in non-negligible performance > issues due to excessive memory allocation. > To solve this problem and avoid decompression delays in the cases where it > does not provide benefits, I think we should allow compressed files to store > uncompressed chunks as alternative to compressed data. Such a chunk could be > written after compression returns a buffer larger than, for example, 90% of > the input, and would not result in additional delays in writing. On reads it > could be recognized by size (using a single global threshold constant in the > compression metadata) and data could be directly transferred into the > decompressed buffer, skipping the decompression step and ensuring a 64k > buffer for compressed data always suffices. -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org