cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4667) optimize memtable deletions for batchlog
Date Tue, 02 Oct 2012 16:39:07 GMT


Jonathan Ellis commented on CASSANDRA-4667:

Let's recap what we're trying to do here.

When every node is up, there's no reason to write batchlog data out to sstables (which in
turn incurs cost like compaction) since the BL write + delete cancel each other out, and BL
data is strictly local, so we don't need to preserve tombstones for repair.

It still looks to me like the simplest way to achieve this is to look at the rows being written
during flush -- if we have a data row + row level tombstone, then writing it is effectively
an expensive no-op and we can skip it.  Rest of the flush machinery doesn't need to change,
including telling the commitlog that it can start replay after the flush point.
> optimize memtable deletions for batchlog
> ----------------------------------------
>                 Key: CASSANDRA-4667
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>            Reporter: Aleksey Yeschenko
>            Assignee: Aleksey Yeschenko
>         Attachments: CASSANDRA-4667-v1.1.patch, CASSANDRA-4667-v2.patch
> Batchlog writes with the same key are never retried. This means that if a batchlog row
is in the memtable, it can't be in any of the sstables, ever. In such cases we don't need
to write a tombstone to disk. We can purge the row completely from the memtable and only write
a tombstone if the row had been flushed already (if it's not in the memtable then it must
be in one of the sstables).

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:

View raw message