[
https://issues.apache.org/jira/browse/CASSANDRA-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13205519#comment-13205519
]
Jonathan Ellis commented on CASSANDRA-1956:
-------------------------------------------
Right now we have a cache that is only useful for accelerating queries against
rows that fit easily into memory, and even then it is inefficient if you only
care about part of the row (either name-based or slice-based).
The filter approach allows us to make slice-based queries more efficient
(somewhat clumsily) but doesn't really address the inefficiency for name-based
queries. As Lior points out, it also doesn't help with 2I queries, while with
a true query cache we could do write-through updates on 2I queries as well
("select * from users where birth_date = 1980"). (This is a fairly
straightforward jump to make for queries within a single composite-PK row, and
admittedly more complex when spanning multiple physical rows gets involved.)
> 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
