Well I just found this:


which explains a ton...  It looks like this particular Column Family will grow infinitely (it's just one row with a column per migration), so if I'm pounding on my Cassandra node with CREATE/DROP activity, I'm going to make VERY wide row.

That tells me enough to say "don't do that!"  :-)


On Tue, Apr 3, 2012 at 6:00 PM, David Leimbach <leimy2k@gmail.com> wrote:
I've been trying to understand the overhead of create/drop keyspace on Cassandra 1.0.8.  It's not free, especially when I've managed to drive up the LiveDiskSpaceUsed for the Migrations CF in the "system" keyspace up to over 12 MB of disk.

I've tried doing "nodetool -h localhost repair system" and other nodetool commands to try to compact the SSTables involved with it, but it never wants to let go of that slowly growing space.

The Cassandra node in question is in a ring of size 1.

Other than clobbering my data directory, how do I get my space back?  Is it natural for this to grow seemingly infinitely (even though it's pretty small increments), or did I find a bug?

The reason I ask is I need to run unit tests in a shared developer infrastructure with Cassandra, and we were having a little trouble with TRUNCATE on column families, but that might have been environmental (I've not looked deeply into it).

Which is less expensive?  Create/Drop, or Truncate?  I don't expect Truncate to swell the Migration Column Family because it tracks (seemingly) schema changes.