Or use the new user-defined compaction option recently introduced, provided you can determine over which SSTables a partition is spread
On Fri, Feb 9, 2018 at 5:23 PM, Jon Haddad <j...@jonhaddad.com> wrote: > Give this a read through: > > https://github.com/protectwise/cassandra-util/tree/master/deleting- > compaction-strategy > > Basically you write your own logic for how stuff gets forgotten, then you > can recompact every sstable with upgradesstables -a. > > Jon > > > On Feb 9, 2018, at 8:10 AM, Nicolas Guyomar <nicolas.guyo...@gmail.com> > wrote: > > Hi everyone, > > Because of GDPR we really face the need to support “Right to Be Forgotten” > requests => https://gdpr-info.eu/art-17-gdpr/ stating that *"the > controller shall have the obligation to erase personal data without undue > delay"* > > Because I usually meet customers that do not have that much clients, > modeling one partition per client is almost always possible, easing > deletion by partition key. > > Then, appart from triggering a manual compaction on impacted tables using > STCS, I do not see how I can be GDPR compliant. > > I'm kind of surprised not to find any thread on that matter on the ML, do > you guys have any modeling strategy that would make it easier to get rid of > data ? > > Thank you for any given advice > > Nicolas > > >
