[
https://issues.apache.org/jira/browse/CASSANDRA-5348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13802975#comment-13802975
]
Michael Andrews commented on CASSANDRA-5348:
--------------------------------------------
+1 to Robert and Sylvain's comments. We were planning to use the on-heap row
cache as a memcache replacement for a very small but heavily used table, but
now our upgrade to 2.0 has put us back at the drawing board. I thought
Cassandra was built for systems engineers who knew the risks of what they were
doing and had the flexibility to make those choices? I can wait until 2.1 for
a better caching mechanism, but this seems like something that could have
stayed with a disclaimer and more documentation on how to use it appropriately.
> Remove on-heap row cache
> ------------------------
>
> Key: CASSANDRA-5348
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5348
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 2.0 beta 1
>
> Attachments: 5348.txt
>
>
> The row (partition) cache easily does more harm than good. People expect it
> to act like a query cache but it is very different than that, especially for
> the wide partitions that are so common in Cassandra data models.
> Making it off-heap by default only helped a little; we still have to
> deserialize the partition to the heap to query it.
> Ultimately we can add a better cache based on the ideas in CASSANDRA-1956 or
> CASSANDRA-2864, but even if we don't get to that until 2.1, removing the old
> row cache for 2.0 is a good idea.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
