cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Yaskevich (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-3143) Global caches (key/row)
Date Wed, 14 Dec 2011 13:59:30 GMT

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

Pavel Yaskevich commented on CASSANDRA-3143:
--------------------------------------------

bq. I don't think CacheService.reloadKeyCache works correctly. It only populate the cache
with fake values that won't get updated unless you reload the sstables, which has no reason
to happen. I'm fine removing the key cache reloading altogether, but as an alternative, why
not save the value of the key cache too? The thing is, I'm not very comfortable with the current
'two phase' key cache loading: if we ever have a bug in the SSTReader.load method, the actual
pre-loading with -1 values will be harmful, which seems unnecessarily fragile. Saving the
values on disk would avoid that.

I agree, it just thought that it's valuable to have that reload around. I'm going to remove
key cache reload and save values to avoid 'two phrase' key cache loading.
 
bq. In CFS, it's probably faster/simpler to use metadata.cfId rather than Schema.instance.getId(table.name,
this.columnFamily)

This would mean that we will be caching even secondary index CFs which is, as was said, is
not desired. 

bq. In CacheService, calling scheduleSaving with -1 as second argument would be slightly faster
than using Integer.MAX_VALUE.

This could have even worse performance because it will change semantics and call hotKeySet
method on the ICache, for CLHM this is _not_ O(1) operation as doc for "descendingKeySetWithLimit(int
limit);" says.

bq. I wonder if the reduce cache capacity thing still makes sense after this patch?

I think it does because it also helps to reclaim some memory when system is starving.


                
> Global caches (key/row)
> -----------------------
>
>                 Key: CASSANDRA-3143
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3143
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Pavel Yaskevich
>            Assignee: Pavel Yaskevich
>            Priority: Minor
>              Labels: Core
>             Fix For: 1.1
>
>         Attachments: 0001-global-key-cache.patch, 0002-global-row-cache-and-ASC.readSaved-changed-to-abstra.patch,
0003-CacheServiceMBean-and-correct-key-cache-loading.patch, 0004-key-row-cache-tests-and-tweaks.patch,
0005-cleanup-of-the-CFMetaData-and-thrift-avro-CfDef-and-.patch, 0006-row-key-cache-improvements-according-to-Sylvain-s-co.patch
>
>
> Caches are difficult to configure well as ColumnFamilies are added, similar to how memtables
were difficult pre-CASSANDRA-2006.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message