cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jeske <dav...@gmail.com>
Subject Re: Programmatically allow only one out of two types of rows in a CF to enter the CACHE
Date Sun, 30 Oct 2011 17:42:01 GMT
If your summary data is frequently accessed, you will probably be best off
storing the two sets of data separately (either in separate column families
or with different key-prefixes). This will give you the greatest
cache-locality for your summary data, which you say is popular. If your
summary data is very well cached, then it won't matter that it's might
require two disk-seeks to get summary+details, because your summary data is
usually in cache anyhow.

If you want a more specific recommendation that that, we'd need to see
answers to the following questions:

(a) how big is the summary data (total, per row)? (average, max)
(b) how big is the detail data (total, per row)?     (average, max)
(b) what is the read/write traffic to the summary data? ..detail data?

A side note about caches... IMO, you're better off getting the cache
behavior you want through physical ordering than through more explicit
caching. This is because most modern databases (cassandra included) go
through the OS buffer cache already, and there is some amount of
duplicating of data involved in trying to application cache data. If your
application cache hitrate is very high (90%+) this can work out, but if
it's lower (50%) it can sometimes have poor effects on the cache efficiency
of both the application cache and OS buffer cache (because of data being
duplicated in both caches).

Mime
View raw message