cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Dusbabek <>
Subject Re: Regarding Cassandra Scalability
Date Mon, 19 Apr 2010 13:49:27 GMT
On Sun, Apr 18, 2010 at 11:14, dir dir <> wrote:
> Hi Gary,
>>The main reason is that the compaction operation (removing deleted
>>values) currently requires that an entire row be read into memory.
> Thank you for your explanation. But I still do not understand what do you
> mean.

When you delete a column in cassandra, the data is not really deleted.
 Instead a flag is turned on indicating the column is no longer valid
(we call it a 'tombstone').  During compaction the column family is
scanned and the tombstones are truly deleted.

> in my opinion, Actually the row contents must fit in available memory.
> if row contents are not fit in available memory, our software will raise
> exception out of memory. since it is true( "the row contents must fit in
> available memory"),
> then why you said that is a problem which it (Cassandra) cannot solved??

It was not correct of me to say it is a problem that cassandra cannot
solve.  Memory-efficient compactions will be addressed.

> You say: "compaction operation requires that entire row be read into memory"
> whether this is a problem of "out of memory"??  When we need to perform
> compaction operation?? In what situation we shall perform compaction
> operation??

You will need to address the large rows yourself (consider breaking
them up).  You can identify these rows during compaction by setting
RowWarningThresholdInMB in storage-conf.xml.  When a big enough row
comes along, it is logged so you can go back later and address the



> Thank You.
> Dir.

View raw message