Since the session tokens are random, perhaps computing a shard from each one and using it as the partition key would be a good idea.
I would also use uuid v1 to get ordering. With such a small amount of data, only a few shards would be needed. On Mon, Dec 1, 2014 at 10:08 AM, Phil Wise <p...@advancedtelematic.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The session will be written once at create time, and never modified > after that. Will that affect things? > > Thank you > > - -Phil > > On 01.12.2014 15:58, Jonathan Haddad wrote: > > I don't think DateTiered will help here, since there's no > > clustering key defined. This is a pretty straightforward workload, > > I've done something similar. > > > > Are you overwriting the session on every request? Or just writing > > it once? > > > > On Mon Dec 01 2014 at 6:45:14 AM Matt Brown <m...@mattnworb.com> > > wrote: > > > >> This sounds like a good use case for > >> 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 > >> > >> > >> > >> > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQIcBAEBAgAGBQJUfIR1AAoJEAvGtrO88FBAnpAP/0RCdwCy4Wi0ogz24SRKpCu0 > c/i6O2HBTinl2RXLoH9xMOT8kXJ82P9tVDeKjLQAZYnBgRwF7Fcbvd40GPf+5aaj > aU1TkU4jLnDCeFTwG/vx+TIfZEE27nppsECLtfmnzJEl/4yZwAG3Dy+VkuqBurMu > J6If9bMnseEgvF1onmA7ZLygJq44tlgOGyHT0WdYRX7CwAE6HeyxMC38ArarRU37 > dfGhsttBMqdxHreKE0CqRZZ67iT+KixGoUeCvZUnTvOLTsrEWO17yTezQDamAee0 > jIsVfgKqqhoiKeAj99J75rcsIT3WAbS23MV1s92AQXYkpR1KmHTB6KvUjH2AQBew > 9xwdDSg/eVsdQNkGbtSJ2cNPnFuBBZv2kzW5PVyQ625bMHNAF2GE9rLIKddMUbNQ > LiwOPAJDWBJeZnJYj3cncdfC2Jw1H4rlV0k6BHwdzZUrEdbvUKlHtyl8/ZsZnJHs > SrPsiYQa0NI6C+faAFqzBEyLhsWdJL3ygNZTo4CW3I8z+yYEyzZtmKPDmHdVzK/M > M8GlaRYw1t7OY81VBXKcmPyr5Omti7wtkffC6bhopsPCm7ATSq2r46z8OFlkUdJl > wcTMJM0E6gZtiMIr3D+WbOTzI5kPX6x4UB3ec3xq6+GIObPwioVAJf3ADmIK4iHT > G106NwdUnag5XlnbwgMX > =6zXb > -----END PGP SIGNATURE----- >
