DuyHai Doan wrote
> it looks like there is a need for a tool to take care of the bucketing
> switch
But I still can't understand why bucketing should be better than `DELETE row
USING TIMESTAMP`. Looks like the only source of truth about this topic is
the source code of Cassa.
--
View this mes
"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 bucketin
2014-08-18 13:25 GMT+02:00 clslrns :
> 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.
You can work around the read counter before read, but I agree that it would
be much better if disk space was reclaim
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
what about you timeline versioning?
every time a timeline has more than x columns, you bump its version (which
should be part of its row key) and start writing on that one (though this
will make your app substantially more complex).
AFAIK reclaiming disk space for delete rows is far easier than rec
No, it is in seconds
--
View this message in context:
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/disk-space-and-tombstones-tp7596356p7596363.html
Sent from the cassandra-u...@incubator.apache.org mailing list archive at
Nabble.com.
In our case major compaction (using sstableresetlevel) will take 15 days for
15 nodes plus trimming time. So it turns into never ending maintenance mode.
--
View this message in context:
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/disk-space-and-tombstones-tp7596356p7596361
I was exactly in your same situation, I could only reclaim disk space for
trimmed data this way:
very low gc_grace + size tiered compaction + slice timestamp deletes +
major compaction
2014-08-18 12:06 GMT+02:00 Rahul Neelakantan :
> Is that GC_grace 300 days?
>
> Rahul Neelakantan
>
> > On Aug
Is that GC_grace 300 days?
Rahul Neelakantan
> On Aug 18, 2014, at 5:51 AM, Dimetrio wrote:
>
> In our Twitter-like application users have their own timelines with news from
> subscriptions. To populate timelines we're using fanout on write. But we
> forced to trim it to keep free disk space un
