Vector Clock easy and hard

Document directory

• Why vector clocks are easy
• Why vector clocks are hard

Why vector clocks are easy

Http://basho.com/blog/technical/2010/01/29/why-vector-clocks-are-easy/

Vector clocks by example

Through the following routine examples to help you understand vector clock, you will find that this algorithm is not complex.
You want to plan the day of dinner next week? How can we achieve eventual consistency?
Of course, this problem can also be solved using paxos.
Another idea is to use the vector clock solution.

Alice, Ben, Cathy, and Dave are planning to meet next week for dinner.

The planning startsAliceSuggesting they meet onWednesday.

Later,DaveDiscuss alternativesCathy, And they decide onThursdayInstead.

DaveAlso exchanges emailBen, And they decide onTuesday.

When Alice pings everyone again to find out whether they still agree with her Wednesday suggestion, she getsMixed messages:

Cathy claims to have settled on Thursday with Dave, and Ben claims to have settled on Tuesday with Dave.

Dave can't be reached, and soNo one is able to determine the order in which these communications happened, And so none of Alice, Ben, and Cathy know whether Tuesday or Thursday is the correct choice.

The story changes, but the end result is always the same: You ask two people for the latest version of a piece of information, and they reply with two different answers, and there's no way to tell which one isReallyThe most recent.

 

StartAlice'sInitial message: "Let's meet Wednesday ,"

date = Wednesdayvclock = Alice:1

BenSuggests Tuesday:

date = Tuesdayvclock = Alice:1, Ben:1

DaveReplies, confirming Tuesday:

date = Tuesdayvclock = Alice:1, Ben:1, Dave:1

NowCathyGets into the act, suggesting Thursday:

date = Thursdayvclock = Alice:1, Cathy:1

DaveHas two conflicting objects:

date = Tuesdayvclock = Alice:1, Ben:1, Dave:1

And

date = Thursdayvclock = Alice:1, Cathy:1

Dave can tell that these versions are in conflict, because neither vclock "descends" from the other. Luckily, Dave's a reasonable guy, and choosesThursday. Dave also created a vector clock that is a successor to all previusly-seen vector clocks. He emails this value back to Cathy.

date = Thursdayvclock = Alice:1, Ben:1, Cathy:1, Dave:2

So now whenAliceAsks Ben and Cathy for the latest demo-, the replies she bought es are, from Ben:

date = Tuesdayvclock = Alice:1, Ben:1, Dave:1

And from Cathy:

date = Thursdayvclock = Alice:1, Ben:1, Cathy:1, Dave:2

 

From this, she can tell that Dave intended his corresponsed with Cathy to override the demo-he made with Ben. all Alice has to do is show Ben the vector clock from Cathy's message, and Ben will know that he has been overruled.

That worked out pretty well.

The figure above shows that 'why vector clocks are easy'

 

Why vector clocks are hard

Http://basho.com/blog/technical/2010/04/05/why-vector-clocks-are-hard/

However, in actual implementation of this system, there are still many problems that need to be solved. From the implementation perspective, 'Why vector clocks are hard'

The most difficult question is, what is used as an actor? And how to save a vclocks as it grows over time?

1. What an actor is(I. e. Where the incrementing and resolution is, and what parties get their own field in the vector)

2. How to keep vclocks from growing without bound over time.

In this example the parties that actually proposed changes ("clients") were the actors in the vector clocks. this is the model that vector clocks are designed for and work well with, but it has a drawback. the width of the vectors will grow proportionally with the number of clients. in a group of friends deciding when to have dinner this isn't a problem, but in a distributed storage system the number of clients over time can be large. once the vector clocks get that large, they not only take up more space in disk and Ram but also take longer to compute comparisons over.

In this case, we will talk about what to choose as an actor. The above example uses client as an actor, but the problem is that in a distributed environment, the number of clients may be very large, this has serious efficiency problems.

One straightforward idea isMake the serversHandling Client requests be"Actors", Instead of representing the clients directly. since any given system usually has a known bounded number of servers over time and also usually has less servers than clients, this serves to reduce and cap the size of the vclocks

Let's think through the same example, but with that difference, to see how it goes. we'll assume that a 2-server Distributed System is coordinating the communication, with clients evenly distributed among them.

In the following example, we try to use server as an actor to avoid excessive client problems.

Alice and Dave happen to get server X, and Ben and Cathy get server y.

We're fine through the first few steps:

The only real difference so far is that each update increments a vector clock field named for the client's chosen server instead of the client itself. this will mean that the number of fields needed won't grow without bound; it will be the same as the number of servers. this is the desired effect of the change.

We run into trouble, though, when Cathy sends her update:

In the original example, this is where a conflict was created. Dave sorted out the conflict, and everything was fine.

With our new strategy, though, something else happened. ben and Cathy were both modifying from the same original object. since we used their server ID instead of their own name to identify the change, Cathy's message has the same vector clock as Ben's! This means that Dave's message (responding to Ben) appears to be a simple successor to Cathy's... and we lose her data silently!

The problem with using server as actor is that some data will be lost because Cathy and ben both operate on y, so for the system, there is no difference between Cathy and Ben in y, so when Dave confirm Ben, the vector is X2, Y1, and then receives Cathy X1 and Y1, it will be deemed as expired data and will be automatically lost. in this way, the above coordination problem cannot be solved, so this simple solution is not feasible.

The reasons for this problem are as follows,

For vector clocks to have their desired effect without causing accidents such as this, the elements represented byFields in the vclockMust beReal units of concurrency. In a case like this little example or a distributed storage system, that means client identifiers, not server-based ones.

Server is not a real concurrency unit, but it is unreasonable for you to take it as an actor.

 

Just lose a little information and everything will be fine

If we use client identifiers, we're back in the situation where vector clocks will grow and grow as more clients use a system over time.

The solution most people end up with is"Prune"Their Vector clocks as they grow.

This is doneAdding a timestamp to each field, And updating it to the current local time whenever that field is incremented. This timestamp is never used for vclock comparison -- that is purely a matter of logical time -- but is only for pruning purposes.

This way, when a given vclock gets too big, you can remove fields, starting at the one that was updated longest Ago, until you hit a size/age threshold that makes sense for your application.

But, you ask,Doesn' t this lose information?

Yes, it does-- But it won't make you lose your data.

The only case where this kind of pruning will matter at all is when a client holds a very old copy of The unpruned vclock and submits data descended from that. this will create a sibling (conflict) even though you might have been able to resolve it automatically if you had the complete unpruned vclock at the server. that is the tradeoff with pruning: in exchange for keeping growth under control, you run the chance of occasionally having to do a "false merge "... but you never lose data quietly, which makes this approach unequivocally better than moving the field identifiers off of the real client and onto the server.

The idea is that since we have to use the client as the actor, the problem is that the vector will grow bigger and bigger, can we solve this problem...

That is, prune. the prune and Timestamp can be used to regularly clear old client data.

Is this solution risky? There are some, but acceptable, so there is a valuable tradeoff, at least we will not lose data quietly now.