Live data from Hacker News

CockroachDB beta-20161013

jepsen.io

171–180 of 213 posts

Re: CockroachDB beta-20161013

#171

Earlier quoted context omitted.

While you specialize in presumptuous ad hominem attacks against strangers on the internet. I like my vice better.

I can only go off what you wrote, stating you are deliberately ignorant. I was just reiterating what you proudly said. Do you really think saying you are a specialist, yet won't read about the topic you specialize in because you are scared of a benign name is reasonable? I forgot to mention the ridiculous hyperbole comparing 'cockroach' to racial slurs.

My point is that the name isn't benign. And my post was deliberately somewhat hyperbolic. I actually have read a bit about Cockroach, and if I saw a growing ecosystem that seemed relevant to my work, I would pursue it more.

But as others have pointed out, the name creates unnecessary conflict and discomfort. In a world of perfectly rational humans, it wouldn't matter. In the real world, it makes it harder to get stakeholders on board. That's why I made the comparison to ethnic slurs. "F_U_DB" might be the greatest storage system imaginable. It doesn't change the fact that the name alone is going to create extra unpleasant work. (EDITED to fix an error)

Re: CockroachDB beta-20161013

#172

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 submit "Bunker" as a more approachable name. Not only does it have the connotation of "survives nuclear bombardment", but also suggests "keep your stuff safe here" and "something you could entrust with your life".

The name "Bunker" also suggest that the developers are German nazis, since German nazis built a large amount of bunkers in Europe during WW2.

.. so probably not a good name either, at least not in Europe. ;-)

Re: CockroachDB beta-20161013

#173
post #12

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.

Hey man, didn't realize you left Stripe but did sort of notice Jepsen getting more serious. Jepsen has phenomenal reach:

Interesting and hilarious coverage of technical complexity which assumes just enough knowledge to engage a keen novice while seemingly engaging seasoned experts in the field.

Thanks for that. Your entertainment firm is a bit out if my wheelhouse, but it's such a crowded space and you end up getting really tied down. Maybe get acquihired for an Iditarod team, but I reckon this is more scaleable.

Posts are great. Tganks

Re: CockroachDB beta-20161013

#174

Earlier quoted context omitted.

My though exactly. It's already the case with faster DB. E.G: most projects my customers make me work on will never need scaling on multiple instances. They run really fast on a single postgres instance. One had some perf issues. First he just moved the DB to avoid having it on the same machine as the web server. Saved him a year. Then as the user base grew, he just bought a bigger server for the db. Right now it wor…

You do understand that scalability is more than just concurrent users right ? Maybe not ? There are many very small startups doing work in IoT, Analytics, Social, Finance, Health etc who have ridiculously challenging storage needs. Trying to vertically scale is simply not an option when you have a 50 node Spark cluster or 1M IoT devices all streaming data into your database. Vertically scaling your DB doesn't work as…

This is a very niche use case. The vast majority of projects have neither the user base to arrive to such numbers, no are they I/O challenged. Most companies are not facebook or google.

Plus if you manage to do 50 write sec on this DB, I don't see how you plan to scale anything with it. You are back to use good old sharding with load balancers.

Re: CockroachDB beta-20161013

#175
post #81

Earlier quoted context omitted.

Right now not really. Cockroach perf don't allow you do have a big dataset given the performances.

Can you elaborate on this point please? My reading of the article and docs is that perf is expected to scale linearly with the number of nodes (and therefore with dataset size).

Let's say you get 50 writes / sec per node. You need what, 1000 nodes to get to the playing fields of Postgres, with a simpler and cheaper setup ? Right now it's really not competitive, unless they improve the performance 1000 times. It makes no sense to buy and administrate many more machines to get the power you can have with one machine on another, proven tech.

Re: CockroachDB beta-20161013

#176

Earlier quoted context omitted.

Right now not really. Cockroach perf don't allow you do have a big dataset given the performances.

This statement makes absolutely no sense. Performance is very loosely correlated with dataset size and less so in most distributed NoSQL databases like CockroachDB.

At a given point in time yes, but to get this data set, you need to write it into the DB. Big datasets implies either you have been receiving data for very long of you did it quickly on a shorter period of time. It's usually the later. Which mean you need fast writes. 50 writes / sec is terrible, even more if to improve that you need to buy more servers while you 30 euros / months postgres instance can deal much more than that.

Re: CockroachDB beta-20161013

#177

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…

their name is the stupidest startup blunder I've ever seen. Enterprise won't go near it, seriously. I cannot tell a client I'm using a "cockroach" database, no fucking way. If we could go back and rename Windows Hitler would anyone be using it???

> If we could go back and rename Windows Hitler would anyone be using it???

That didn't take long. https://en.wikipedia.org/wiki/Godwin%27s_law

Re: CockroachDB beta-20161013

#178
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…

Are read-only transactions handled without contention? I understand that a read-write transaction needs to be aborted if a later conflicting write is committed. But read-only transactions can view a snapshot of what was committed before they begin - you trade a little bit of latency for being conflict free. It doesn't even have to be the default as long as you offer it as an option, you might want this if you know you are reading hot keys, or as a fallback if you've been aborted X times.

This was IMO the big innovation of true time in spanner - contention free reads at either now, or at some time in the past.

Re: CockroachDB beta-20161013

#179
post #57

Earlier quoted context omitted.

Agree 100%, ditto for suggested alternate name. I'd been doing the same for Rust. It's not a rational reason, sure, but I have to sell adoption to a broader userbase that cares about more that the technical merits. I don't want to have to make the case for why someone's system needs rust and cockroaches.

I have to say, I think that if you have a problem with "Rust" then you lose credibility in your criticism of "Cockroach". Contrary to most above, I think "Cockroach" is great. It's suitable. Any suit who has a problem with it should get back on their side of the office, and stop sticking their nose in things they know nothing about, especially when so evidently closed minded. There are too many people in that meeting…

If you want your product to extend from the cutting edge to the mainstream, you have to consider good naming.

Re: CockroachDB beta-20161013

#180

Earlier quoted context omitted.

Agree, the name is pretty off putting. Maybe they were trying to be funny? I don't know, but I would recommend changing it.

the level of bikeshedding on the name is crazy. I think it is a good name btw.

The amount of rejection this name evokes is considerable. Maybe they should think about branding, unless their target is to stay in the fringe.
Post reply on HN