Well you lose the atomicity and isolation, but in this case that is probably fine
That said, in every interaction I’ve had with static columns, they seem to be an odd duck (e.g. adding or complicating range slices), perhaps worthy of their own code path and sstables. Just food for thought. > On Apr 30, 2015, at 7:13 PM, Jonathan Haddad <j...@jonhaddad.com> wrote: > > 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. >> >>
smime.p7s
Description: S/MIME cryptographic signature
