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/08/21 14:37:16 UTC

[jira] Updated: (CASSANDRA-1417) add cache save/load

     [ https://issues.apache.org/jira/browse/CASSANDRA-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Ellis updated CASSANDRA-1417:
--------------------------------------

    Description: 
Since mixing 0.7 nodes with 0.6 is looking increasingly unlikely to be supported because of the deep changes to the Thrift API, we should allow saving out the 0.6 cache and loading it on startup so that we don't inflict the pain of an entire cluster of cold cache on upgraders.

The cache format should just be a list of row keys.  Loading it is as simple as calling getColumnFamily (with a zero-column predicate) on each row, for row cache.

Key cache is more complicated, but only a little.  First is that you have to de-duplicate the row keys from multiple sstables.  (Saving which sstable version it's associated with is less useful, since that will be obsoleted by compaction.)  Second is that we don't need to actually read any row data, we just need to go through the index locator part of the read path (getPosition).

  was:
Since mixing 0.7 nodes with 0.6 is looking increasingly unlikely to be supported because of the deep changes to Thrift, we should allow saving out the 0.6 cache and loading it on startup so that we don't inflict the pain of an entire cluster of cold cache on upgraders.

The cache format should just be a list of row keys.  Loading it is as simple as calling getColumnFamily (with a zero-column predicate) on each row, for row cache.

Key cache is more complicated, but only a little.  First is that you have to de-duplicate the row keys from multiple sstables.  (Saving which sstable version it's associated with is less useful, since that will be obsoleted by compaction.)  Second is that we don't need to actually read any row data, we just need to go through the index locator part of the read path (getPosition).


> add cache save/load
> -------------------
>
>                 Key: CASSANDRA-1417
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1417
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Jonathan Ellis
>             Fix For: 0.6.6, 0.7 beta 2
>
>
> Since mixing 0.7 nodes with 0.6 is looking increasingly unlikely to be supported because of the deep changes to the Thrift API, we should allow saving out the 0.6 cache and loading it on startup so that we don't inflict the pain of an entire cluster of cold cache on upgraders.
> The cache format should just be a list of row keys.  Loading it is as simple as calling getColumnFamily (with a zero-column predicate) on each row, for row cache.
> Key cache is more complicated, but only a little.  First is that you have to de-duplicate the row keys from multiple sstables.  (Saving which sstable version it's associated with is less useful, since that will be obsoleted by compaction.)  Second is that we don't need to actually read any row data, we just need to go through the index locator part of the read path (getPosition).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.