I don't know what the advantage would be of using this sharding system. I would recommend just going with a simple k->v table as the OP suggested. On Mon Dec 01 2014 at 7:18:51 AM Laing, Michael <michael.la...@nytimes.com> wrote:
> 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----- >> > >
