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

51–57 of 57 posts

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

#51

Post by stuki »

rch wrote: post #41
maaku wrote: post #32

Earlier quoted context omitted.

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.

And if two commands get stored in quick succession, such that the first results in a state that renders the second impossible? Particularly if some of the balance updates in the first command, are contingent on others ( credit line backing checking account updated if deposit balance Financial transactions are pretty much the poster child for atomic, multi update transactions and pessimistic locking.

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

#52

Post by dang »

Given that most of the comments are merely about the name, and that the author has implied that the software doesn't work [1], it seems there's little to discuss here. We're going to demote this submission [2].

1. https://twitter.com/andybons/status/472458545154494465. The answer to that question, btw, is yes. Reposts of stories that have had significant attention are treated as dupes for about a year.

2. That's not a criticism of the submitter. We want to see original work on HN. But there ought to be some substance to it, as well as to the resulting discussion.

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

#53

Post by strangemonad »

mahkoh wrote: post #49
enraged_camel wrote: post #45

Earlier quoted context omitted.

>>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.

and french

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

#54

Post by syntern »

stuki wrote: post #51
rch wrote: post #41

Earlier quoted context omitted.

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.

And if two commands get stored in quick succession, such that the first results in a state that renders the second impossible? Particularly if some of the balance updates in the first command, are contingent on others ( credit line backing checking account updated if deposit balance Financial transactions are pretty much the poster child for atomic, multi update transactions and pessimistic locking.

You can always save the fact that a transaction was started, read the account's state (including the most recent transactions as an ordered list), calculate the validity of the item, and update the success/failure accordingly.

It is not the transaction itself that is hard, it is the network partition. E.g. what happens if two network partition approve transactions, that wouldn't have been accepted if there were no partitions.

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

#55

Post by nawitus »

teraflop wrote: post #50
nawitus wrote: post #48

Earlier quoted context omitted.

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 dat…

Okay, so there will be conflicts, which brings us back to the original question.

>I would consider that "proper" replication in the sense of a replicated state machine.

When I think about proper replication, I'm thinking about master-master replication which doesn't fail if the connection between peers is sometimes down, even for very long periods (e.g. what CouchDB can handle). I'm of course not saying that other kinds of replications are somehow inherently bad, but multi-master replication without active connections is what I'm after and what a lot of modern applications can benefit from.

Once you have two databases that are not connected all the time you need to handle conflicts. You can move the conflict handling totally to the client side, but the conflict handling must be implemented somewhere. I think that's such a common use-case that the database should provide basic interfaces and implementation for it. If nothing else, it reduces boilerplate code by large amounts. Of course no database can handle conflict handling fully, as some of it always depends on the business domain.

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

#56

Post by rch »

stuki wrote: post #51
rch wrote: post #41

Earlier quoted context omitted.

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.

And if two commands get stored in quick succession, such that the first results in a state that renders the second impossible? Particularly if some of the balance updates in the first command, are contingent on others ( credit line backing checking account updated if deposit balance Financial transactions are pretty much the poster child for atomic, multi update transactions and pessimistic locking.

I've probably gotten off base here by wanting to perform arbitrary actions against services I may or may not control in the course of satisfying a command, and worrying too much about made up corner cases.

If this DB is the sole record of The Money, and I can move some quantity from X to Y in a transaction, then that's fine by me.

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

#57

Post by warfangle »

itsnotvalid wrote: post #19
warfangle wrote: post #13

Riak, when you use LevelDB behind it, certainly has indexes. As many as you want (within reason), through secondary indexes[0]. While it doesn't have joins specifically, you can link data blobs and walk the links[1]. For when that isn't quite enough, you can always perform a compiled erlang map reduce across a given dataset[2]. I don't quite see how CockroachDB offers anything Riak doesn't. Riak, while not offering t…

Multi Data Center Replication doesn't come in the free-lunch-pack. To get that with Riak, you probably need to downpay $6000 for getting that license for a node. So if you have two geolocations for your data, it would be at least $12000 for a minimal setup. Of course for people looking at the usage for this, money is not the major issue.

Very good point.
Post reply on HN