Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 095AF10DE6 for ; Mon, 1 Dec 2014 19:33:33 +0000 (UTC) Received: (qmail 99562 invoked by uid 500); 1 Dec 2014 19:33:30 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 99519 invoked by uid 500); 1 Dec 2014 19:33:30 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 99509 invoked by uid 99); 1 Dec 2014 19:33:30 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2014 19:33:30 +0000 X-ASF-Spam-Status: No, hits=-6.5 required=5.0 tests=ENV_AND_HDR_SPF_MATCH,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,USER_IN_DEF_SPF_WL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of michael.laing@nytimes.com designates 209.85.216.169 as permitted sender) Received: from [209.85.216.169] (HELO mail-qc0-f169.google.com) (209.85.216.169) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Dec 2014 19:33:04 +0000 Received: by mail-qc0-f169.google.com with SMTP id w7so8255776qcr.14 for ; Mon, 01 Dec 2014 11:33:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=W7qhR94oewaM0JdVU9bdo8hiJ1SfXDOpOxIK7UrnFCc=; b=dRkegz3hq+YLfAiyq726uANwRWVjCUFn2fvmY3pfRxB/Gf04HfBDL0OXmHZZYNPZi1 3jOAs927Ywt/5TZh9X0wjntFeECevAGbvSGbQqw67NL08+t+e8F5ozbNCI8S2dv8XnZC UW0x/7pQvMFhzNTjh2cmsmfIKWt1vT9PjJHA+ObW0m2+rXg+VhvrmFuPuuS7KXVC/8cy JDSe2VGc6kXGs14WQZRAurzbEJWJylmK30UA2y5wGFK0/SlsQEFsSTMo1CjFNcvvrbAz qL1uB06wmuDytyXBf+6K5uCa5k8pKjBfE9Amflp9B8Db8+HS390fZ4mUAjZ9l0AmB3/V bWTA== X-Gm-Message-State: ALoCoQm58KAiwmg3reCMKFHPygrmxOHiU/17aL73eAUcx1ckMrJpKfJmSB1Q66Y848PURoPboWn8 MIME-Version: 1.0 X-Received: by 10.229.16.197 with SMTP id p5mr87302176qca.3.1417462381732; Mon, 01 Dec 2014 11:33:01 -0800 (PST) Received: by 10.140.85.227 with HTTP; Mon, 1 Dec 2014 11:33:01 -0800 (PST) In-Reply-To: References: <547C21B0.9080203@advancedtelematic.com> <6A19DFA2-0217-482A-AF6B-D6C870E9C7A1@mattnworb.com> <547C8476.2020608@advancedtelematic.com> Date: Mon, 1 Dec 2014 14:33:01 -0500 Message-ID: Subject: Re: Using Cassandra for session tokens From: "Laing, Michael" To: "user@cassandra.apache.org" Content-Type: multipart/alternative; boundary=001a1133e4ccbf103805092cad6d X-Virus-Checked: Checked by ClamAV on apache.org --001a1133e4ccbf103805092cad6d Content-Type: text/plain; charset=UTF-8 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 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 > 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 >> 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 >>> > 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 >>> >> 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----- >>> >> >> --001a1133e4ccbf103805092cad6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 <jon@jonhaddad.com> wrote:
I don't know what the advantage would be of us= ing this sharding system.=C2=A0 I would recommend just going with a simple = k->v table as the OP suggested.=C2=A0

On Mon Dec 01 2014 at 7:18:51 AM Laing,= Michael <michael.laing@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 ne= eded.

= On Mon, Dec 1, 2014 at 10:08 AM, Phil Wise <phil@advancedtelemati= c.com> wrote:
-----BEGIN PG= P 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.=C2=A0 This is a pretty straightforward workloa= d,
> 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 <matt@mattnworb.com>
> wrote:
>
>> This sounds like a good use case for
>> http://www.datastax.com/dev/blog/datetieredcompac= tionstrategy
>>
>>
>> On Dec 1, 2014, at 3:07 AM, Phil Wise
>> <phil@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 36= 00;
>>
>> 4) Perform ~1000 reads/sec like:
>>
>> SELECT * FROM tokens WHERE
>> ID=3D468e0d69-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.=C2=A0 Are there any metr= ics
>> 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<= br> >> 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
=3D6zXb
-----END PGP SIGNATURE-----


--001a1133e4ccbf103805092cad6d--