Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CockroachDB 1.0

cockroachlabs.com

Post reply on HN
Print view View original

81–90 of 366 posts

Re: CockroachDB 1.0

#81

Post by trimbo »

benesch wrote: post #53
zzzcpan wrote: post #29

Earlier quoted context omitted.

They are targeting MySQL/Postgres users, basically a post-CAP approach to RDBMS. But if you can work with eventual consistency, they are definitely not your first choice.

[Cockroach Labs engineer here.] Yes, if very low-latency (i.e., P99 latency sub-5ms) reads and writes are critical to your application, CockroachDB should not be your first choice. That said, one of the primary motivations for CockroachDB is that most existing systems don't handle eventual consistency well. In our experience, most developers will eventually write code that assumes a consistent database, either accide…

> P99 latency sub-5ms

Has the team cooked up any latency benchmarks for different configurations? E.g. same-rack, same-zone, multi-zone, multi-region?

Re: CockroachDB 1.0

#84

Post by dianasaur323 »

greenshackle2 wrote: post #71
bpicolo wrote: post #20

Earlier quoted context omitted.

Open source vs not open source. Cockroach still in it's infancy vs spanner. I'm sure there are a variety of things here, but they mostly aim to solve a similar problem with a slightly different approach. Some of the big details relate to not requiring atomic clocks: https://www.cockroachlabs.com/blog/living-without-atomic-clo... Here's their comparison chart, though naturally it's biased for things-cockroach-does: ht…

I'm confused. What's the difference between 'Yes' and 'Optional' in the 'Commercial Version' row on the comparison chart? To me 'Yes' suggests there is only a commercial version, but clearly that's not true for CockroachDB.

Thanks for pointing that out! We will fix that to optional for us :)

Re: CockroachDB 1.0

#85

Post by nocman »

socmag wrote: post #47
socmag wrote: post #36

Clocks are meaningless under load. The higher frequency the transactions the more you get into quantum physics. In reality, nobody cares if T-Mobile debited your account 0.01ms before WalMart. [edit] what is important is isolation and consistency of the transactons.

Instead of just downvoting, how about refuting my claim? I'm seriously curious what is the disagreement. These guys already established atomic clocks are unnecessary. Very interested in which use cases require them.

Am I wrong in remembering that the HN guidelines used to say that you should not downvote someone's comment simply because you disagreed with it?

I went looking, and I don't see that in the current guidelines. I could be wrong about it being there before, but I was almost certain that it was at one point.

Seems like it used to say that you should only downvote comments that you think don't contribute anything of value to the conversation.

Just curious, because it seems to me that for quite a while now there have been a lot of comments that appear to get downvoted just because people don't agree with what the person said (and often there are no responses to counter, the person just gets downvoted).

Re: CockroachDB 1.0

#86

Post by dianasaur323 »

api wrote: post #70

About nine months ago we made the decision to go with RethinkDB for our infrastructure in place of PostgreSQL (at least for live replicated data), but if this existed at the time we'd have seriously taken a look. We're pretty happy with RethinkDB but I plan on still taking a look at this so we have a backup option.

[cockroachdb here] We are big fans of RethinkDB, but also glad to hear that you'll explore CockroachDB. Let us know how it goes, and definitely file any issues / feature requests in our GitHub repo!

Re: CockroachDB 1.0

#87

Post by socmag »

johnhenry wrote: post #75
socmag wrote: post #36

Clocks are meaningless under load. The higher frequency the transactions the more you get into quantum physics. In reality, nobody cares if T-Mobile debited your account 0.01ms before WalMart. [edit] what is important is isolation and consistency of the transactons.

Actually, WalMNart cares and so does T-mobile. You probably care too if you stop and think for a bit... The concern here isn't just order of transactions, but also synchronization. For instance, WalMart might charge you twice for a transaction if it appears to have happened at different times when it arrives in different data centers. Also, the comment "The higher frequency the transactions the more you get into quan…

No I disagree since you left out atomicity from your argument.

WalMart cannot commit if someone else committed previously, they have to try again.

Atomicity is precisely what it is. There is no fuzziness there, you either do it or you don't.

The problem with current database designs is the idea of BeginTransaction, that function is the core of the problem.

"Transactions" in the real world are NOT completed until everyone agrees.

Consider you yourself enter into a transaction with your landlord, you BeginTransaction..

However during the negotiation you choose to disagree and back away from the deal.

That transaction, even though it took three months to decide was rejected (by either party).

The only "transaction" is the committed transaction.

Re: CockroachDB 1.0

#88

Post by korzun »

johnwheeler wrote: post #28

I think the name "Cockroach" was a really poor decision from a marketing standpoint. The team intended to convey durability, since cockroaches can live through anything. But when I think of a cockroach, I think, gross, disgusting, etc.

> I think the name "Cockroach" was a really poor decision from a marketing standpoint

Good thing that marketing types have no say when it comes to engineering decisions.

Re: CockroachDB 1.0

#89

Post by socmag »

theptip wrote: post #69
socmag wrote: post #47

Earlier quoted context omitted.

Instead of just downvoting, how about refuting my claim? I'm seriously curious what is the disagreement. These guys already established atomic clocks are unnecessary. Very interested in which use cases require them.

Read and learn: https://research.google.com/archive/spanner.html Serializability is all about ensuring a single consistent ordering of events. Lots of algorithmic shortcuts you can take if all your nodes' clocks are precisely in sync.

I'm very familiar with the literature since I'm a distributed database developer.

If you investigate high frequency trading you will understand that the quantum phenomena that I'm talking about is not just me high on mushrooms but a real world thing.

The only "time" relevant is the time when the cluster agrees an atomic, isolated transaction is time to commit from its own perspective.

Re: CockroachDB 1.0

#90

Post by arjunnarayan »

therealmarv wrote: post #82

Does this work theoretically interplanetary (just asking because for science) ?

No. Once your latency goes beyond single digit seconds, performance will probably collapse. Too many subsystems would time out. in theory it could be made to work (with terrible performance, and extremely long commit-waits due to having to wait until the remote planets get back to you), but I wouldn't architect a planetary spanning distributed database this way. We probably would have to go back to the drawing board and start from scratch.
Post reply on HN