> This makes sense, but from what I have seen, read contention vs > cassandra is a much bigger deal than write contention (unless you > don't have a separate device for your commitlog, but optimizing for > that case isn't one of our goals).
I am not really concerned with write performance, but rather with writes affecting reads. Cache eviction due to streaming writes has the obvious effect on hit ratio on reads, and in general large sustained writes tend to very negatively affect read latency (and typically in a bursty fashion). So; the idea was to specifically optimize to try to make reads be minimally affected by writes (in the sense of the background compaction eventually resulting from those writes). Understood and agreed about the commit log (though as long as write bursts are within what a battery-backed RAID controller can keep in its cache I'd expect it to potentially work pretty well without separation, if you do have such a setup). -- / Peter Schuller
