Probably a lot of work but it would be incredibly useful for vnodes if flushing was range aware (to be used with RangeAwareCompactionStrategy). The writers are already range aware for JBOD, but that's not terribly valuable ATM.
On 20 February 2018 at 21:57, Jeff Jirsa <jji...@gmail.com> wrote: > There are some arguments to be made that the flush should consider > compaction strategy - would allow a bug flush to respect LCS filesizes or > break into smaller pieces to try to minimize range overlaps going from l0 > into l1, for example. > > I have no idea how much work would be involved, but may be worthwhile. > > > -- > Jeff Jirsa > > > On Feb 20, 2018, at 1:26 PM, Jon Haddad <j...@jonhaddad.com> wrote: > > The file format is independent from compaction. A compaction strategy > only selects sstables to be compacted, that’s it’s only job. It could have > side effects, like generating other files, but any decent compaction > strategy will account for the fact that those other files don’t exist. > > I wrote a blog post a few months ago going over some of the nuance of > compaction you mind find informative: http://thelastpickle.com/blog/2017/ > 03/16/compaction-nuance.html > > This is also the wrong mailing list, please direct future user questions > to the user list. The dev list is for development of Cassandra itself. > > Jon > > On Feb 20, 2018, at 1:10 PM, Carl Mueller <carl.muel...@smartthings.com> > wrote: > > When memtables/CommitLogs are flushed to disk/sstable, does the sstable go > through sstable organization specific to each compaction strategy, or is > the sstable creation the same for all compactionstrats and it is up to the > compaction strategy to recompact the sstable if desired? > > >
