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.
