[
https://issues.apache.org/jira/browse/CASSANDRA-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Yaskevich updated CASSANDRA-3143:
---------------------------------------
Attachment: 0006-row-key-cache-improvements-according-to-Sylvain-s-co.patch
0005-cleanup-of-the-CFMetaData-and-thrift-avro-CfDef-and-.patch
0004-key-row-cache-tests-and-tweaks.patch
0003-CacheServiceMBean-and-correct-key-cache-loading.patch
0002-global-row-cache-and-ASC.readSaved-changed-to-abstra.patch
0001-global-key-cache.patch
bq. Preceding point apart, we would at least need a way to deactivate row
caching on a per-cf basis. We may also want that for key cache, though this
seems less critical. My initial idea would be to either have a boolean flag if
we only want to allow disabling row cache, or some multi-value caches option
that could be "none", "key_only", "row_only" or "all".
This is going to be moved to the separate task.
bq. For the Row cache key, we should really use the cfId instead of table and
cfname.
Secondary index cfs do not register with Schema.load so they don't have a cfId.
bq. I think it would be worth factoring what can be of readSaved. In
particular, we could create a KeyCacheKey (like RowCacheKey and that would
really just be the usual pair of (Descriptor, DecoratedKey), have it share an
interface with RowCacheKey (serialize and deserialize basically) and use that.
Done.
bq. Putting the clone of the key into the constructor of RowCacheKey is
inefficient, we don't care about cloning when we invalidate or query the cache
(nor when we deserialize RowCacheKeys).
Fixed.
bq. nit: not fond of declaration like public abstract Set<?> readSaved(),
making it harder to know what the method returns just to save a few characters.
Changed to Set<? extends CacheKey> as both key and row cache key now share the
same interface - CacheKey.
bq. I believe the CacheService.instance will load the CacheService that will
trigger an exception if there is a problem, not set the instance to null. So in
particular, this message will never be written. That code is moved by the 4th
patch but the problem remains I think (note that we do want to make sure
CacheService get loaded quickly to throw an exception if we have an
initialization problem, it's just not the right way I believe).
This is the same as done in the StorageService constructor to make sure that
StreamingService.instance is available when needed, because static fields are
initialized on the first demand.
bq. I'm not super fond of that key cache preloading. If the key cache save is
outdated, we'll have a bunch of uselessly preloaded stuff (not a huge deal
but...). Maybe we could keep doing as before and just save the set of keys for
each column family instead. That would needs buffering of the keys during the
cache save though, but not sure it's such a huge deal and it would reduce the
size of the saved cache quite a bit.
The idea was to rely on cache LRU policy and save an actual global state of the
cache to minimize cache's specific configuration per cf...
bq. In CacheService, setRowCacheSavePeriodInSecond directly schedule the saving
to the new value, but the get method grabs the value from DatabaseDescriptor,
so it will always return the initially set value, which is not what we want. I
think we should keep the Integer that were previously in CFS (but I'm fine
moving them to CacheService).
Fixed.
bq. Why does the getRowCacheKeysToSave() option disappeared?
Because we don't control that anymore, rely on cache LRU policy instead.
bq. The patch does the following change: " + int newCapacity = (int)
(DatabaseDescriptor.getReduceCacheCapacityTo() * getCapacity());" ....
This was unclear at first but fixed to use "weightedSize()" instead of
"getCapacity()" now.
bq. I really think that making DecoratedKey equals method deal with RowCacheKey
is asking for trouble. Not sure why it would be useful either?
Fixed.
Rebased with the latest trunk (last commit
f76e9aeaed3e73bcfaf6bccd62f9f02f31b09960)
> 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
