If you want it in a separate sstable, just use a separate table. There's nothing that warrants making the codebase more complex to accomplish something it already does.
On Thu, Apr 30, 2015 at 5:07 PM graham sanderson <gra...@vast.com> wrote: > Anyone here have an opinion; how realistic would it be to have a separate > memtable/sstable for static columns? > > Begin forwarded message: > > *From: *Jonathan Haddad <j...@jonhaddad.com> > *Subject: **Re: DateTieredCompactionStrategy and static columns* > *Date: *April 30, 2015 at 3:55:46 PM CDT > *To: *u...@cassandra.apache.org > *Reply-To: *u...@cassandra.apache.org > > > I suspect this will kill the benefit of DTCS, but haven't tested it to be > 100% here. > > The benefit of DTCS is that sstables are selected for compaction based on > the age of the data, not their size. When you mix TTL'ed data and non > TTL'ed data, you end up screwing with the "drop the entire SSTable" > optimization. I don't believe this is any different just because you're > mixing in static columns. What I think will happen is you'll end up with > an sstable that's almost entirely TTL'ed with a few static columns that > will never get compacted or dropped. Pretty much the worst scenario I can > think of. > > > > On Thu, Apr 30, 2015 at 11:21 AM graham sanderson <gra...@vast.com> wrote: > >> I have a potential use case I haven’t had a chance to prototype yet, >> which would normally be a good candidate for DTCS (i.e. data delivered in >> order and a fixed TTL), however with every write we’d also be updating some >> static cells (namely a few key/values in a static map<text.text> CQL >> column). There could also be explicit deletes of keys in the static map, >> though that’s not 100% necessary. >> >> Since those columns don’t have TTL, without reading thru the code code >> and/or trying it, I have no idea what effect this has on DTCS (perhaps it >> needs to use separate sstables for static columns). Has anyone tried this. >> If not I eventually will and will report back. > >
