cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yuki Morishita (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-4237) Add back 0.8-style memtable_lifetime feature
Date Mon, 05 Nov 2012 19:34:13 GMT

     [ 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

Attaching rebased and updated version.

bq. is there a race here where if user manually calls force flush while it's expired, we get
two scheduled tasks added?

You are right, so I moved the rescheduling code from forceFlush to scheduleFlush. I just let
periodic flush to be scheduled without canceling already scheduled ones, and let the task
check expiration before running flush.
                
> 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

Mime
View raw message