[jira] [Comment Edited] (CASSANDRA-5357) Query cache / partition head cache

["Marcus Eriksson (JIRA)" <ji...@apache.org>]

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

Marcus Eriksson edited comment on CASSANDRA-5357 at 1/10/14 3:22 PM:
---------------------------------------------------------------------

Patch that caches first N cql rows (or first N cells per partition). N is configurable and defaults to 100.

Approach is basically, on read:
* If row key is not in cache, read up the first n cells, stick them in cache.
* If the newly cached data does not include all cells requested by user, we do *another read*. We cannot know if the requested cells will be included in the first N cells. Question is if we should really put that row in cache in that case? It means we don't totally waste the read we just did, but we might waste row cache memory instead.
* Needs to deserialize the entire cached value in order to know if the query can be served from cache. An optimization could be to keep the last-cached-cellname on the heap to quickly check.


was (Author: krummas):
Patch that caches first N cql rows (or first N cells per partition). N is configurable and defaults to 100.

Approach is basically, on read:
* If row key is not in cache, read up the first n cells, stick them in cache.
* If the newly cached data does not include all cells requested by user, we do *another read*. We cannot know if the requested columns will be included in the first N columns. Question is if we should really put that row in cache in that case? It means we don't totally waste the read we just did, but we might waste row cache memory instead.
* Needs to deserialize the entire cached value in order to know if the query can be served from cache. An optimization could be to keep the last-cached-cellname on the heap to quickly check.

> Query cache / partition head cache
> ----------------------------------
>
>                 Key: CASSANDRA-5357
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5357
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Jonathan Ellis
>            Assignee: Marcus Eriksson
>             Fix For: 2.1
>
>         Attachments: 0001-Cache-a-configurable-amount-of-columns.patch
>
>
> I think that most people expect the row cache to act like a query cache, because that's a reasonable model.  Caching the entire partition is, in retrospect, not really reasonable, so it's not surprising that it catches people off guard, especially given the confusion we've inflicted on ourselves as to what a "row" constitutes.
> I propose replacing it with a true query cache.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)