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

101–110 of 213 posts

Re: CockroachDB beta-20161013

#101

Post by jdcarter »

WhitneyLand wrote: post #24

Could the name actually slow the project's momentum? I only recently read some cool things about CDB and wondered if I could have been subconsciously skipping articles about it for deep seeded reasons like http://bbc.com/future/story/20140918-the-reality-about-roach... Of course anything good may eventually rise to success on its merits, but in case I'm not the only one with a subconscious aversion maybe the info bel…

Absolutely the name is holding them back. In my case it prevents me from championing the product within my company. Going to the executives and saying "we're going to put our most precious data into Cockroach" simply won't fly. Any discussion of features will be for naught; I know the CEO will make a "no" decision as soon as he hears the name.

To any Cockroach Labs folks who might read this: please give me (and all of us) a name that I can evangelize without my audience cringing.

Re: CockroachDB beta-20161013

#102

Post by hinkley »

qaq wrote: post #55
aphyr wrote: post #46

Earlier quoted context omitted.

As I mentioned in the article's introductory paragraphs, where Spanner forces a minimum latency on writes to ensure consistency, CockroachDB pushes that latency to reads which contend with a write.

Latency is one thing throughput is a different animal 2 reads/second per m3.large node that really forces one to think there are some severe architectural issues.

You're not wrong. Whoever downvoted you is pushing an agenda and I'm not happy about it.

Reads per second is ultimately a measure of how many operations can be retired per second, not how long the operation takes. Anyone who has spent fifteen minutes learning about capacity planning should know that. 5 reads per second doesn't mean each read takes 200ms. It might mean 1 second per read spread across 5 threads of execution, or 3 seconds per read across 15 workers.

Re: CockroachDB beta-20161013

#103

Post by stickfigure »

bfrog wrote: post #79
bdarnell wrote: post #44

Earlier quoted context omitted.

(Cockroach Labs CTO here) Jepsen is essentially a worst-case stress test for a consistent database: all the transactions conflict with each other. CockroachDB's optimistic concurrency control performs worse with this kind of workload than the pessimistic (lock-based) concurrency control seen in most non-distributed databases. But this high-contention scenario is not the norm for most databases. Most transactions don'…

Couldn't this be a problem for application authors and a potential source of DoS activities? It seems this should be a big red warning flag somewhere.

Not really.

All databases tend to struggle to under contention. If you are an application author building a high-scale app, you need to avoid contention by design. That single counter row you were planning to increment on every visit? Bad idea; maybe insert a new visit record instead.

The contention in this example is an aspect of the test design, not database design. You wouldn't try to build an app this way.

Re: CockroachDB beta-20161013

#104

Post by anoother »

huehehue wrote: post #52
digler999 wrote: post #37

Earlier quoted context omitted.

to me it's not a deeply-seeded reason, it's just when I hear cutesy-sounding names I just don't take them seriously. They sound like the latest, hipster thing that's going to be in-bloom for a (figurative) week or two until the next cutesy thing steals everyone's attention. Even the language Pony has a mildly off-putting name (to me) despite hearing people rave about it. Couch DB ? What the hell does that mean ? I ad…

Ah yes, let's not forget the solid branding behind some of Adobe's work: https://pig.apache.org/ https://hive.apache.org/ (Look at the anguish in this creature's face) http://hadoop.apache.org/

s/Adobe/Apache

?

Re: CockroachDB beta-20161013

#105

Post by influx »

WhitneyLand wrote: post #24

Could the name actually slow the project's momentum? I only recently read some cool things about CDB and wondered if I could have been subconsciously skipping articles about it for deep seeded reasons like http://bbc.com/future/story/20140918-the-reality-about-roach... Of course anything good may eventually rise to success on its merits, but in case I'm not the only one with a subconscious aversion maybe the info bel…

It's a terrible name, it also has the property that stupidly configured web filters could filter it due to string matching the first part of the word.

It also makes your employees look stupid when they tell their landlords, bank accounts, dates that they work at Cockroach Labs. Good luck explaining that you aren't an exterminator.

Re: CockroachDB beta-20161013

#107

Post by hinkley »

arjunnarayan wrote: post #82
hinkley wrote: post #39

Earlier quoted context omitted.

I'm a little confused about how read speed is 2x slower than write speed. With respect to 'correctness', you're drifting into pyrrhic victory or 'not even wrong' territory at that point. When there are basic expectations of behavior that aren't being met, many of us would reject the idea that this code is 'correct'.

[Disclaimer: CockroachDB engineer here, working on performance and benchmarking] IIRC, in the case that aphyr refers to for these specific numbers, the reads are scans that span multiple shards[1], while the writes are writes to single shards. [1] even though aphyr says it's just a hundred rows, the tables are split into multiple shards because aphyr in this case was specifically testing our correctness in multi-shar…

Oh, I see. That makes sense, thank you.

The benchmark isn't quite apples to apples. I'm used to people doing put/get benchmarks, not put/search workflows. Merging results from multiple machines is nothing to sneeze at, especially if you have replication between nodes.

I worked for a search engine dotbomb, and I had a constant worry that the core engineering team had not solved a very similar problem. But since the funding round failed I'll never know for sure what they had planned.

Re: CockroachDB beta-20161013

#108

Post by crudbug »

WhitneyLand wrote: post #24

Could the name actually slow the project's momentum? I only recently read some cool things about CDB and wondered if I could have been subconsciously skipping articles about it for deep seeded reasons like http://bbc.com/future/story/20140918-the-reality-about-roach... Of course anything good may eventually rise to success on its merits, but in case I'm not the only one with a subconscious aversion maybe the info bel…

Yes.. RoachDB sounds much better, if they want to continue with the same line of thought.

Re: CockroachDB beta-20161013

#109

Post by stickfigure »

hinkley wrote: post #102
qaq wrote: post #55

Earlier quoted context omitted.

Latency is one thing throughput is a different animal 2 reads/second per m3.large node that really forces one to think there are some severe architectural issues.

You're not wrong. Whoever downvoted you is pushing an agenda and I'm not happy about it. Reads per second is ultimately a measure of how many operations can be retired per second, not how long the operation takes. Anyone who has spent fifteen minutes learning about capacity planning should know that. 5 reads per second doesn't mean each read takes 200ms. It might mean 1 second per read spread across 5 threads of exec…

The parent poster (and many others in this thread) are assuming that performance under this deliberately pathological test is reflective of performance in the real world.

Optimistic locking systems inherently perform poorly under contention. But they also perform better than pessimistic concurrency systems overall because in the real world we design applications to avoid contention.

As an example, the Google App Engine datastore runs zillions of QPS across petabytes of data in a massive distributed cluster. But if you build an app that does nothing but mutate a single piece of state over and over, you'll top out at a couple transactions per second. This is painful if you're trying to build a simple counter, but with minimal care you can build a system that scales to any sized dataset and traffic volume.

Re: CockroachDB beta-20161013

#110

Post by SilasX »

finder83 wrote: post #25
WhitneyLand wrote: post #24

Could the name actually slow the project's momentum? I only recently read some cool things about CDB and wondered if I could have been subconsciously skipping articles about it for deep seeded reasons like http://bbc.com/future/story/20140918-the-reality-about-roach... Of course anything good may eventually rise to success on its merits, but in case I'm not the only one with a subconscious aversion maybe the info bel…

I agree completely. I love reading about databases, but apparently have been skipping reading about CockroachDB for that same reason subconsciously. I took a deep dive the other day and was amazed that I've seen the name dozens of times and have never bothered to ask what was special about it. It really is a fascinating database.

I had the same experience with Rust, for the same reason.
Post reply on HN