On Wed, Jul 7, 2010 at 4:57 PM, Peter Schuller <peter.schul...@infidyne.com> wrote: >> This makes sense, but from what I have seen, read contention vs >> cassandra is a much bigger deal than write contention
(meant "read contention vs compaction") > 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). It might be worth experimenting with posix_fadvise. I don't think implementing our own i/o scheduler or rate-limiter would be as good a use of time (it sounds like you're on that page too). -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
