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 <[email protected]> wrote: > On Sun, May 18, 2014 at 10:38 PM, Pramod Biligiri > <[email protected]>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. >
