cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Eriksson (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-5357) Query cache / partition head cache
Date Fri, 10 Jan 2014 14:14:01 GMT


Marcus Eriksson updated CASSANDRA-5357:

    Attachment: 0001-Cache-a-configurable-amount-of-columns.patch

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

> Query cache / partition head cache
> ----------------------------------
>                 Key: CASSANDRA-5357
>                 URL:
>             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

View raw message