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

141–150 of 366 posts

Re: CockroachDB 1.0

#141

Post by [deleted] »

cocktailpeanuts wrote: post #102
johnwheeler wrote: post #68

Earlier quoted context omitted.

You're going to have a hard time convincing nontechnical managements they need to go with Cockroach instead of Oracle. It's unfortunate the world works that way, but nevertheless, it works that way. It could be the best database in the world. They did a real disservice to themselves by naming it after a bug people typically associate with filth, disease, and germs. Would you use something called TurdDB or AssDB?

it's not at all unfortunate that the world works that way. What's really unfortunate is the founder of this seemingly great database system has decided to not care about how human psychology works. Here's an Wikipedia excerpt on cockroach: > They feed on human and pet food and can leave an offensive odor.[60] They can passively transport pathogenic microbes on their body surfaces, particularly in environments such as…

[deleted]

Re: CockroachDB 1.0

#142

Post by efsavage »

anthonylebrun wrote: post #56

Since there's a little side riff about the name going on I thought I'd throw in my 2 cents. Personally I love the name. I think it does a great job of conveying the spirit of the project and provides unlimited pun opportunities. Plus it's memorable, just like a real life roach encounter. Unfortunately I'm sure some people will discriminate against your DB on the basis of name alone. That's ludicrous, but that's our s…

It's a bad name because this topic will come up every time it's discussed, forever. It's a distraction from other relevant issues like new features or how it performs.

Re: CockroachDB 1.0

#143

Post by tsuraan »

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…

I don't have a full history of the guidelines, but the canonical link on this tends to be [0]. About nine years ago, PG thought downvote to disagree was perfectly reasonable. I don't think there's been any official change since then.

[0] - https://news.ycombinator.com/item?id=117171

Re: CockroachDB 1.0

#144

Post by arjunnarayan »

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 transported to a single node/datacenter, and I doubt there's a query and network setup where that's more efficient than doing networked shuffles themselves.

I don't think you need gigabit networks, but you're certainly going to want at least 10 megabit links. We have not tried to benchmark scenarios where we are bandwidth constrained, so I can't tell you precisely what the minimums are. All the cloud scenarios we've tested (on GCE, Azure, AWS, DigitalOcean) are constrained on other dimensions (i.e. CPU cores, memory, disk IO).

And thank you :)

Re: CockroachDB 1.0

#145

Post by state_machine »

politician wrote: post #127
state_machine wrote: post #107

Earlier quoted context omitted.

[cockroachdb employee] Short answer: no. Long answer: at their closest earth and mars are about 54m km apart, at the furthest it's over 400, with an average of around 225m km, so theoretical latency is varies between 4 and 24 minutes. CockroachDB uses synchronous replication via raft, and that latency would cause problems as would some other setting like our window sizes and their interaction with timeouts.

> CockroachDB uses synchronous replication via raft Deep space aside, I wish the announcement just said that! I came back to HN for insight into the paragraph about "multi-active availability... an evolution in high availability from active-active replication". Marketing... sometimes... I tell you what.

Whoops, sorry about that. If you're looking for more on how it works (rocksdb, raft, distributed transactions across multiple raft groups, etc), you might find the design doc interesting: https://github.com/cockroachdb/cockroach/blob/master/docs/de...

Re: CockroachDB 1.0

#146

Post by wmfiv »

arjunnarayan wrote: post #73
wmfiv wrote: post #63

Are there published benchmarks for multi-key operations and more complex SELECT statements? I apologize if I missed them. I'm trying to determine whether there's a place for Cockroach within what I think are the constraints in the database space. * Traditional SQL Databases - Go to solution for every project until proven otherwise. - Battle tested and unmatched features. - Hugely optimized with incredible single node…

[Cockroach Labs engineer here working on performance benchmarking] We have load generators for YCSB (just raw key-value ops in a firehose) and TPC-H (very complicated read-only queries) running right now, and we're about to start running TPC-C queries (moderately complex queries in large volume) as well. You can follow along on our progress here: https://github.com/cockroachdb/loadgen In the context of your dichotomy…

That's great. Thanks for the response and I'll keep an eye out for the blogs.

Re: CockroachDB 1.0

#147

Post by MarkMc »

kyle-rb wrote: post #111
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.

It's sort of like clickbait, but whatever works I guess. A name like CockroachDB catches my eye the same way Yandex's Cocaine PaaS makes me click to find out what the hell that product actually is.

The point is that is doesn't work. Yes, the name makes the product stand out but that benefit doesn't compensate for having your product associated with filth and disease.

There's a reason Toyota has never named a car 'The Cockroach' and a soft drink company has never released 'Cockroach Cola'.

Re: CockroachDB 1.0

#148

Post by [deleted] »

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…

[deleted]

Re: CockroachDB 1.0

#149

Post by MarkMc »

thraway2016 wrote: post #100
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.

If you make technology stack decisions based on your feelings rather than what the product actually does, then you shouldn't be employed as a decision-maker.

Then nobody should be employed as a decision-maker, because everyone is affected by their feelings.

Re: CockroachDB 1.0

#150

Post by arjunnarayan »

rjammala wrote: post #133
bdarnell wrote: post #124

Earlier quoted context omitted.

(Cockroach Labs co-founder) I gave a talk on exactly this subject at the ACM Applicative conference last year: https://www.cockroachlabs.com/community/tech-talks/challenge... Overall we've been happy with the choice. The GC is sometimes a performance issue, but it's manageable (and Go gives you better tools to limit the cost of GC than many other garbage-collected languages)

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...
Post reply on HN