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 scode@scode.org designates
 74.125.82.44 as permitted sender)
MIME-Version: 1.0
Sender: scode@scode.org
In-Reply-To: <4EBC7AB8.7030105@bnl.gov>
References: <1302618388.3794.34.camel@mierdi-laptop>
	<4DA47CCD.50509@panasiangroup.com>
	<1302630144.1732.2.camel@Avalon>
	<4DA491EE.6010500@panasiangroup.com>
	<4EB84C9F.8040208@bnl.gov>
	<CAKkz8Q03bk1=moG__noMBV6zUAo+9i7ocLMQesWceUU9voc6=g@mail.gmail.com>
	<4EBC7AB8.7030105@bnl.gov>
Date: Sun, 13 Nov 2011 16:22:13 -0800
Message-ID: 
 <CAO5xsd2DKqz7dv1zpp3G3g3wvquu5YiuD7oNhzjWUNqwjvCRgw@mail.gmail.com>
Subject: Re: Mass deletion -- slowing down
From: Peter Schuller <peter.schuller@infidyne.com>
To: user@cassandra.apache.org, potekhin@bnl.gov
Content-Type: text/plain; charset=UTF-8

Deletions in Cassandra imply the use of tombstones (see
http://wiki.apache.org/cassandra/DistributedDeletes) and under some
circumstances reads can turn O(n) with respect to the amount of
columns deleted, depending. It sounds like this is what you're seeing.

For example, suppose you're inserting a range of columns into a row,
deleting it, and inserting another non-overlapping subsequent range.
Repeat that a bunch of times. In terms of what's stored in Cassandra
for the row you now have:

  tomb
  tomb
  tomb
  tomb
  ....
   actual data

If you then do something like a slice on that row with the end-points
being such that they include all the tombstones, Cassandra essentially
has to read through and process all those tombstones (for the
PostgreSQL aware: this is similar to the effect you can get if
implementing e.g. a FIFO queue, where MIN(pos) turns O(n) with respect
to the number of deleted entries until the last vacuum - improved in
modern versions)).


-- 
/ Peter Schuller (@scode, http://worldmodscode.wordpress.com)