"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.chir...@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-u...@incubator.apache.org mailing list archive at > Nabble.com. >
