The advantages of a DHT often include:
1. bounded size routes
2. load balancing
3. dynamic membership
at the cost of only making very weak consistency guarantees. Typically a DHT
is used for very read heavy workloads - such as CDNs - where the p2p
approach is very scalable. But it's extremely hard to make consistent
updates, because generally to do so you need to make sure a majority of the
replicas of a given item are updated at the same time. ZooKeeper won't scale
as far as a DHT (talking about billions of entries), but it does ensure that
all clients see a linearizable, consistent history on all updates. There is
a fundamental tension between synchronicity of updates and scale.
On 15 March 2010 18:17, Maxime Caron <maxime.ca...@gmail.com> wrote:
> I now understand that ZK is NOT a distributed hash table.
> I only wondered if it where possible to build one with the same level of
> consistency by using ordered updates log like ZK does.
> If it is possible i thing it would be a cool solution to a lot of problem
> out there, not neeserly the same one ZK try to solve.
> Something along the line of Wuala
> On 15 March 2010 21:28, Ted Dunning <ted.dunn...@gmail.com> wrote:
> > I don't think that you have considered the impact of ordered updates
> > On Mon, Mar 15, 2010 at 6:19 PM, Maxime Caron <maxime.ca...@gmail.com
> > >wrote:
> > > So this is all about the "operation log" so if a node is in minority
> > > have more recent committed value this node is in Veto over the other
> > node.
> > >