cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Schuller (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-3921) Compaction doesn't clear out expired tombstones from SerializingCache
Date Thu, 16 Feb 2012 01:30:59 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13209048#comment-13209048
] 

Peter Schuller commented on CASSANDRA-3921:
-------------------------------------------

With a typical workload, not evicting it would just fail to "optimize" - you have to wait
for the data to get dropped out of cache.

But if you do have a use-case where you have a lot of requests to non-existent data, this
could "silently" render the row caches almost useless in a way that is very hard to detect.
Suppose you have rows with a hot set where you want caching, but the data is made up of "churning"
columns (insertions/deletions; the set of columns constantly  But, the "damaged" is limited
to the ratio of requests for empty rows vs. other requests, and is less prominent the bigger
the average requested row in relation to the size of a tombstone.

The above should be true if the rows in cache only contain the tombstones.

But consider a use-case where you have rows (hot) that gets constantly updated with insertion/deletion
(let's say it has 1-5 columns at any point in time, with columns constantly "churned"). How
you have something which is hot in cache due to reads (for the ones in hot set), data being
over-written, and the per-row average size increasing over time. Cache locality becomes worse
and worse and no one can see why, and a restart magically fixes it. This should hold true
as long as row cache entries aren't entirely re-read on writes, which would in part defeat
the purpose of caching (but I realize now I'm not sure what we do here).

                
> Compaction doesn't clear out expired tombstones from SerializingCache
> ---------------------------------------------------------------------
>
>                 Key: CASSANDRA-3921
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3921
>             Project: Cassandra
>          Issue Type: Bug
>    Affects Versions: 0.8.0
>            Reporter: Jonathan Ellis
>            Priority: Minor
>             Fix For: 1.1.0
>
>
> Compaction calls removeDeletedInCache, which looks like this:
> {code}
> .   public void removeDeletedInCache(DecoratedKey key)
>     {
>         ColumnFamily cachedRow = cfs.getRawCachedRow(key);
>         if (cachedRow != null)
>             ColumnFamilyStore.removeDeleted(cachedRow, gcBefore);
>     }
> {code}
> For the SerializingCache, this means it calls removeDeleted on a temporary, deserialized
copy, which leaves the cache contents unaffected.

--
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

        

Mime
View raw message