On Tue, Apr 13, 2010 at 1:55 PM, Paul Prescod <pres...@gmail.com> wrote: > What do you mean by "bad practice"? The document above implies that it > is nearly impossible. It implies that you will have between 1 and 4 > SSTables. Does the administrator have a choice in this matter?
You can tune the 4 number via JMX (primarily so you can disable compaction entirely during bulk loads), but it's not tuneable in the configuration file because there's no value to messing with it other than temporarily. > I am probably being totally naive, but is the answer to the question > "worst iops on read" just: > > 3 reads per SSTable * 4 SStables * ReplicationFactor ? > > = 3 * 4 * 3 = 36? Leaving aside whether multiplying by RF is answering the "right" question, the answer is "close, but not quite," because - sstables are only merged with similarly-sized sstables, so you will have 3 of size X (your memtable flush size), 3 of size 2X, 3 of size 4X, and so forth. (This is one reason why increasing your memtable size, within reason, is a good idea.) - you can write to the system faster than compaction can keep up (increasing memtable size also helps with this), so "worst case" for reads depends on how stubborn you are about this. sane ops teams will monitor the compaction mbean and take action (add capacity or throttle writes) if the pending compaction count starts to grow out of hand. -Jonathan
