Live data from Hacker News

CockroachDB 1.0

cockroachlabs.com

71–80 of 366 posts

Re: CockroachDB 1.0

#71
post #20

Can someone give a brief pros/cons between Cockroach DB Core and Google Cloud Spanner?

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.

Re: CockroachDB 1.0

#72
post #44

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.

Cockroaches are figuratively unkillable; resilient and survive in nuclear wastelands. I think the team was going for something like: you put your data in here and it will survive basically anything but a multi-continent nuclear war

Then how about ShelterDB or ProtectDB or something along those lines? Shelter is actually a pretty kick ass name for a DB IMO

Re: CockroachDB 1.0

#73
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, we want to bridge that gap. We want the linear scalability of your second group along with the full feature-set of the first group.

We will be publishing our performance numbers, but we haven't so far because the product has improved rapidly, and our numbers have been quickly obsoleted, but rest assured, we will be publishing a series of blog posts very soon. Anecdotally, our beta customers are not finding that they need very many more CockroachDB nodes than their existing database solutions, even with something as high-performant (but inconsistent) as Cassandra.

Re: CockroachDB 1.0

#74

In a couple of years, I suspect that they will rebrand their name to just "RoachDB". It conveys the same meaning, while not being that awkward to discuss with users/clients

> "RoachDB". It conveys the same meaning, while not being that awkward to discuss with users/clients

"Roach" has some other connotations as well[0], which may not help with selling to larger and enterprise clients.

[0] https://www.urbandictionary.com/define.php?term=roach

Re: CockroachDB 1.0

#75
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 quantum physics." isn't relevant here. This is more in the realm of relativity than quantum physics. Even so, we aren't currently at a point where we need to worry about transactions happening at relativistic speeds.

Re: CockroachDB 1.0

#76
post #37

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 memorable. So if the product is really excellent and is needed by customers - then I think it could be a boon. I mean Mongo has very bad associations for me in terms of childhood taunts and Blazing Saddles...but now the name really relates more to the product than to the original meaning.

> I mean Mongo has very bad associations for me in terms of childhood taunts and Blazing Saddles...but now the name really relates more to the product than to the original meaning.

The difference is that the word "mongo" is an issue of the same word having different meanings in different dialects. Whereas, with "cockroach", it's the same intended meaning, but with different connotations.

Re: CockroachDB 1.0

#78
post #25

Earlier quoted context omitted.

> CockroachDB is a distributed, scale-out SQL database which relies on hybrid logical clocks I was curious what "hybrid logical clocks" meant and found the linked paper a bit over my head. I found this more layman description: http://muratbuffalo.blogspot.ca/2014/07/hybrid-logical-clock... Apparently Google used GPS/atomic clocks to keep time synced: >> To alleviate the problems of large ε, Google's TrueTime (TT) emp…

You might find our post[1] on atomic clocks, rather having to do without them, partially interesting. [1]: https://www.cockroachlabs.com/blog/living-without-atomic-clo...

Hey guys, I'm a fellow developer of distributed systems here.

First of all I think what you are doing is great.

My question is what's the point of clocks at all? The current time is a very subjective matter and I'm sure you know this, the only real time is at the point when the cluster receives the request to commit. Anything else should be considered hearsay.

Specifically the time source of any client is totally meaningless since as you say further in the discussion that client machine times can be off by huge margins.

If you accept that then one has to accept the fact that individual machines within the cluster itself are prone to drift too, although one can attempt to correct for that I appreciate.

Wouldn't you think though that what is more important is that the order is more based on the bucketed time of arrival (with respect to the cluster).

I don't see how given network delays anyone can be totally sure A is prior to B, atomic clocks or not.

What is important is first to commit.

[edit] Yes would love to talk privately about this topic @irfansharif

Re: CockroachDB 1.0

#79

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…

I see it as technical people on HN who appreciate the metaphor, versus marketing/business people who can only think of "image".

It's to expected with the massive infestation of HN by suits and khakis in the last few years.

Re: CockroachDB 1.0

#80
It probably scales but how is the performance? If I need to load a couple billion rows and do a dozen joins in some analytics, is that one machine, a dozen, or 100?

Is it more for web apps, analytics, or what? When would I consider switching from e.g. Postgres to CockroachDB?

Post reply on HN