[
https://issues.apache.org/jira/browse/CASSANDRA-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13205579#comment-13205579
]
Jonathan Ellis commented on CASSANDRA-1956:
-------------------------------------------
bq. What is so clumsy?
First, that you need to explicitly configure it as part of the schema. Second,
because it inherently only allows one type of query to be cached. "One CF per
query" is the wrong rule of thumb -- "One CF per type of resultset" is my
preferred one. So for instance, you couldn't cache both oldest entries and
newest, from the same row in a CF.
bq. while with a true query cache we could do write-through updates on 2I
queries as well
What I mean by this is that {{select * from users where birth_date = 1980}} is
a query that people could reasonably want to cache, that we can't fit into your
3 categories of "full row, head/tail, handful of named columns."
At a more sophisticated stage from that, a "true" query cache could update that
cached resultsets whenever someone updates the birth_date value to or from
1980, so the query stays fast without having to be recalculated. (We already
have the perfect place in the code for this where index maintenance happens in
Table.apply.)
> 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-commiting-block-cache.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
