[
https://issues.apache.org/jira/browse/CASSANDRA-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987072#action_12987072
]
Jonathan Ellis commented on CASSANDRA-1956:
-------------------------------------------
bq. Rather than keeping track of tombstones in the cache (could not figure out
how to do it without locking) deletions are not handled but 'expected' and
accounted by caching columns * expected_ts_ratio which is configurable)
This seems pretty error prone. What about just invalidating (removing from the
cache) the row on delete and letting it get rebuild on the next read? Either
way, it means TailRowCacheFilter is not a great fit for workloads w/ lots of
deletes (which I am okay with) but at least you don't risk outright invalid
answers this way.
> Convert row cache to row+filter cache
> -------------------------------------
>
> Key: CASSANDRA-1956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1956
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 0.7.0
> Reporter: Stu Hood
> Attachments: 0001-row-cache-filter.patch
>
>
> Changing the row cache to a row+filter cache would make it much more useful.
> We currently have to warn against using the row cache with wide rows, where
> the read pattern is typically a peek at the head, but this usecase would be
> perfect supported by a cache that stored only columns matching the filter.
> Possible implementations:
> * (copout) Cache a single filter per row, and leave the cache key as is
> * Cache a list of filters per row, leaving the cache key as is: this is
> likely to have some gotchas for weird usage patterns, and it requires the
> list overheard
> * Change the cache key to "rowkey+filterid": basically ideal, but you need a
> secondary index to lookup cache entries by rowkey so that you can keep them
> in sync with the memtable
> * others?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
