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.
Good point! I suggest the topic starter to apply at the companies that build products for us techies to use. I live in Germany and we have many more remote options nowadays - New Relic, Elastic, Snowflake, Aiven, etc. It will be fun and you can master some specialisation that can make you more valuable and be a meaningful progression.
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).
Have you tried it yourself or maybe you know someone who have? Honestly, I think that this development is highly impractical due to very high entrance ticket price for someone not belonging to UW PLSE group ;-)
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.
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.
