zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pramod Biligiri <pramodbilig...@gmail.com>
Subject Re: Partitioned Zookeeper
Date Fri, 23 May 2014 03:18:43 GMT
Hi Ted,
Thanks for the details :) I'm looking at the code now and trying some
changes. Will keep you posted in any case something positive turns out.

Pramod


On Sun, May 18, 2014 at 11:31 PM, Ted Dunning <ted.dunning@gmail.com> wrote:

> On Sun, May 18, 2014 at 10:38 PM, Pramod Biligiri
> <pramodbiligiri@gmail.com>wrote:
>
> > Do you see any other problems with the approach I'm taking. If we see any
> > gains from it, we can look at the tricky issues next.
> >
>
> No.  The idea of partitioning ZK has come up often and something roughly
> like what you suggest has always come up.
>
> Your suggestion to partition on the top-level of the namespace is easy to
> do, but will not give application transparent speedup.   Essentially what
> will happen is that applications will tend to push their hierarchies down
> one level.  This will result in something similar to the current system
> where you could just as well run multiple ZK clusters in any case.  IF a
> single application is the only one that is stressing ZK, you will get no
> gain from your approach.
>
> If you really want speedup that is transparent to the applications, then I
> would suggest that you use something like the zkid or a hash of the path
> name for determining the partition.  That is much more likely to give you
> speed up without application modification.
>
> One thing that could be a problem with such any such federation approach is
> that you are likely to be losing the ordering guarantees that ZK provides.
>  Since clients may see delayed views of the name space and since the delay
> may vary depending on which part of the namespace partition you are looking
> at, you can't force ordering any more.  THis is an especially serious
> problem since these ordering guarantees are a big part of what ZK is all
> about in the first place.  Restoring these guarantees while maintaining
> performance is likely to be quite difficult.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message