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

151–160 of 366 posts

Re: CockroachDB 1.0

#151

Post by grzm »

nocman wrote: post #85
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.

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 valu…

While it's not in the guidelines, 'pg is on record years ago saying that downvoting for disagreement is okay, given that people upvote for agreement:

https://news.ycombinator.com/item?id=117171

That said, I think many on HN do think that downvotes should be reserved for uncivil or unsubstantive comments as they don't contribute to the conversation. Some will still downvote for disagreement or for other reasons.

I think it's best not to let it bother you or worry about it because there's not much you can do about it, other than contribute as civilly, substantively, charitably, and in good faith.

Re: CockroachDB 1.0

#152

Post by dang »

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.

We detached this subthread from https://news.ycombinator.com/item?id=14308521 and marked it off-topic.

Re: CockroachDB 1.0

#153

Post by cachvico »

tw04 wrote: post #129
nocman wrote: post #106

Earlier quoted context omitted.

I'm certain that I'm not thinking of somewhere else. I'm completely open to the possibility that I just remember it wrong, but I'm sure that it was HN that I was thinking of, and not another site.

You're thinking of Reddit.

Reddit, we did it again.

Re: CockroachDB 1.0

#154

Post by sixdimensional »

arjunnarayan wrote: post #144
sixdimensional wrote: post #138

How does Cockroach efficiently handle the shuffle step when data is on many nodes on the cluster and has to move to be joined? Does Cockroach need high capacity network links to function well? I always see companies making the claim of linear speedup with more nodes but surely that can't be the case if the nodes are geographically disjointed over anything less than gigabit links? Perhaps linear speedup with more node…

The short story is we do need high capacity network links to function well. By "high capacity" I mean at least double digit megabit links between your datacenters. A query that inherently requires shuffling because the data is geographically distributed can't get past the bandwidth needs of performing the shuffle. At the very least, with the literal simplest query plan, you're going to need all the raw data to be tra…

That makes sense- I think part of the reason such types of databases are well suited to cloud operations is the guaranteed throughput of the cloud providers own network backbone, which is almost impossible for any single "regular" organization to match, at least for the price. I think we are at a point where doing business without the cloud will become nearly (but not completely) impossible at huge scale with all these features.

Thank you very much for your detailed answer and good luck with the continued rollout!

Re: CockroachDB 1.0

#156

Post by daliwali »

CockroachDB looks like a great alternative to PostgreSQL, congrats to the team for doing so much in such a short time. The wire protocol is compatible with Postgres, which allows re-using battle-tested Postgres clients. However it's a non-starter for my use case since it lacks array columns, which Postgres supports [0]. I also make use of fairly recent SQL features introduced in Postgres 9.4, but I'm not sure if there are major issues with compatibility.

[0] https://github.com/cockroachdb/cockroach/issues/2115

Re: CockroachDB 1.0

#157

Post by Svenskunganka »

arjunnarayan wrote: post #122
Svenskunganka wrote: post #114

Pardon the nature of my question, but I'm really interested in what your experience has been so far building a database with Go? Has its runtime (the GC for example) posed any issues for you so far? Looking at other RDBMS's, languages with manual memory management like C or C++ seems to be the go-to choice, so what were the reasons you chose Go? I'm quite frankly amazed that Go's runtime is able to support a database…

We have a post on why we chose Go, from a year and a half ago: https://www.cockroachlabs.com/blog/why-go-was-the-right-choi... More technically, here's a somewhat random set of thoughts on the subject: The Go GC is performant and predictable, unlike the JVM GC. We do have some very memory-allocation-conscious code patterns to minimize the performance impact of working in a garbage-collected language runtime, but in t…

Thank you for the reply! You and the presentation video Ben posted covered pretty much all of my questions, and I'm going to keep an eye on the issue tracker regarding performance to see what interesting things you might run into and how you deal with them in Go!

Re: CockroachDB 1.0

#158

Post by newman314 »

rodionos wrote: post #39
dis-sys wrote: post #6

I really like the fact that the CockroachDB team recently did a detailed Jepsen test with Aphyr. The follow up articles from both CockroachDB and Aphyr explaining the findings are very interesting to read. For those who might be interested - https://www.cockroachlabs.com/blog/cockroachdb-beta-passes-j... https://jepsen.io/analyses/cockroachdb-beta-20160829

> When a node exceeds the clock offset threshold, it will automatically shut down to prevent anomalies. If you're planning to run on VMware, be prepared to handle rather dramatic system clock shifts. I've seen shifts of up to 5 minutes during heavy backup windows. Not all customers might be willing to have their nodes go down due to system clock / NTP issues.

Do people not run NTP on their VMs?

Or are you saying that you see heavy clock skew despite having NTP in place?

Re: CockroachDB 1.0

#159

Post by rjammala »

arjunnarayan wrote: post #150
rjammala wrote: post #133

Earlier quoted context omitted.

Thanks for the video. Can you please upload the slides somewhere?

We were told that the slides would be uploaded by Applicative (hence we didn't post a copy), but we can't seem to find it on the internet either, so here's a copy from our Google drive: https://drive.google.com/file/d/0ByQnrkOiRT_LMmZ6SXFmbk5wTDA...

Thanks! Arjun.

Re: CockroachDB 1.0

#160

Post by newsat13 »

Very disappointed with HN turning into a 4chan/reddit style trolling board about the name. Guys, we get it that you don't like the name. Can we please stop bike shedding and move on? The people at cockroachdb have obviously seen all your messages but decided it's worth keeping the name. What more is there to talk about? Why not talk about the relative technical merits of this DB?
Post reply on HN