You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2010/01/07 01:36:54 UTC
[jira] Created: (CASSANDRA-678) row-level cache
row-level cache
---------------
Key: CASSANDRA-678
URL: https://issues.apache.org/jira/browse/CASSANDRA-678
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 0.9
We have a key cache but that doesn't help mitigate the expensive deserialization of the actual data to return.
Adding a row-level cache should be fairly simple using a ConcurrentLinkedHashMap<String [key], ColumnFamily> structure. (We will only cache whole rows at a time, since already know how to query on those in-memory. This limits us to CFs full of narrow rows but that is a common enough use case to be worth tackling if it can be done simply enough.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-678) row-level cache
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797533#action_12797533 ]
Jonathan Ellis commented on CASSANDRA-678:
------------------------------------------
I have the basic functionality working for reads now. Next: cache invalidation on insert.
> row-level cache
> ---------------
>
> Key: CASSANDRA-678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-678
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.9
>
>
> We have a key cache but that doesn't help mitigate the expensive deserialization of the actual data to return.
> Adding a row-level cache should be fairly simple using a ConcurrentLinkedHashMap<String [key], ColumnFamily> structure. (We will only cache whole rows at a time, since already know how to query on those in-memory. This limits us to CFs full of narrow rows but that is a common enough use case to be worth tackling if it can be done simply enough.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-678) row-level cache
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-678:
-------------------------------------
Attachment: 0005-combine-SSTable-keycaches-into-one-at-CFS-level.-do-no.txt
0004-make-rowcache-keycache-configurable-per-CF.txt
0003-instrumentation.txt
0002-clean-up-onstart-to-fix-cache-size-calculation.txt
0001-basic-caching.txt
> row-level cache
> ---------------
>
> Key: CASSANDRA-678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-678
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.9
>
> Attachments: 0001-basic-caching.txt, 0002-clean-up-onstart-to-fix-cache-size-calculation.txt, 0003-instrumentation.txt, 0004-make-rowcache-keycache-configurable-per-CF.txt, 0005-combine-SSTable-keycaches-into-one-at-CFS-level.-do-no.txt
>
>
> We have a key cache but that doesn't help mitigate the expensive deserialization of the actual data to return.
> Adding a row-level cache should be fairly simple using a ConcurrentLinkedHashMap<String [key], ColumnFamily> structure. (We will only cache whole rows at a time, since already know how to query on those in-memory. This limits us to CFs full of narrow rows but that is a common enough use case to be worth tackling if it can be done simply enough.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-678) row-level cache
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798301#action_12798301 ]
Jonathan Ellis commented on CASSANDRA-678:
------------------------------------------
05
to provide similar visibility into keycache performance, combines SSTable keycaches into one at CFS level. This results in losing most of the performance gains of using a key cache. I've included this in case someone sees something obviously dumb I did, but it's definitely not good to apply in current form.
04
make rowcache, keycache configurable per-CF
03
row cache jmx instrumentation (size, hit rate)
02
clean up onstart to fix cache size calculation
01
basic row caching
> row-level cache
> ---------------
>
> Key: CASSANDRA-678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-678
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.9
>
> Attachments: 0001-basic-caching.txt, 0002-clean-up-onstart-to-fix-cache-size-calculation.txt, 0003-instrumentation.txt, 0004-make-rowcache-keycache-configurable-per-CF.txt, 0005-combine-SSTable-keycaches-into-one-at-CFS-level.-do-no.txt
>
>
> We have a key cache but that doesn't help mitigate the expensive deserialization of the actual data to return.
> Adding a row-level cache should be fairly simple using a ConcurrentLinkedHashMap<String [key], ColumnFamily> structure. (We will only cache whole rows at a time, since already know how to query on those in-memory. This limits us to CFs full of narrow rows but that is a common enough use case to be worth tackling if it can be done simply enough.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-678) row-level cache
Posted by "Ryan King (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798751#action_12798751 ]
Ryan King commented on CASSANDRA-678:
-------------------------------------
Configuring it by rows would be fine. Most of our rows will be pretty consistently sized (within a given CF) so we can do the math to get GB's.
> row-level cache
> ---------------
>
> Key: CASSANDRA-678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-678
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.9
>
> Attachments: 0001-basic-caching.txt, 0002-clean-up-onstart-to-fix-cache-size-calculation.txt, 0003-instrumentation.txt, 0004-make-rowcache-keycache-configurable-per-CF.txt, 0005-combine-SSTable-keycaches-into-one-at-CFS-level.-do-no.txt, 0005-update-cached-rows-in-place-instead-of-invalidating-.patch
>
>
> We have a key cache but that doesn't help mitigate the expensive deserialization of the actual data to return.
> Adding a row-level cache should be fairly simple using a ConcurrentLinkedHashMap<String [key], ColumnFamily> structure. (We will only cache whole rows at a time, since already know how to query on those in-memory. This limits us to CFs full of narrow rows but that is a common enough use case to be worth tackling if it can be done simply enough.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-678) row-level cache
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798302#action_12798302 ]
Jonathan Ellis commented on CASSANDRA-678:
------------------------------------------
My limited testing shows roughly 100% throughput improvement and a reduction of 50% in latency with 01 to 04 applied and a cache large enough to get an 80% hit rate.
> row-level cache
> ---------------
>
> Key: CASSANDRA-678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-678
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.9
>
> Attachments: 0001-basic-caching.txt, 0002-clean-up-onstart-to-fix-cache-size-calculation.txt, 0003-instrumentation.txt, 0004-make-rowcache-keycache-configurable-per-CF.txt, 0005-combine-SSTable-keycaches-into-one-at-CFS-level.-do-no.txt
>
>
> We have a key cache but that doesn't help mitigate the expensive deserialization of the actual data to return.
> Adding a row-level cache should be fairly simple using a ConcurrentLinkedHashMap<String [key], ColumnFamily> structure. (We will only cache whole rows at a time, since already know how to query on those in-memory. This limits us to CFs full of narrow rows but that is a common enough use case to be worth tackling if it can be done simply enough.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-678) row-level cache
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798747#action_12798747 ]
Jonathan Ellis commented on CASSANDRA-678:
------------------------------------------
It wouldn't be hard to add an absolute number of rows as an option (GB would be much more expensive to measure), but I'm trying to do the smallest amount that is actually useful in this ticket. (as usual :)
> row-level cache
> ---------------
>
> Key: CASSANDRA-678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-678
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.9
>
> Attachments: 0001-basic-caching.txt, 0002-clean-up-onstart-to-fix-cache-size-calculation.txt, 0003-instrumentation.txt, 0004-make-rowcache-keycache-configurable-per-CF.txt, 0005-combine-SSTable-keycaches-into-one-at-CFS-level.-do-no.txt, 0005-update-cached-rows-in-place-instead-of-invalidating-.patch
>
>
> We have a key cache but that doesn't help mitigate the expensive deserialization of the actual data to return.
> Adding a row-level cache should be fairly simple using a ConcurrentLinkedHashMap<String [key], ColumnFamily> structure. (We will only cache whole rows at a time, since already know how to query on those in-memory. This limits us to CFs full of narrow rows but that is a common enough use case to be worth tackling if it can be done simply enough.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-678) row-level cache
Posted by "Ryan King (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798744#action_12798744 ]
Ryan King commented on CASSANDRA-678:
-------------------------------------
It would be nice if the capacity configuration was in absolute size, rather than a fraction of the CF size. In other words, I'd like to be able to configure cassandra like "use 1GB of row cache per CF". Obviously, as your data set gets bigger, your cache hit ratios will go down (assuming your traffic distribution stays relatively uniform).
Otherwise, I think this looks awesome, this will really help us.
> row-level cache
> ---------------
>
> Key: CASSANDRA-678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-678
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.9
>
> Attachments: 0001-basic-caching.txt, 0002-clean-up-onstart-to-fix-cache-size-calculation.txt, 0003-instrumentation.txt, 0004-make-rowcache-keycache-configurable-per-CF.txt, 0005-combine-SSTable-keycaches-into-one-at-CFS-level.-do-no.txt, 0005-update-cached-rows-in-place-instead-of-invalidating-.patch
>
>
> We have a key cache but that doesn't help mitigate the expensive deserialization of the actual data to return.
> Adding a row-level cache should be fairly simple using a ConcurrentLinkedHashMap<String [key], ColumnFamily> structure. (We will only cache whole rows at a time, since already know how to query on those in-memory. This limits us to CFs full of narrow rows but that is a common enough use case to be worth tackling if it can be done simply enough.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-678) row-level cache
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-678:
-------------------------------------
Attachment: 0005-update-cached-rows-in-place-instead-of-invalidating-.patch
05 (2nd one)
update cached rows in-place instead of invalidating & reloading. should make it more suitable for relatively wide rows,
> row-level cache
> ---------------
>
> Key: CASSANDRA-678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-678
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.9
>
> Attachments: 0001-basic-caching.txt, 0002-clean-up-onstart-to-fix-cache-size-calculation.txt, 0003-instrumentation.txt, 0004-make-rowcache-keycache-configurable-per-CF.txt, 0005-combine-SSTable-keycaches-into-one-at-CFS-level.-do-no.txt, 0005-update-cached-rows-in-place-instead-of-invalidating-.patch
>
>
> We have a key cache but that doesn't help mitigate the expensive deserialization of the actual data to return.
> Adding a row-level cache should be fairly simple using a ConcurrentLinkedHashMap<String [key], ColumnFamily> structure. (We will only cache whole rows at a time, since already know how to query on those in-memory. This limits us to CFs full of narrow rows but that is a common enough use case to be worth tackling if it can be done simply enough.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-678) row-level cache
Posted by "Chris Goffinet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799047#action_12799047 ]
Chris Goffinet commented on CASSANDRA-678:
------------------------------------------
+1. Adding the ability to adjust this via JMX/Nodeprobe and Ryan's suggestion of setting total rows is a good idea.
> row-level cache
> ---------------
>
> Key: CASSANDRA-678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-678
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.9
>
> Attachments: 0001-basic-caching.txt, 0002-clean-up-onstart-to-fix-cache-size-calculation.txt, 0003-instrumentation.txt, 0004-make-rowcache-keycache-configurable-per-CF.txt, 0005-combine-SSTable-keycaches-into-one-at-CFS-level.-do-no.txt, 0005-update-cached-rows-in-place-instead-of-invalidating-.patch
>
>
> We have a key cache but that doesn't help mitigate the expensive deserialization of the actual data to return.
> Adding a row-level cache should be fairly simple using a ConcurrentLinkedHashMap<String [key], ColumnFamily> structure. (We will only cache whole rows at a time, since already know how to query on those in-memory. This limits us to CFs full of narrow rows but that is a common enough use case to be worth tackling if it can be done simply enough.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-678) row-level cache
Posted by "Chris Goffinet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798569#action_12798569 ]
Chris Goffinet commented on CASSANDRA-678:
------------------------------------------
Apologies, yes you're right. Had another patch named 0002 that I didn't notice.
> row-level cache
> ---------------
>
> Key: CASSANDRA-678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-678
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.9
>
> Attachments: 0001-basic-caching.txt, 0002-clean-up-onstart-to-fix-cache-size-calculation.txt, 0003-instrumentation.txt, 0004-make-rowcache-keycache-configurable-per-CF.txt, 0005-combine-SSTable-keycaches-into-one-at-CFS-level.-do-no.txt, 0005-update-cached-rows-in-place-instead-of-invalidating-.patch
>
>
> We have a key cache but that doesn't help mitigate the expensive deserialization of the actual data to return.
> Adding a row-level cache should be fairly simple using a ConcurrentLinkedHashMap<String [key], ColumnFamily> structure. (We will only cache whole rows at a time, since already know how to query on those in-memory. This limits us to CFs full of narrow rows but that is a common enough use case to be worth tackling if it can be done simply enough.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-678) row-level cache
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799719#action_12799719 ]
Hudson commented on CASSANDRA-678:
----------------------------------
Integrated in Cassandra #322 (See [http://hudson.zones.apache.org/hudson/job/Cassandra/322/])
> row-level cache
> ---------------
>
> Key: CASSANDRA-678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-678
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.9
>
> Attachments: 0001-basic-caching.txt, 0002-clean-up-onstart-to-fix-cache-size-calculation.txt, 0003-instrumentation.txt, 0004-make-rowcache-keycache-configurable-per-CF.txt, 0005-combine-SSTable-keycaches-into-one-at-CFS-level.-do-no.txt, 0005-update-cached-rows-in-place-instead-of-invalidating-.patch
>
>
> We have a key cache but that doesn't help mitigate the expensive deserialization of the actual data to return.
> Adding a row-level cache should be fairly simple using a ConcurrentLinkedHashMap<String [key], ColumnFamily> structure. (We will only cache whole rows at a time, since already know how to query on those in-memory. This limits us to CFs full of narrow rows but that is a common enough use case to be worth tackling if it can be done simply enough.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-678) row-level cache
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798565#action_12798565 ]
Jonathan Ellis commented on CASSANDRA-678:
------------------------------------------
not sure what you are seeing. applying those to fresh trunk works fine for me.
> row-level cache
> ---------------
>
> Key: CASSANDRA-678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-678
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.9
>
> Attachments: 0001-basic-caching.txt, 0002-clean-up-onstart-to-fix-cache-size-calculation.txt, 0003-instrumentation.txt, 0004-make-rowcache-keycache-configurable-per-CF.txt, 0005-combine-SSTable-keycaches-into-one-at-CFS-level.-do-no.txt, 0005-update-cached-rows-in-place-instead-of-invalidating-.patch
>
>
> We have a key cache but that doesn't help mitigate the expensive deserialization of the actual data to return.
> Adding a row-level cache should be fairly simple using a ConcurrentLinkedHashMap<String [key], ColumnFamily> structure. (We will only cache whole rows at a time, since already know how to query on those in-memory. This limits us to CFs full of narrow rows but that is a common enough use case to be worth tackling if it can be done simply enough.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CASSANDRA-678) row-level cache
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis resolved CASSANDRA-678.
--------------------------------------
Resolution: Fixed
committed. created CASSANDRA-688 to track refinements
> row-level cache
> ---------------
>
> Key: CASSANDRA-678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-678
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.9
>
> Attachments: 0001-basic-caching.txt, 0002-clean-up-onstart-to-fix-cache-size-calculation.txt, 0003-instrumentation.txt, 0004-make-rowcache-keycache-configurable-per-CF.txt, 0005-combine-SSTable-keycaches-into-one-at-CFS-level.-do-no.txt, 0005-update-cached-rows-in-place-instead-of-invalidating-.patch
>
>
> We have a key cache but that doesn't help mitigate the expensive deserialization of the actual data to return.
> Adding a row-level cache should be fairly simple using a ConcurrentLinkedHashMap<String [key], ColumnFamily> structure. (We will only cache whole rows at a time, since already know how to query on those in-memory. This limits us to CFs full of narrow rows but that is a common enough use case to be worth tackling if it can be done simply enough.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-678) row-level cache
Posted by "Chris Goffinet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798554#action_12798554 ]
Chris Goffinet commented on CASSANDRA-678:
------------------------------------------
I am getting compile errors when I apply 1-4 and 5 (2nd one).
<anonymous org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$1> is not abstract and does not override abstract method rejectedExecution(java.lang.Runnable,org.apache.cassandra.concurrent.ContinuationsExecutor) in org.apache.cassandra.concurrent.RejectedExecutionHandler
DebuggableThreadPoolExecutor.java:34: setRejectedExecutionHandler(java.util.concurrent.RejectedExecutionHandler) in java.util.concurrent.ThreadPoolExecutor cannot be applied to (<anonymous org.apache.cassandra.concurrent.RejectedExecutionHandler>)
[javac] this.setRejectedExecutionHandler(new RejectedExecutionHandler()
> row-level cache
> ---------------
>
> Key: CASSANDRA-678
> URL: https://issues.apache.org/jira/browse/CASSANDRA-678
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.9
>
> Attachments: 0001-basic-caching.txt, 0002-clean-up-onstart-to-fix-cache-size-calculation.txt, 0003-instrumentation.txt, 0004-make-rowcache-keycache-configurable-per-CF.txt, 0005-combine-SSTable-keycaches-into-one-at-CFS-level.-do-no.txt, 0005-update-cached-rows-in-place-instead-of-invalidating-.patch
>
>
> We have a key cache but that doesn't help mitigate the expensive deserialization of the actual data to return.
> Adding a row-level cache should be fairly simple using a ConcurrentLinkedHashMap<String [key], ColumnFamily> structure. (We will only cache whole rows at a time, since already know how to query on those in-memory. This limits us to CFs full of narrow rows but that is a common enough use case to be worth tackling if it can be done simply enough.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.