tschottdorf

I'm close to a 35+ yo engineer and have been with my current employer for over six years, mostly based in Europe. There are multiple ICs, myself included, in positions like the ones you seem to be looking for, and we are hiring. I know you're asking for advice and not for leads, but maybe the data point that I consider these reasonable goals is advice enough and perhaps you'd like to chat about the company behind it. Reach out at tobias@cockroachlabs.com if you're interested.

I tried to use this but once I start entering tasks I don't see how to proceed. There's no way forward from neither there nor the project list page. Am I missing something?

There is an extension to linearizability that takes General Relativity into account. Paywalled unfortunately: https://link.springer.com/chapter/10.1007/978-3-662-45174-8_... I agree that whatever can be done in an eventually consistent fashion should be. For the rest, at least academia has an answer.

(I work at Cockroach Labs and gave an internal talk on this paper some time ago).

https://github.com/uwplse/verdi is a good example of this (it uses coq and extractions along with minimal glue).

employee here.

Yep, we've also had our share of troubles with noisy clock on cloud environments, so that's something we're very aware of. Further down the road, we're considering a "clockless" mode, which of course isn't clockless, but depends less on the offset threshold: https://github.com/cockroachdb/cockroach/issues/14093

That said, even today, configuring a cluster with a fairly high maximum clock offset is feasible for many workloads.

I'm not really on wifi good enough to reply extensively, but I pushed an update to the post explaining this better. If you carry out the read explicitly, you can still get the anomaly in much the same way. I should've done so from the beginning, but I tried to simplify the argument and went too far.

I don't think that gryadka is correct, see http://tschottdorf.github.io/if-its-not-paxos-its-probably-w....

Yes, if your timestamp is far enough in the past (this is determined by the maximum clock offset configured for the cluster), and if you don't collide with writes of a long-running transaction (which may run at a timestamp that could influence what you read), you will not have to worry about contention. What you're suggesting are definitely options for reading consistent, if slightly out of date, information from a hot keyspace. There's a blog post on time travel queries, which conveniently expose the required functionality as specified by the SQL standard.

Cockroach Labs employee here. We provide serializable consistency for the whole keyspace. It's just that it's easier when you stay in one Raft ensemble as less can go wrong.

Employee here - which discussion around NewSQL would you like to have? You pay for the consistency in more round trips between replicas, and you need a quorum of your nodes (which carry your data) to be alive. All of that stuff can be made arbitrarily more complex to increase throughput, but essentially these are the tradeoffs.

Note that Spanner always waits out the clock uncertainty on commit, while Cockroach doesn't need to do that - by design there are fewer situations in which the offset really matters. We can still benefit from a good bound in some situations, in particular you get global linearizability between causally unrelated transactions by waiting out the maximum clock offset (so just what Spanner does). BTW, I'm not sure when you would ever need the above guarantee, but it's cool! (disclaimer: actually working on the project).

Exactly right. The hard part is building a key-value store with a powerful notion of transactions (not just compare-and-set or the like), and that's what's mostly done. Structured data is still work, but on the shoulders of giants.

The plan is to get out of alpha as soon as possible. I'll leave it to the founders to throw dates around but we're working hard on getting the technical core on solid ground, and all the auxiliary stuff (UI, deployment, ...) required for beta is getting a lot of attention. We'll have hands-on deployment demos soon and if you follow the project in the coming weeks you'll probably get a good idea of where things are going.

Cockroach trusts the MaxOffset, and if your clocks don't live up to the promise, you might get some stale reads. By the way, Spanner breaks in the same way if their clock offset (via their TrueTime API) fails them. But Spanner has to wait out the MaxOffset on every commit, we don't - so we get away with having it high enough for off-the-shelf clock synchronization and save you the atomic clocks, at similar guarantees. That's a very good deal. If you happen to have atomic clocks around and you have strong guarantees on your uncertainty like Spanner does, you get linearizability at the same price.

For a more in-depth explanation of the above, see https://gist.github.com/tschottdorf/57bcccc379b151456044.

That's correct, it's a consistent system and so the majority needs to be involved on mutating writes. Reads typically can read from one designated copy of the replica directly (bypassing Raft).

not quite ready yet, but the pace has picked up dramatically. We've begun work on the structured data layer and are whipping up a suite of extensive acceptance tests (load testing, performance metrics, ...) to iron out all of the performance issues/bugs that we don't want to be a part of the beta. Raft consensus, btw, is already implemented. We'll update the README shortly to give a more concrete estimate of the situation.