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

61–70 of 366 posts

Re: CockroachDB 1.0

#61

Post by Mizza »

jabl wrote: post #52
cwisecarver wrote: post #3

Cue the comments stating that no one will use this because the name is bad.

Just like, err, GIMP? What is it with Spencer Kimball and naming things that gets people so upset? It's not like other company or product names are that good; we're just used to them. Some high profile tech companies: - Google: some propellerhead big number joke (hey, I have a Phd and I don't know offhand how big a googleplex is...) - Alphabet: Really? That out of ideas? - Amazon: Some hot snake and insect-infested j…

I mean the big issue is really the inherent positive/negative association. I wouldn't over-think it.

Amazon - big, marvelous jungle. Yahoo - an expression of Joy. Apple - a delicious sweet fruit.

Cockroach - a disgusting plague insect.

Re: CockroachDB 1.0

#62

Post by api »

dboreham wrote: post #60
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…

At first when I saw yet more name comments on this thread I felt disappointment that people can't leave the subject alone. But then I realized that as someone who doesn't care about the name, even positively enjoys it, I have a competitive advantage over those people. Now I feel good again.

Choosing technologies based on first-hand review and first principles rather than things like Gartner magic quadrants, big company brand recognition, feature lists, and "serious" sounding names is a competitive advantage that startups often have over big businesses. The latter are forced by their procurement departments and other forces to use old, inferior, and more costly technology.

On the flip side though if I were in charge of CockroachDB I would look at doing something about the name. Maybe rename it something like "Resilient" as part of the "exit from beta" milestone. It's going to be a serious liability for them selling to the kinds of customers I described above, and unfortunately that's where most of the money is in these devops/infrastructure markets. The key to success is to make a superior product and then figure out how to sell it to pointy haired bosses. The latter often means making it look more boring than it actually is.

Fun factoid: scientists sometimes do this with grant proposals. I've had two scientists independently tell me that they often take cool, fascinating research proposals and "make them boring" to sell them to bureaucrats. "You have to hide all the interesting stuff and make it sound like you are doing boring incremental research. If you talk about anything 'revolutionary' you will never get funded."

Re: CockroachDB 1.0

#63

Post by wmfiv »

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 performance.

  - Good replication and failover solutions.
* Cassandra

  - Solved massive data insert and retention.

  - Battle tested linear scalability to thousands of nodes.

  - Good per node performance.

  - Limited features.
It seems like many new databases tend to suffer from providing scale out but relatively poor per node performance so that a mid-size cluster still performs worse than a single node solution based on a traditional SQL database.

And if you genuinely need huge insert volumes, because of the per node performance you'd need an enormous cluster whereas Cassandra would deal with it quite comfortably.

Re: CockroachDB 1.0

#64

Post by cocktailpeanuts »

jabl wrote: post #52
cwisecarver wrote: post #3

Cue the comments stating that no one will use this because the name is bad.

Just like, err, GIMP? What is it with Spencer Kimball and naming things that gets people so upset? It's not like other company or product names are that good; we're just used to them. Some high profile tech companies: - Google: some propellerhead big number joke (hey, I have a Phd and I don't know offhand how big a googleplex is...) - Alphabet: Really? That out of ideas? - Amazon: Some hot snake and insect-infested j…

There's bad name, and then there's repulsive name.

All the examples you mention fall under "bad name", and it's not even objectively bad, I actually think they're great names, so it's subjective. And NONE of them are repulsive.

Then again, if you insist cockroaches are lovable creatures I have nothing more to say.

Re: CockroachDB 1.0

#66

Post by [deleted] »

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.

[deleted]

Re: CockroachDB 1.0

#67

Post by [deleted] »

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.

[deleted]

Re: CockroachDB 1.0

#68

Post by johnwheeler »

_jal wrote: post #57
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.

This isn't the place to find out, but I'm curious as to the relative ratio of people who have this reaction. I don't, at all - I'm vaguely positive towards the name, but in general don't care what things are called, so long as I can remember it. (Although I still maintain that "Paypal" is the stupidest name ever.) I know people exist who will avoid things simply because they react negatively to the name. How prevalen…

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?

Re: CockroachDB 1.0

#69

Post by theptip »

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.

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.

Re: CockroachDB 1.0

#70

Post by api »

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