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

151–160 of 213 posts

Re: CockroachDB beta-20161013

#151

Post by zzzcpan »

dijit wrote: post #123

I wish everyone would stop bikeshedding the damn name. From my perspective I'm glad something that's trying to do this is coming into existence. a couple years ago I was given the arduous task of ensuring that we never lost data. One of the requirements was that: At any time, any server can (and will) fail.. if you acknowledge that you have data then you MUST never lose it. You cannot imagine how many database soluti…

"We settled on postgresql, because, despite going into toast tables and having to implement sharding on top"

This is a common mistake. The choice doesn't actually guarantee consistency at all. PostgreSQL only guarantees consistency as long as you don't try to communicate with it over a network, which you obviously do if you have shards. To address this problem we have things like 2pc, but they aren't very useful for an RDBMS on their own without the whole infrastructure of a distributed database.

Re: CockroachDB beta-20161013

#152

Post by andrewchambers »

renegadesensei wrote: post #138
andrewchambers wrote: post #98

Earlier quoted context omitted.

You seem to specialize in willful ignorance and bike shedding to me.

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.

Re: CockroachDB beta-20161013

#153

Post by ysleepy »

So I assume this means cockroachDB currently (probably) meets its promised consistency levels. How does it compare to the usual default settings of PostgreSQL for example? - I think you get SERIALIZABLE, so the behaviour should be very reasonable.

I understand the txn/s numbers are in a pathological scenario, but will these transactions block the whole db from moving faster or have unrelated transactions still normal throughput?

I'm just glad we get linearizable single keys, I had to switch to HBase because it was the only choice at the time. Cassandra did not even give me read-your-own-writes. HBase also had issues while testing on the same host, delete+write lead to deletes being reordered after the writes because they had the same timestamp.

I'm a bit disappointed from HN in this post, everyone only talks about the name. But 90% probably did not even read the article. Aaanyway, heres my 2cents: https://cr.yp.to/cdb.html is CDB for me :P - so better choose another acronym!

Re: CockroachDB beta-20161013

#154

Post by ahachete »

sametmax wrote: post #68
hinkley wrote: post #49

Earlier quoted context omitted.

What I found out the hard way is that there's a qualitative difference between 'can' and 'must' here that causes a lot of problems with the development cycle. When the project can no longer fit onto a developer's box it changes a bunch of dynamics and often not for the better. Lots of regressions slip in, because developers start to believe that the glitches they see are caused by other people touching things they sh…

Plus I found that people using MongoDB tend to not formalize their data schema because the tool doesn't enforce it. But they do have a data schema. Only: - it's implicit, and you have to inspect the db and the code to understand it. - there is no single source of truth, so any changes better be backed up by unit tests. And training is awkward. If some fields/values are rarely use, you can easily end up not knowing ab…

> - it's implicit, and you have to inspect the db and the code to understand it.

Or run ToroDB Stampede [1] and look at the generated tables manually or via other tools like Schema Spy [2].

[1] https://www.torodb.com/stampede/

[2] http://schemaspy.sourceforge.net/

(warning: I'm a ToroDB dev)

Re: CockroachDB beta-20161013

#155

Post by dijit »

zzzcpan wrote: post #151
dijit wrote: post #123

I wish everyone would stop bikeshedding the damn name. From my perspective I'm glad something that's trying to do this is coming into existence. a couple years ago I was given the arduous task of ensuring that we never lost data. One of the requirements was that: At any time, any server can (and will) fail.. if you acknowledge that you have data then you MUST never lose it. You cannot imagine how many database soluti…

"We settled on postgresql, because, despite going into toast tables and having to implement sharding on top" This is a common mistake. The choice doesn't actually guarantee consistency at all. PostgreSQL only guarantees consistency as long as you don't try to communicate with it over a network, which you obviously do if you have shards. To address this problem we have things like 2pc, but they aren't very useful for…

The networking isn't a problem if you only acknowledge a write when the underlying database says so. You could have a write succeed before you crash. But you won't lose an acknowledged write.

Re: CockroachDB beta-20161013

#156

Post by p4lindromica »

Perignon wrote: post #126
dijit wrote: post #123

I wish everyone would stop bikeshedding the damn name. From my perspective I'm glad something that's trying to do this is coming into existence. a couple years ago I was given the arduous task of ensuring that we never lost data. One of the requirements was that: At any time, any server can (and will) fail.. if you acknowledge that you have data then you MUST never lose it. You cannot imagine how many database soluti…

It's not bikeshedding. Who the fuck wants to work for a company called Cockroach Labs? Seriously, sure your tech friends and recruiters might appreciate it on your resume but anyone outside of tech? Applying for an apartment, mortgage, car, lol good luck. And also not too sure that anyone outside the immediate tech/startup nerd scene would appreciate it other. That aside why the hell do I want to thing of cockroaches…

"Who the fuck wants to put their bikes in a magenta shed?"

Re: CockroachDB beta-20161013

#157

Post by Perignon »

dijit wrote: post #130
Perignon wrote: post #126

Earlier quoted context omitted.

It's not bikeshedding. Who the fuck wants to work for a company called Cockroach Labs? Seriously, sure your tech friends and recruiters might appreciate it on your resume but anyone outside of tech? Applying for an apartment, mortgage, car, lol good luck. And also not too sure that anyone outside the immediate tech/startup nerd scene would appreciate it other. That aside why the hell do I want to thing of cockroaches…

Nobody is going to give a flying fuck what your company is named on a mortgage application. Honestly there are companies with _much_ worse names in active use like "Dick & Daughters"[0] or "Ismail ANUS"[1] who even got an appointment to the queen. Seriously, it's bikeshedding, and the point of the DB is that you don't think about it all day. I also don't think of women called Cassandra when I use the database of the…

Dick & Daughters or Ismael ANUS are definitely not more vile then Cockroach. The former are names rooted in tradition, not some idea of a an arrogant hipster joke. To call a company Cockroach is fucken arrogance. Plain and Simple.

Re: CockroachDB beta-20161013

#158

Post by Gigablah »

tshannon wrote: post #97
irfansharif wrote: post #69

I'm disappointed with the commentary here, I for one would think the discussions around building a distributed system with the consistency guarantees claimed here would be far more interesting than the name of said system.

The name may just be low hanging fruit to comment on if one has nothing else to add to the conversation.

I think it's hilarious that people are up in arms about the name but apparently something like MongoDB is fine.

Re: CockroachDB beta-20161013

#159

Post by jpgvm »

ysleepy wrote: post #153

So I assume this means cockroachDB currently (probably) meets its promised consistency levels. How does it compare to the usual default settings of PostgreSQL for example? - I think you get SERIALIZABLE, so the behaviour should be very reasonable. I understand the txn/s numbers are in a pathological scenario, but will these transactions block the whole db from moving faster or have unrelated transactions still normal…

I don't believe CockroachDB provides SERIALIZABLE consistency for the entire keyspace, rather for subsets of the keyspace that reside in the same Raft cluster.

In practice this means no cross key serializability without including a serialization token in transactions.

I may be mistaken however but that is my understanding from reading CockroachDB docs and Aphyrs post.

Re: CockroachDB beta-20161013

#160

Post by p4lindromica »

justicezyx wrote: post #112
irfansharif wrote: post #69

I'm disappointed with the commentary here, I for one would think the discussions around building a distributed system with the consistency guarantees claimed here would be far more interesting than the name of said system.

People care about CDB raises one of the most prominent and easiest fixable problem. I see 0 problem of this.

Just like you think you can fix my shed by painting it yellow, right?
Post reply on HN