barrel-db / hlc Goto Github PK

Maybe I'm missing something, but logical clocks are a mechanism used to work around the fact that physical timestamps are unreliable in distributed systems.

How is adding a physical timestamp to a logical one doing anything to help?

In case of a lack of causal conflict, the approach would be to either detect the conflict, store siblings, and return this to the application; or to instead pick a winner.

In case of a causal conflict, I can only assume the timestamp is used to pick a winner. If the timestamp is to be judged unreliable, how is it doing any better work than just picking any random total order between conflicting values? You could very well just pick max(A, B), min(A,B), max(Hash(A), Hash(B)), etc. as long as all nodes of a system use the same deterministic comparison.

Is there some use of an assumed accuracy range for the timestamp? If so, why not just use the timestamp without any logical clock, and then detect conflicts whenever two timestamps are edged too close together?

I'm guessing the only benefit I could see is that you're reducing your problem cases, which were

for logical clocks:

• Conflicts in causality are detected
• Conflicts in causality and timestamps are detected
• Conflicts purely in timestamps are ignored

And for timestamps with a known precision:

• Conflicts in causality and timestamps are detected
• Conflicts in timestamps are detected
• Conflicts in causality only are ignored

Down to:

• Conflict in causality and timestamps are detected
• Conflicts in causality xor timestamps are ignored

I'm not exactly sure how often, in practice, this will happen and actually be desirable to do. Can you enlighten me?