3 ms·
That is what a distributed has table is. And the values and keys aren't lost--there's just some confusion over what the keys and values are. The keys and value
by paddyforan 14y ago
That is what a distributed has table is. And the values and keys aren't lost--there's just some confusion over what the keys and values are.
The keys and values, at least in Pastry's case, are the NodeID and the metadata about the Node, respectively. According to my understanding, at least. I had to learn a lot to implement this, so I would not claim to be an expert on distributed hash tables by any stretch of the imagination.
- StavrosK 14y agoHmm, so is the use case a distributed task queue? If so, why not use a consistent hash ring (http://www.martinbroadhurst.com/Consistent-Hash-Ring.html http://www.martinbroadhurst.com/Consistent-Hash-Ring.html), or just pick a server at random? I'm afraid I'm missing the point entirely :/ Is it about maintaining a consistent list of member workers?
- paddyforan 14y agoA consistent hash ring is a similar concept, I think. We're quickly approaching the out-of-my-depth line, though. It's about maintaining the property that you can route information from many different places and have that information end in a consistent place, no matter where it's sent from. And, assuming the consistent place doesn't go offline, a large number of servers can fall over without warning before that property is changed. It's about making discovery of nodes in your cluster reliable, and passing information in between them. The use cases for that are many, and each has their own nuances, which is why this is so confusing and hard to talk about.
- StavrosK 14y agoRight. It sounds like one of those problems that can be solved in many ways, and a DHT is designed to deal with a specific constraint. Thanks for the details!