This sounds like a good use case for http://www.datastax.com/dev/blog/datetieredcompactionstrategy <http://www.datastax.com/dev/blog/datetieredcompactionstrategy>
> On Dec 1, 2014, at 3:07 AM, Phil Wise <p...@advancedtelematic.com> wrote: > > We're considering switching from using Redis to Cassandra to store > short lived (~1 hour) session tokens, in order to reduce the number of > data storage engines we have to manage. > > Can anyone foresee any problems with the following approach: > > 1) Use the TTL functionality in Cassandra to remove old tokens. > > 2) Store the tokens in a table like: > > CREATE TABLE tokens ( > id uuid, > username text, > // (other session information) > PRIMARY KEY (id) > ); > > 3) Perform ~100 writes/sec like: > > INSERT INTO tokens (id, username ) > VALUES (468e0d69-1ebe-4477-8565-00a4cb6fa9f2, 'bob') > USING TTL 3600; > > 4) Perform ~1000 reads/sec like: > > SELECT * FROM tokens > WHERE ID=468e0d69-1ebe-4477-8565-00a4cb6fa9f2 ; > > The tokens will be about 100 bytes each, and we will grant 100 per > second on a small 3 node cluster. Therefore there will be about 360k > tokens alive at any time, with a total size of 36MB before database > overhead. > > My biggest worry at the moment is that this kind of workload will > stress compaction in an unusual way. Are there any metrics I should > keep an eye on to make sure it is working fine? > > I read over the following links, but they mostly talk about DELETE-ing > and tombstones. Am I right in thinking that as soon as a node performs > a compaction then the rows with an expired TTL will be thrown away, > regardless of gc_grace_seconds? > > https://issues.apache.org/jira/browse/CASSANDRA-7534 > > http://www.datastax.com/dev/blog/cassandra-anti-patterns-queues-and-queue-like-datasets > > https://issues.apache.org/jira/browse/CASSANDRA-6654 > > Thank you > > Phil > >
