cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: Worst case #iops to read a row
Date Tue, 13 Apr 2010 19:24:06 GMT
On Tue, Apr 13, 2010 at 1:55 PM, Paul Prescod <prescod@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

Mime
View raw message