Live data from Hacker News

CockroachDB 1.0

cockroachlabs.com

41–50 of 366 posts

Re: CockroachDB 1.0

#41
post #30

Can Cockroach be plugged into a Rails app where mysql was? I'd be interested in hearing: - the backup story - the replication/failover story - horizontal scaling story (is it plug and play)

I have ported a MySQL-based ActiveRecord Rails app that was somewhat complicated to Postgres, and then on to CockroachDB. It works pretty well, so I'd give it a go. We're also committed to supporting ActiveRecord via the Postgres connector, so if you run into any bugs, we would do our best to fix them. I am personally invested in ActiveRecord support myself. At this point ORM support on CockroachDB is driven mostly by usage so please try it!

Your other questions are better answered on the blog post, but quickly:

* CockroachDB core comes with a `dump` command to backup your databases. CockroachDB Enterprise has blazingly fast _incremental_ cloud backup and restore, the kind that you might want for a very large deployment.

* Replication is managed under the hood by sharding the data into many ranges that are each 64mb in size. Each range is replicated using Raft, and if a node goes down, the other replicas scattered across the cluster seamlessly take over and upreplicate a new replica to "heal" the cluster.

* The horizontal scaling is indeed plug and play - just add more nodes to the cluster and they'll automatically rebalance replicas across the cluster with no downtime and no additional configuration.

Re: CockroachDB 1.0

#42
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.

The difference is that "mongo" does not have a universally-known meaning. Cockroaches and known throughout the world, and are disgusting throughout the world.

Re: CockroachDB 1.0

#43

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.

Yeah, I suggested "RoachDB" a while back. Which sounds more pleasant. There was a github issue for this as well.

Re: CockroachDB 1.0

#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

Re: CockroachDB 1.0

#45
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.

employee here.

Yep, we've also had our share of troubles with noisy clock on cloud environments, so that's something we're very aware of. Further down the road, we're considering a "clockless" mode, which of course isn't clockless, but depends less on the offset threshold: https://github.com/cockroachdb/cockroach/issues/14093

That said, even today, configuring a cluster with a fairly high maximum clock offset is feasible for many workloads.

Re: CockroachDB 1.0

#47
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.

Re: CockroachDB 1.0

#48
First, this is awesome! Congrats to the team for reaching this milestone.

Secondly, I think the name is memorable and conveys exactly what it should. If I were ever on an engineering team that chose not to use CockroachDB due to being "grossed out" by the name, I wouldn't be on that engineering team for long. Perhaps someone can explain the knee-jerk reaction to it for me.

Re: CockroachDB 1.0

#49
post #42
post #37

Earlier quoted context omitted.

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.

The difference is that "mongo" does not have a universally-known meaning. Cockroaches and known throughout the world, and are disgusting throughout the world.

In Italy "mongo" conjures up the slur used for mentally challenged people. I had a friend smirk when I mentioned MongoDB once.

Re: CockroachDB 1.0

#50
I'm amazed at how visceral a reaction the term "cockroach" receives haha

Though I AM a country kid, so maybe I'm just a bit less squeamish when it comes to these things.

Post reply on HN