[ https://issues.apache.org/jira/browse/CASSANDRA-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Yuki Morishita updated CASSANDRA-4237: -------------------------------------- Attachment: 4237.txt OK, this attached version schedules flush at Memtable creation when memtable_flush_period_in_ms is set, and it tries to keep flushing at the same interval after memtable is expired. > 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.0 > > 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 For more information on JIRA, see: http://www.atlassian.com/software/jira