This may be true for monster clusters being supported by a ZK cluster or for
data-intensive operations like high throughput queuing, but many
applications of ZK are incredibly low volume.

For instance, with Katta, there is a read-modify-write when a search engine
comes up, when a shard is assigned or loaded, a dozen or so when an index is
added and a few when the master fails.  None of these operations occurs in
practice even once an hour.

I also log machine state across lots of machines once every few seconds
(partly to give ZK something to do).  That results in dozens (at most) of
transactions per second.

I think that a huge proportion of Zk clusters are going to have transactions
per day rather than kilo transactions per second.  At these rates, all you
have to worry about is simultaneous failures ... make sure that the ZK
cluster members are on separate power supplies and network switches.  Beyond
that, everything is over-kill.  You could run on a cluster of iPhones and
still be happy with performance.

On Fri, Jul 17, 2009 at 1:38 PM, Benjamin Reed <> wrote:

> the main thing is that you use dedicated zk machines (with a dedicated disk
> for logging). once you have that in place, watch the load on your cluster,
> as long as you aren't saturating the cluster you should share.

Ted Dunning, CTO

Reply via email to