[
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)
