[
https://issues.apache.org/jira/browse/CASSANDRA-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179689#comment-13179689
]
Sylvain Lebresne commented on CASSANDRA-1956:
---------------------------------------------
bq. ... to answer my own question, "I want to keep an entire CF in memory" is a
fairly common request. So maybe the answer is, we support that more directly,
as well as the query cache.
Thinking out loud, but with secondary indexes, we use the trick of expanding
the filter to a full row filter if the maxRowSize for the cfs is smaller that
some value (the columnIndexSize more specially). Given that keeping entire CF
in memory really make sense only for static (narrow) CFs, we could just expand
filters for those CFs automatically and just have a query cache as far as the
cache implementation is concerned.
As a side note, I share Daniel's opinion (at least I believe that's what he
meant earlier) that a serializing query cache that invalidate on update will be
very useful for wide rows. At least I don't see many use cases where it would.
However I see a cache that would not invalidate on update but keep the cached
data matching the filter be much more useful, even if we start by an on-heap
cache. And once we've agreed that we'll evacuate the delete problem by
invalidating, I don't think it's too hard to do.
> 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
> Reporter: Stu Hood
> Assignee: Vijay
> Priority: Minor
> Fix For: 1.2
>
> Attachments: 0001-1956-cache-updates-v0.patch,
> 0001-re-factor-row-cache.patch, 0001-row-cache-filter.patch,
> 0002-1956-updates-to-thrift-and-avro-v0.patch, 0002-add-query-cache.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.
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
