[
https://issues.apache.org/jira/browse/CASSANDRA-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420671#comment-13420671
]
Jonathan Ellis commented on CASSANDRA-4237:
-------------------------------------------
I don't think this is quite what we want, since it will flush the memtable
every {{period}} regardless of whether it has already been recently flushed by
normal request volume. (FWIW, the 0.8 brute force approach was to loop over
each CFS in the KS every 10s, and flush it if it was expired -- see callers of
CFS.forceFlushIfExpired.)
> Add back 0.8-style memtable_lifetime feature
> --------------------------------------------
>
> Key: CASSANDRA-4237
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4237
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Affects Versions: 1.0.0
> Reporter: Jonathan Ellis
> Assignee: Yuki Morishita
> Priority: Minor
> Fix For: 1.2
>
> Attachments: 4237.txt
>
>
> Back in 0.8 we had a memtable_lifetime_in_minutes setting. We got rid of it
> in 1.0 when we added CASSANDRA-2427, which is a better way to ensure
> flushing on low-activity memtables.
> However, at the same time we also added the ability to disable durable
> writes. So it's entirely possible to configure a low-activity memtable, that
> isn't part of the commitlog. So, we should add back a memtable lifetime
> setting.
> An additional motive is pointed out by
> http://www.fsl.cs.sunysb.edu/~pshetty/socc11-gtssl.pdf: if you have a *high*
> activity columnfamily, and don't require absolute durability, the commitlog
> is redundant if you are flushing faster than the commitlog sync period. So,
> disabling durable writes but setting memtable lifetime to the same as the
> commitlog sync would be a reasonable optimization.
> Thus, when we add back memtable lifetime, I think we should measure it in
> seconds or possibly even milliseconds (to match commitlog_sync_period) rather
> than minutes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
