I'm not sure that "you'd still want to retain the ability to individually control how flushing happens on a per-cf basis in order to cater to different workloads that benefit from different flushing behavior". It seems to me like a good system-wide algorithm that works dynamically, and takes into account moment-by-moment usage, can do this better than a human who is guessing and making decisions on a static basis.
Having said that, my suggestion doesn't really depend so much on having one memtable or many. Rather, it depends on making flushing behavior dependent on system-wide parameters, which reflect the actual physical resources available per node, rather than per-CF parameters (though per-CF tuning can be taken into account, it should be a suggestion that gets overridden by system-wide needs). On Wed, Jan 19, 2011 at 10:48 AM, Peter Schuller < peter.schul...@infidyne.com> wrote: > > Right now there is a one-to-one mapping between memtables and SSTables. > > Instead of that, would it be possible to have one giant memtable for each > > Cassandra instance, with partial flushing to SSTs? > > I think a complication here is that, although I agree things need to > be easier to tweak at least for the common case, I'm pretty sure you'd > still want to retain the ability to individually control how flushing > happens on a per-cf basis in order to cater to different workloads > that benefit from different flushing behavior. > > I suspect the main concern here may be that there is a desire to have > better overal control over how flushing happens and when writes start > blocking, rather than necessarily implying that there can't be more > than one memtable (the ticket Stu posted seems to address one such > means of control). > > -- > / Peter Schuller >
