[1]: https://www.cockroachlabs.com/blog/living-without-atomic-clo...
First of all I think what you are doing is great.
My question is what's the point of clocks at all? The current time is a very subjective matter and I'm sure you know this, the only real time is at the point when the cluster receives the request to commit. Anything else should be considered hearsay.
Specifically the time source of any client is totally meaningless since as you say further in the discussion that client machine times can be off by huge margins.
If you accept that then one has to accept the fact that individual machines within the cluster itself are prone to drift too, although one can attempt to correct for that I appreciate.
Wouldn't you think though that what is more important is that the order is more based on the bucketed time of arrival (with respect to the cluster).
I don't see how given network delays anyone can be totally sure A is prior to B, atomic clocks or not.
What is important is first to commit.
[edit] Yes would love to talk privately about this topic @irfansharif
You throw three more observers in and how do you make sure that all of them observe the requests arriving in the same order? Not even the hardware can guarantee that packets arrive at 4 places in the same order, even if the hardware is arranged in a symmetrical fashion (which takes half the fun out of a clustered solution).
I would highly recommend to read the link by irfansharif. It's probably the best primer ever written on the subject.
distributed systems like cockroach shouldn't use the client's conception of current time for anything at all, except possibly to store it (_verbatim_, don't interpret it) and relay it back to the client or to other clients (and let the client interpret it however they want).
[1]: https://github.com/cockroachdb/cockroach/blob/master/docs/de...
Building a distributed database that can optionally benefit from the same optimization actually makes a great deal of sense. Your average hobbyist won't care, but spending some extra few kilo bucks on hardware in a dc and get big throughput improvements out of your database system is a steal.
The CAP theorem still holds, so we pick which 2 out 3 to be strengths and where to compromise as little as possible. It's a guaranteed 87.3% effective hair loss formula. I find Quiet Riot helps.
I was curious what "hybrid logical clocks" meant and found the linked paper a bit over my head. I found this more layman description:
http://muratbuffalo.blogspot.ca/2014/07/hybrid-logical-clock...
Apparently Google used GPS/atomic clocks to keep time synced:
>> To alleviate the problems of large ε, Google's TrueTime (TT) employs GPS/atomic clocks to achieve tight-synchronization (ε=6ms), however the cost of adding the required support infrastructure can be prohibitive and ε=6ms is still a non-negligible time.
And CockroachDB created more of a hybrid version that works on commodity hardware.
Distributed systems programming sounds endlessly challenging as you are always balancing trade-offs.