[
https://issues.apache.org/jira/browse/CASSANDRA-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987674#action_12987674
]
Daniel Doubleday commented on CASSANDRA-1956:
---------------------------------------------
@Jonathan
Yes I like the invalidation idea.
@Stu
bq. We actually have existing 'filter' implementations (in
org.apache.cassandra.db.filter) that I think would make the most sense for use
aside cache entries.
In my implementation the RowCacheFilter has more responsibilities than just
filtering the columns. It's more like a plugin interface and filter is probably
not the right name for it. It actually uses the db.filter classes.
I guess I don't understand what you proposed as general mechanism. As I said I
had this implementation on 0.6 before and just ported it. My main point was
that I think it would be really helpful if the plugin mechanism would allow for
custom cache handlers (maybe that would be a better name) with a generic
configuration mechanism (filter params in yaml). Because every use case / data
model can be very specific.
bq. Also, regarding the "tombstones in cache" problem: I believe it came up in
IRC the other day. The solution that seemed closest to our existing methods was
to keep the tombstones in cache, but to add a thread that periodically walked
the cache to perform GC (with our existing GC timeout) like we would during
compaction.
I don't understand how that would help me: the TailRowCacheFilter contract is
that it can return a specific amount of live columns. These are cached. If one
of them gets deleted it would not be able to return a valid response. I tried
to cope with that with the expected deletion ratio. But I agree with Jonathon
that this is not good enough.
Again you might have an entirely different solution in mind ...
> 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
> Assignee: Daniel Doubleday
> Fix For: 0.7.2
>
> 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.
