It's possible you'll run into compaction headaches. Likely actually.
If you have time-bucketed purge/archives, I'd implement a time bucketing
strategy using rotating tables dedicated to a time period so that when an
entire table is ready for archiving you just snapshot its sstables and then
The important point to consider is whether you are deleting old data or
recently written data. How old/recent depends on your write rate to the
cluster and there's no real formula. Basically you want to avoid deleting a
lot of old data all at once because the tombstones will end up in new
SSTables
t;jens.ran...@tink.se>
> > > Reply-To: "user@cassandra.apache.org" <user@cassandra.apache.org>
> > > Date: Tuesday, March 6, 2018 at 12:34 AM
> > > To: "user@cassandra.apache.org" <user@cassandra.apache.org>
> > > Subject: Re:
r@cassandra.apache.org" <user@cassandra.apache.org>
> *Date: *Tuesday, March 6, 2018 at 12:34 AM
> *To: *"user@cassandra.apache.org" <user@cassandra.apache.org>
> *Subject: *Re: One time major deletion/purge vs periodic deletion
>
>
>
> Sounds lik
ra.apache.org>
Date: Tuesday, March 6, 2018 at 12:34 AM
To: "user@cassandra.apache.org" <user@cassandra.apache.org>
Subject: Re: One time major deletion/purge vs periodic deletion
Sounds like you are using Cassandra as a queue. It's an antibiotic pattern.
What I would do would
Sounds like you are using Cassandra as a queue. It's an antibiotic pattern.
What I would do would be to rely on TTL for removal of data and use the
TWCS compaction strategy to handle removal and you just focus on insertion.
On Tue, Mar 6, 2018, 07:39 Charulata Sharma (charshar)
