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

CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore

github.com

Post reply on HN
Print view View original

41–50 of 57 posts

Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore

#41

Post by rch »

maaku wrote: post #32
rch wrote: post #28

Earlier quoted context omitted.

Riak will have strongly consistent buckets in 2.0+, which pretty much takes care of the cases in which I'd need guarantees for data in this storage model.

Consistency of single updates is vastly different than multi-write atomic transactions. The former precludes, for example, financial applications which require atomic updates of multiple balances.

Clearly, but I would just be using Riak to store the single command that indicates an update of multiple balances should be scheduled. Given sound guarantees at that level, I'll be able to implement the transaction myself in any number of ways, inclusive of interop with external services.

Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore

#42

Post by bdevine »

orasis wrote: post #27

Change the name. I get the joke, but it has an emotionally negative connotation that bosses will hate.

That's the first thing I thought. If anybody from the team is looking, how about something like BlattoDB[0]?

[0] http://en.m.wikipedia.org/wiki/Blattaria

Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore

#43

Post by notduncansmith »

bdevine wrote: post #42
orasis wrote: post #27

Change the name. I get the joke, but it has an emotionally negative connotation that bosses will hate.

That's the first thing I thought. If anybody from the team is looking, how about something like BlattoDB[0]? [0] http://en.m.wikipedia.org/wiki/Blattaria

Sounds a lot like "blotto", which is the last state I want my DB in.

Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore

#45

Post by enraged_camel »

maaku wrote: post #20
candybar wrote: post #15

As for the name, which I agree is problematic as is, how about EntomoDB for entomos (insect)? Edit: It's not problematic if success is not an objective. But if it is, choosing a name with such strong established negative connotations is not wise.

How is the name problematic? I knew exactly what they were saying and why when I saw it. If it were me I would have shortened it to RoachDB, but that's just marketing.

>>How is the name problematic?

Most people are disgusted by cockroaches. I think that's a good enough reason to change the name, at least if you want the product to be taken seriously.

Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore

#46

Post by increment_i »

limsup wrote: post #2

I assume it's called this because a cockroach can supposedly survive a nuclear attack. But it's a bad name. It does not invoke good feelings.

Gotta agree. Cringe inducing name when you first hear it, but I imagine it would become less so as you worked with it more and more. You'd be desensitized to it after a while I'd imagine.

Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore

#47

Post by bdevine »

notduncansmith wrote: post #43
bdevine wrote: post #42

Earlier quoted context omitted.

That's the first thing I thought. If anybody from the team is looking, how about something like BlattoDB[0]? [0] http://en.m.wikipedia.org/wiki/Blattaria

Sounds a lot like "blotto", which is the last state I want my DB in.

True, true. But the point still stands that there are options which hint at the durability of cockroaches without invoking disgust!

Actually this all does remind me of research on the tangible effect of disgust on products -- see [0]. That work studied physical contact, but it's easy to extrapolate from there.

[0] https://faculty.fuqua.duke.edu/~gavan/bio/GJF_articles/conta...

Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore

#48

Post by nawitus »

teraflop wrote: post #17
nawitus wrote: post #14

How does it handle replication and the resulting conflicts?

It uses strongly consistent replication, so there are no conflicts.

So it doesn't support "proper" replication, e.g. the kind where the databases are not connected 100% the time perfectly? And I wonder how they can prevent conflicts due to latency.. Even if there's a 50ms latency, is the other database going to wait for 50ms between every write or something?

Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore

#49

Post by mahkoh »

enraged_camel wrote: post #45
maaku wrote: post #20

Earlier quoted context omitted.

How is the name problematic? I knew exactly what they were saying and why when I saw it. If it were me I would have shortened it to RoachDB, but that's just marketing.

>>How is the name problematic? Most people are disgusted by cockroaches. I think that's a good enough reason to change the name, at least if you want the product to be taken seriously.

Friendly reminder that "Mongo" is a very offensive word in German. A "Mongo" is a person suffering from Down syndrome. CockroachDB is a walk in the park compared to MongoDB.

Re: CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore

#50

Post by teraflop »

nawitus wrote: post #48
teraflop wrote: post #17

Earlier quoted context omitted.

It uses strongly consistent replication, so there are no conflicts.

So it doesn't support "proper" replication, e.g. the kind where the databases are not connected 100% the time perfectly? And I wonder how they can prevent conflicts due to latency.. Even if there's a 50ms latency, is the other database going to wait for 50ms between every write or something?

Well, that's a matter of terminology. It uses quorum replication, so it can make progress as long as a majority of replicas are online and communicating. I would consider that "proper" replication in the sense of a replicated state machine.

You're right that it's different from, say, master/slave replication in an SQL database. There's no distinction between an authoritative master and a slave that provides stale data. Each machine either gives you consistent reads and writes, or is unavailable.

As far as latency goes, the gory details are in the design document. You need to talk to at least N/2 other replicas; there's no way around that without giving up consistency. But that doesn't mean you can only do one transaction every 50ms; they can be pipelined, and non-conflicting transactions can proceed simultaneously.

Post reply on HN