Predefined configurations make most sense to me too. My personal preference is to use a variation of the mechanism for defining memtable configurations <https://github.com/apache/cassandra/blob/trunk/conf/cassandra.yaml#L787>, where the details of each are laid out explicitly in the yaml, and the schema selects the one to use.
> Without reading the code, the only other one that comes to mind is single sstable upleveling in LCS. There is no need indeed to perform single-sstable uplevelling, because the level is a derived feature for an sstable. In other words, when the fanout is breached, the sstable in question is already understood to belong to the next level. This is how levelled compaction works in UCS. When an sstable becomes too dense for its level, the strategy sees it to belong on the next level; if there is already data for the same interval on that level, a compaction needs to take place, otherwise you get the effect of a "single sstable uplevel" without doing anything. > LCS changes other default table params like bloomfilter FP ratio, which UCS doesn't do Results from Academia show that there is value in finer bloomfilter control by the compaction strategy (making it a function of the compaction parameters as well as the level/density); this is very doable but it needs quite a bit of experimentation because I'm not sure the results necessarily translate to wide partition stores. Regards, Branimir On Tue, Dec 10, 2024 at 12:47 AM Benedict <bened...@apache.org> wrote: > That should never need to happen in UCS as far as I understand. Levels > should be defined by the properties of the sstable, not by assignment, so > all sstables should be placed in the correct bucket on creation by > definition. I haven’t read the code though, so there might be some > impediment to that platonic ideal. Branimir can confirm, but this *should* > naturally fall out of the formalisation. > > > On 9 Dec 2024, at 14:27, Jeff Jirsa <jji...@apache.org> wrote: > > > > > > > > On 2024/12/09 17:33:09 Benedict wrote: > >> I think it would make sense to support overriding the default FP in the > UCS parameters, so we can treat it as a direct replacement. Desiree FP is > directly related to sstable overlaps after all. > >> > >> Can you think of any other usability gaps like this? > > > > Without reading the code, the only other one that comes to mind is > single sstable upleveling in LCS. > > > > (The UCS docs talk about trying to forecast when to push sstables one > extra level, but we saw in it's often the case that you can breach the > fanout without any real overlaps, and simply re-leveling via metadata > mutation could maintain that invariant easier than rewriting the whole > table. It's possible UCS is doing this, too, but again, not obvious in the > docs.) > -- Branimir Lambov e. branimir.lam...@datastax.com w. www.datastax.com
