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

Vijay edited comment on CASSANDRA-5357 at 9/23/13 4:48 AM:
-----------------------------------------------------------

Hi Jonathan, I have pushed a version with sentinel (might have made it little 
hackie, but it works) 
https://github.com/Vijay2win/cassandra/commits/query_cache_v2.

{quote}
Serializing the entire QueryCacheValue for each lookup is going to kill 
performance on hot partitions.
{quote}
It is required because we need to know the query which populated the cache, for 
example there can be a named query for Column A, Z which can be followed by a 
slice query from A to Z and we might not respond with the right response since 
B to Y is not in the cache. 

In a separate ticket we can also optimize the above case (and more) cache 
query's stored, if thats ok. Example: If the slice with count as 250 is stored 
we might not need to store the slice with count of 50 with same range, we can 
also merge overlapping slices etc.

{quote}
if there's room, that's fine, but exceeding the configured memory budget is Bad
{quote}
Can we do that in a separate ticket?, i believe we can achieve this by 
implementing a Iterator which will be similar to SSTableIterator to stream the 
columns than constructing the ColumnFamily at once.

Thanks!
                
      was (Author: vijay2...@yahoo.com):
    Hi Jonathan, I have pushed a version with sentinel (might have made it 
little hackie, but it works) 
https://github.com/Vijay2win/cassandra/commits/query_cache_v2.

{quote}
Serializing the entire QueryCacheValue for each lookup is going to kill 
performance on hot partitions.
{quote}
It is required because we need to know the query which populated the cache, for 
example there can be a named query for Column A, Z which can be followed by a 
slice query from A to Z and we might not respond with the right response since 
B to Y is not in the cache. 

In a separate ticket we can also optimize the above case (and more) cache 
query's stored, if thats ok. Example: If the slice with 250 is stored why to 
also store the slice with 50 in the same range, we can also merge overlapping 
slices etc.

{quote}
if there's room, that's fine, but exceeding the configured memory budget is Bad
{quote}
Can we do that in a separate ticket?, i believe we can achieve this by 
implementing a Iterator which will be similar to SSTableIterator to stream the 
columns than constructing the ColumnFamily at once.

Thanks!
                  
> 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

Reply via email to