Sharding lets you use the row cache effectively in 2.1. But like everything, one should test :)
On Mon, Dec 1, 2014 at 1:56 PM, Jonathan Haddad <j...@jonhaddad.com> wrote: > 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----- >>> >> >>
