Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 26 Mar 2013 05:15:15 +0000 (UTC)
From: "Vijay (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12637544.1363617645910.53909.1364274915490@arcas>
In-Reply-To: <JIRA.12637544.1363617645910@arcas>
References: <JIRA.12637544.1363617645910@arcas>
Subject: [jira] [Commented] (CASSANDRA-5357) Query cache
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Vijay commented on CASSANDRA-5357:
----------------------------------

Ooops, I thought i was continuing the discussion from the other ticket... My bad.

What i had in mind was to do something like Map<RowKey, [QueryFilter,ColumnFamily]> so invalidation is O(1)
To further improve the performance on a query (And deserializing the whole [QueryFilter,ColumnFamily] we can have all the QueryFilters as a part of the RowKey (Kind of like promoted index's).

If we do this then the K (For a fat row) becomes big enough to cause more heap issue. 
Hence we could move that to off-heap along with CF.

Query to a CF will be constant time (or O(m) where m is the size of queries within a row), Space complexity is also constant since we have the key is a off heap reference and a hash.

There is one downside in this approche, if a row is hot all the queries will stay in memory longer (Unless we reimplement a cache like CLHM)... 
If we think this is big enough problem then we would need an alternative approach where we have 2 Maps one for <QF, CF> and the other for <RK, QF> mapping, which might not be that space efficient. Let me know.
                
> Query cache
> -----------
>
>                 Key: CASSANDRA-5357
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5357
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Jonathan Ellis
>            Assignee: Vijay
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira