[
https://issues.apache.org/jira/browse/CASSANDRA-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162540#comment-13162540
]
Daniel Doubleday commented on CASSANDRA-1956:
---------------------------------------------
Looking at CASSANDRA-3143 I understand that the consensus seems to be that
users should be protected from missconfigurations and that a sane 'works most
of the time' solution is the way to go.
Still I want to note why I do believe that some solution along the lines of
your patch is a good idea.
Obviously I can only speak for us and our usecases but our app can only work
with the relevant data set in mem.
Being able to to optimize caching using the knowledge about data access
patterns could significantly improve effeciency.
Right now we still need first level caching for a lot of use cases which makes
life not necessarily easier.
With the patch custom cache providers could (on a per cf basis) cache partial
rows, optimize memory format or even integrate other caching solutions. We
could also skip caching entirely for certain queries. This would also be great
for maintenance jobs which would otherwise lead to cache thrashing.
I understand that nobody wants to scare off adopters but all of this would not
really change anything for people who want to go with the sane standard. And of
course it is also clear that such extension points cannot be guaranteed to be
stable.
Yada yada yada ...
Thanks for the effort btw!
> 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.1
>
> 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
