incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Dusbabek <gdusba...@gmail.com>
Subject Re: Regarding Cassandra Scalability
Date Mon, 19 Apr 2010 13:49:27 GMT
On Sun, Apr 18, 2010 at 11:14, dir dir <sikerasakti@gmail.com> 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
problem.

Regards,

Gary.

> Thank You.
>
> Dir.
>

Mime
View raw message