[
https://issues.apache.org/jira/browse/CASSANDRA-6809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14123492#comment-14123492
]
Jason Brown commented on CASSANDRA-6809:
----------------------------------------
[~barnie] Your proposal is very similar to to what I've implemented wrt to
adding encryption to the commitlog. Instead of subclassing CLS, I created a new
interface, hastily named SegmentWriter, with two impls (one non-encrypted, the
other encrypted), which is then referenced from CLS. More or less, the same as
what you are thinking, I'm sure.
Also, It's not clear to me what you are measuring:
bq. I'm seeing that the current implementation of memory-mapped IO for commit
logs does not help slow HDDs, but has a very noticeable effect (10-20%) on SSDs
Is this the time for the sync() call to complete? So, then, you are evaluating
the value of using mmap? If we're not planning on using mmap, are you thinking
about buffering data ourselves (which is then flushed by the sync thread)?
> Compressed Commit Log
> ---------------------
>
> Key: CASSANDRA-6809
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6809
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Benedict
> Assignee: Branimir Lambov
> Priority: Minor
> Labels: performance
> Fix For: 3.0
>
> Attachments: logtest.txt
>
>
> It seems an unnecessary oversight that we don't compress the commit log.
> Doing so should improve throughput, but some care will need to be taken to
> ensure we use as much of a segment as possible. I propose decoupling the
> writing of the records from the segments. Basically write into a (queue of)
> DirectByteBuffer, and have the sync thread compress, say, ~64K chunks every X
> MB written to the CL (where X is ordinarily CLS size), and then pack as many
> of the compressed chunks into a CLS as possible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
