Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: domain of tnine@apigee.com designates
 209.85.212.50 as permitted sender)
MIME-Version: 1.0
Date: Fri, 16 Aug 2013 10:43:58 -0700
Message-ID: 
 <CA+yzqf-uNyrXVpFNpgj2EuSDf7_vhV=oEAe+xrF1VyZK8i2p8w@mail.gmail.com>
Subject: Configuring ephemeral only column family
From: Todd Nine <tnine@apigee.com>
To: user@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Hi guys,
  We're using expiring columns as a mean for locking.  All of this
data should be completely ephemeral with only a 5 second ttl per
column.  We're seeing some strangeness where our rows are getting
quite large with tombstones.  We really don't need the commit log, nor
the sstables in our use case.  The data is written via a heartbeat, so
if a lock exists it should always exist in the memtable.  I thought
we'd tweaked our lock's CF enough to stop this from happening.  Below
is what we've done.


1) Set GC Grace to 60 seconds on the Locks/HLocks CF
2) Disable the commit log for the Locks keyspace (only has the 1 keyspace in it)

However, we're still seeing very wide rows in our sstables, which (I'm
assuming) are due to tombstones since I only get < 10 columns back on
a full range scan.  We're trying to eliminate the need to go to disk
completely in the Locks\HLocks CF.    Is there anything further we can
do?

Any help would be greatly appreciated!

Thanks,
Todd