cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DuyHai Doan <doanduy...@gmail.com>
Subject Re: disk space and tombstones
Date Mon, 18 Aug 2014 22:01:59 GMT
"That scheme assumes we have to read counter value before write something to
the timeline. This is what we try to avoid as an anti-pattern."

 Hummm, it looks like there is a need for a tool to take care of the
bucketing switch. I've seen a lot of use cases where people need to do wide
row bucketing but bumps into concurrency issues for keeping the "state" of
the current partition. Managing it client-side at application level can be
a nightmare.


On Mon, Aug 18, 2014 at 1:25 PM, clslrns <vitaly.chirkov@flysoft.ru> wrote:

> That scheme assumes we have to read counter value before write something to
> the timeline. This is what we try to avoid as an anti-pattern.
>
> By the way, is there any difference between slice trimming of one row and
> sharding pattern in terms of compaction? AFAIK, delete with timestamp by
> primary key also creates single row tombstone.
>
>
>
> --
> View this message in context:
> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/disk-space-and-tombstones-tp7596356p7596367.html
> Sent from the cassandra-user@incubator.apache.org mailing list archive at
> Nabble.com.
>

Mime
View raw message