Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 76176 invoked from network); 2 Feb 2011 17:02:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 2 Feb 2011 17:02:00 -0000 Received: (qmail 24686 invoked by uid 500); 2 Feb 2011 17:01:57 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 24549 invoked by uid 500); 2 Feb 2011 17:01:55 -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 24533 invoked by uid 99); 2 Feb 2011 17:01:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Feb 2011 17:01:55 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jbellis@gmail.com designates 74.125.83.172 as permitted sender) Received: from [74.125.83.172] (HELO mail-pv0-f172.google.com) (74.125.83.172) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Feb 2011 17:01:49 +0000 Received: by pvc21 with SMTP id 21so32539pvc.31 for ; Wed, 02 Feb 2011 09:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=yJz0qwFzsOPkIV/6y/nTyjMbUMA3wrg6wXu12jUrU5o=; b=vdDolbdrTTjjagBgJH+FYPtuk9jg7tGm/x4XR0kAHG+VjQEKFByJf711SQBN6207BH llwy0MFHuIwSBdjiFMfGv8Mf6lkm+MD3PpjOLwj9MlfHJoC1WBZsIted4CjIfJR+koq0 XnLb5RFQDWjHsh8Xs0RXqjx0zO3cQy7M8Iu+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=UoeU4OIP0N/xSNOskgO6LJVZq+r4mcK0uQWP6YGEcm6VnCtTEsaaMrpVQjN0/olL/m vBYZ/NCvdAesT6mLdXE5xP6jD/VG38ZfHC9uKYOY7zRLroRt5tt0rAIcrNwKuof/CkPv VLvxkiv3tkxEdpLDEy3ycHASyeRXdNB1AWCuc= Received: by 10.142.223.16 with SMTP id v16mr830186wfg.174.1296666089327; Wed, 02 Feb 2011 09:01:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.164.19 with HTTP; Wed, 2 Feb 2011 09:01:09 -0800 (PST) In-Reply-To: References: From: Jonathan Ellis Date: Wed, 2 Feb 2011 09:01:09 -0800 Message-ID: Subject: Re: cassandra as session store To: user@cassandra.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sounds like you're seeing the bug in 0.7.0 preventing deletion of non-Data.db files (i.e. your Index.db) post-compaction. This is fixed for 0.7.1. (https://issues.apache.org/jira/browse/CASSANDRA-2059) On Wed, Feb 2, 2011 at 8:15 AM, Omer van der Horst Jansen wrote: > We're using Cassandra as the back end for a home grown session > management system. That system was originally built back in 2005 using > BerkelyDB/Java and a data distribution system that used UDP multicast. > Maintenance was becoming increasingly painful. > > I wrote a prototype replacement service using Cassandra 0.6 but > decided to wait for the availability of official TTL support in 0.7 > before switching over. > > The new system has been running in production now for a little over a > week. My main issue is that Cassandra is using far more disk space > than I expected it to. The vast bulk of disk space seems to be used > for *Index.db files. I'm hoping that the 10-day GCGraceSeconds > interval that kicks in on Friday will help me there. > > Most of our apps that use this service generate their own session > keys. I assume by hashing and salting a user ID and/or calling > something like java.util.UUID.randomUUID(). > > My schema is currently very simple -- there's a single CF containing a > (binary) payload column and a column that indicates whether or not the > data has been compressed. We have a few rogue apps that store > humongous XML documents in the session and compression helps to deal > with that. That's also why memcached wasn't going to work in our > scenario. > > > > On Tue, Feb 1, 2011 at 12:18 PM, Kallin Nagelberg > wrote: >> Hey, >> I am currently investigating Cassandra for storing what are >> effectively web sessions. Our production environment has about 10 high >> end servers behind a load balancer, and we'd like to add distributed >> session support. My main concerns are performance, consistency, and >> the ability to create unique session keys. The last thing we would >> want is users picking up each others sessions. After spending a few >> days investigating Cassandra I'm thinking of creating a single >> keyspace with a single super-column-family. The scf would store a few >> standard columns, and a supercolumn of arbitrary session attributes, >> like: >> >> 0s809sdf8s908sf90s: { >> prop1: x, >> created : timestamp, >> lastAccessed: timestamp, >> prop2: y, >> arbirtraryProperties : { >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 someRandomProperty1:xxyyzz, >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 someRandomProperty2:xxyyzz, >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 someRandomProperty3:xxyyzz >> } >> >> Does this sound like a reasonable use case? We are on a tight timeline >> and I'm currently on the fence about getting something up and running >> like this on a tight timeline. >> >> Thanks, >> -Kal >> > --=20 Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com