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

CockroachDB 2.0 Performance Makes Significant Strides

cockroachlabs.com

Post reply on HN
Print view View original

91–100 of 187 posts

Re: CockroachDB 2.0 Performance Makes Significant Strides

#91

Post by [deleted] »

mlevental wrote: post #64
ardit33 wrote: post #58

And their fucking stupid name..... if they fail, they surely will be remembered as the company with the idiotic name. I can't see serious engineers working on a company named "Cockroach".

>I can't see serious engineers working on a company named "Cockroach". You used to work at a company called Yammer . God forbid they're not called tech.ai.io-ify. I think it's really funny that this comes up almost every time there's a post about CockroachDB. There were also a lot of people commenting on https://news.ycombinator.com/item?id=16693253 about foul language and such. I also remember being at a big confere…

[deleted]

Re: CockroachDB 2.0 Performance Makes Significant Strides

#92

Post by misterbowfinger »

strict9 wrote: post #31

Before clicking the comments link, I always know what to expect in HN comment section for a CDB post announcing their latest milestone or feature: A lot of congrats and excitement, questions about who uses it in a production environment, very specific use-case questions, and of course the name. Weird how predictable the response to one company/tech always is.

So. For me, personally, I don't care about the name. I generally care that it's great tech, and it clearly has a great team behind it.

However....

If I worked at CockroachDB, and I saw the negative feedback around the name, I'd take it to heart. At the end of the day, the name is marketing for the hard work of their engineers, and marketing for the engineers that want to use this DB (remember, they need to sell it to their managers who may not be technical).

This issue can show up in unexpected ways. For example, for cloud providers like Compose (IBM company), would they be comfortable with putting "CockroachDB" on the front page? They might if it's good enough, but it's at least a consideration (i.e. another meeting, another stakeholder to convince).

Or how about an enterprise company that's going through due diligence, and when their client asks them about their tech stack do they say "CockroachDB" or do they obfuscate the name by saying "It's a high-performance distributed database". That's a crucial moment to market CockroachDB, and it could get lost. As sad as it is, saying that you're using MySQL "because Oracle" is a point of leverage for some sales people.

Is the name worth it? Asking honestly.

Re: CockroachDB 2.0 Performance Makes Significant Strides

#93

Post by wilbeibi »

The thing I really don't get is why CockroachDB is avoid benchmarking with it's rival tidb (https://github.com/cockroachdb/docs/issues/1412). tidb already pretty mature, used in many big companies (Let's say, Didi, which on the similar scale data with Uber, and banks).

Even if I like CockroachDB's pg sql more, it would be helpful to have the comparison/benchmark to show something more.

Re: CockroachDB 2.0 Performance Makes Significant Strides

#95

Post by dexterdog »

crispinb wrote: post #83
dexterdog wrote: post #62

Earlier quoted context omitted.

Cockroaches are considered pretty durable right? In the 80s I remember the line was always that after the nukes landed there would only be cockroaches and twinkies left. That's not a bad thing to say about a database.

This is the sort of obtuse insistence on narrow denotational semantics that makes everyone avoid engineers at parties ;)

It works like a charm for me, or wait, what's the opposite of a charm?

Re: CockroachDB 2.0 Performance Makes Significant Strides

#96

Post by AlimJaffer »

netghost wrote: post #86
AlimJaffer wrote: post #68

Earlier quoted context omitted.

raises hand we're using them extensively. They're our database of choice that we've paired with Nakama[1] which is an open-source, distributed server. Have nothing but great things to say about the database itself in terms of growing performance and the team behind it :). They've been great to us since day-1. [1] github.com/heroiclabs/nakama

What kind of workload are you using it for? What's been your biggest win while using it?

A couple of our use-cases include: good KV access (stored user data etc.) and listing blocks of data that has been pre-sorted on disk at insert time (leaderboard records, chat message history etc.). As well, the clustering technology is particularly useful at scale. We work in the games space with some very large games in production, which allows us to spread the load across multiple database nodes and offers us peace of mind regarding redundancy.

Re: CockroachDB 2.0 Performance Makes Significant Strides

#97

Post by tyingq »

arjunnarayan wrote: post #52
itsdrewmiller wrote: post #34

Earlier quoted context omitted.

Same here, but in educating myself more I found that TPC-C seems to be a somewhat obsolete metric compared to TPC-E (see https://stackoverflow.com/questions/9246939/what-is-the-diff... ). Why use the old one here? edit: Looking into it even further, I agree with the co-author's response here that TPC-C is still an appropriate metric. TPC-E is different and newer but still not as widely used.

I don't think it's true to claim that TPC-C is obsolete and subsumed by TPC-E. They are both different OLTP benchmarks, with different characteristics. TPC-C is more write heavy, TPC-E is far more read heavy. It's true that TPC-E is newer, but doesn't deprecate TPC-C (the way TPC-A, for instance, is now deprecated). We chose TPC-C because it's far more understood than TPC-E in 2018. We wanted to provide understandabl…

It seems not used much anymore. Follow that link (http://www.tpc.org/tpcc/results/tpcc_results.asp?print=false...) and sort by either score, or price performance. The vast majority of top results are a decade old or more. I couldnt find anything less than 5 years old without going to second/third pages.

And the top results are usually crazy high number of cores clusters. The Sun example was over 1700 cores.

Re: CockroachDB 2.0 Performance Makes Significant Strides

#99

Post by manigandham »

wilbeibi wrote: post #93

The thing I really don't get is why CockroachDB is avoid benchmarking with it's rival tidb ( https://github.com/cockroachdb/docs/issues/1412 ). tidb already pretty mature, used in many big companies (Let's say, Didi, which on the similar scale data with Uber, and banks). Even if I like CockroachDB's pg sql more, it would be helpful to have the comparison/benchmark to show something more.

TiDB is much more complicated to run with several moving pieces. Also missing a lot of standard relational features as you can see from the roadmap: https://github.com/pingcap/docs/blob/master/ROADMAP.md

Re: CockroachDB 2.0 Performance Makes Significant Strides

#100

Post by Rafuino »

jordanlewis wrote: post #89
Rafuino wrote: post #63

Earlier quoted context omitted.

Thanks for the short answer. Would be good to know how many local SSDs are attached though for the 850 warehouse scenario. The TPC-C documentation says each warehouse maintains 100,000 items in their stock, but I can't surmise from that how much storage is required to hold 850 warehouses' worth of data. I'm impatient though so let me try to work through the #s myself. I'm using GCP's monthly reserved pricing in the U…

Each warehouse requires about 80 megabytes of storage, unreplicated. 1250 warehouses * 80 MB * 3-way replication = 300 GB, which comfortably fits in a 3-node cluster with 1 local SSD each.

Thank you! My Google-fu couldn't find me the answer
Post reply on HN