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

CockroachDB beta-20161013

jepsen.io

Post reply on HN
Print view View original

11–20 of 213 posts

Re: CockroachDB beta-20161013

#11

Post by aphyr »

BrentOzar wrote: post #2

"For instance, on a cluster of five m3.large nodes, an even mixture of processes performing single-row inserts and selects over a few hundred rows pushed ~40 inserts and ~20 reads per second (steady-state)." Wow, that's...not fast.

I just want to emphasize that:

a.) this is a beta product where the team has been focusing on completeness and correctness before performance

b.) I was testing Cockroach from August through October--Cockroach Labs has put a good deal of work into performance in the last three months, but that work hasn't been merged into mainline yet. I expect things should be a good deal faster by 1.0.

c.) Jepsen does some intentionally pathological things to databases. For instance, we choose extremely small Cockroach shard sizes to force constant rebalancing of the keyspace under inserts. Don't treat this as representative of a production workload.

Re: CockroachDB beta-20161013

#12

Post by aphyr »

vonklaus wrote: post #10

Wow. Probably fundraising and getting out front of googles new consumer spanner service. I just started experimenting w/ cockroachdb and it sounds/seems great. They def are campaigning hard, landing a Jepsen test and a lot of posts/articles last couple. I am pulling for them over G on principle. I infer they know people at Stripe where the Rethink team & Aphyr are so hopefully they can learn from them and build an aw…

Just as a headsup, I left Stripe in late 2015 to run Jepsen as an independent consultancy.

Re: CockroachDB beta-20161013

#13

Post by qaq »

aphyr wrote: post #11
BrentOzar wrote: post #2

"For instance, on a cluster of five m3.large nodes, an even mixture of processes performing single-row inserts and selects over a few hundred rows pushed ~40 inserts and ~20 reads per second (steady-state)." Wow, that's...not fast.

I just want to emphasize that: a.) this is a beta product where the team has been focusing on completeness and correctness before performance b.) I was testing Cockroach from August through October--Cockroach Labs has put a good deal of work into performance in the last three months, but that work hasn't been merged into mainline yet. I expect things should be a good deal faster by 1.0. c.) Jepsen does some intention…

They need to be at least 1000x to 10,000x faster on the read side though

Re: CockroachDB beta-20161013

#14

Post by will_pseudonym »

CockroachDB might be the worst product name I've come across. I get it; cockroaches are extremely hardy, but they're also much more strongly associated with uncleanliness and disease.

EDIT: Also, cockroaches are BUGS! Bugs cause problems in computer systems.

Re: CockroachDB beta-20161013

#15

Post by artursapek »

will_pseudonym wrote: post #14

CockroachDB might be the worst product name I've come across. I get it; cockroaches are extremely hardy, but they're also much more strongly associated with uncleanliness and disease. EDIT: Also, cockroaches are BUGS! Bugs cause problems in computer systems.

I think it's the most memorable database name I've seen. So at least it has that going for it.

Re: CockroachDB beta-20161013

#16

Post by sametmax »

BrentOzar wrote: post #2

"For instance, on a cluster of five m3.large nodes, an even mixture of processes performing single-row inserts and selects over a few hundred rows pushed ~40 inserts and ~20 reads per second (steady-state)." Wow, that's...not fast.

Even if they manage to multiply this by 100 on the final release, it's still way weaker than a regular sql db. I hope they have another selling point than performance.

Re: CockroachDB beta-20161013

#17

Post by aphyr »

qaq wrote: post #13
aphyr wrote: post #11

Earlier quoted context omitted.

I just want to emphasize that: a.) this is a beta product where the team has been focusing on completeness and correctness before performance b.) I was testing Cockroach from August through October--Cockroach Labs has put a good deal of work into performance in the last three months, but that work hasn't been merged into mainline yet. I expect things should be a good deal faster by 1.0. c.) Jepsen does some intention…

They need to be at least 1000x to 10,000x faster on the read side though

I agree that it can and should be faster, but the targets will depend on what you're going for. 20k linearizable reads/sec on EBS-backed instances is, uh, maybe a tad optimistic.

Re: CockroachDB beta-20161013

#18

Post by atmosx »

artursapek wrote: post #15
will_pseudonym wrote: post #14

CockroachDB might be the worst product name I've come across. I get it; cockroaches are extremely hardy, but they're also much more strongly associated with uncleanliness and disease. EDIT: Also, cockroaches are BUGS! Bugs cause problems in computer systems.

I think it's the most memorable database name I've seen. So at least it has that going for it.

I'm not a native English speaker and have troubles pronouncing "cockroach". In my view the naming is rather unfortunate.

Re: CockroachDB beta-20161013

#20

Post by tdrd »

Already__Taken wrote: post #7
exhilaration wrote: post #4

Like Spanner, Cockroach’s correctness depends on the strength of its clocks... Unlike Spanner, CockroachDB users are likely deploying on commodity hardware or the cloud, without GPS and atomic clocks for reference. I'm curious, do any of the cloud providers offer instances with high-precision clocks? Maybe this is something one of the smaller cloud providers might want to offer to differentiate themselves - instances…

Why can't these datacenters be using a high precision gps source for their NTP source in the building?

[Cockroach Labs employee]

In addition to being extremely precise, TrueTime is explicit about error in its measurements.

In other words, a call to TrueTime returns a lower and upper bound for the current time, which is important for systems like Spanner or CockroachDB when operations must be linearized.

In effect, Spanner sleeps on each operation for a duration of [latest_upper_bound - current_lower_bound] to ensure that operations are strictly ordered.

Your suggestion might improve typical clock synchronization, but still leaves defining the critical offset threshold to the operator, and importantly leaves little choice for software like CockroachDB other than to crash when it detects that the invariant is violated.

Post reply on HN