cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Doubleday (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-1956) Convert row cache to row+filter cache
Date Fri, 28 Jan 2011 10:27:44 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988023#action_12988023
] 

Daniel Doubleday commented on CASSANDRA-1956:
---------------------------------------------

Now it's my ahh  :-) I think I understood your idea.

Instead of configuring cache rules you want to cache every filtered request like mysql query
cache?

I dropped the idea because I thought it would be either very restricted to certain query patterns
or very complicated to keep in sync with memtables and/or decide whether a query can be served
by the cache. Also it might be hard to avoid that the cache is being polluted (analogous to
the page cache eviction problem during compaction). It might force the developer to spread
the data over multiple CFs according to access pattern which increases memory needs (more
memtables, more rows).

But yes - if you can come up with an automagical cache management that just works that would
be obviously nicer!

PS: If you wan to have a look at the patch: apply to 0.7 r1064192


> 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.


Mime
View raw message