Hacker News Reader

Comment by brian_cloutier | Hacker News Reader

I'm by no means authoritative, but XL lets you distributed postgresql and keep the transactionality. That's great if you're a bank but necessarily slow and not Available, so running it over a wan might be a bad idea.

BDR lets you distribute your database but throws transactionality out of the window. You have two independent databases which stream changes to each other. A lot faster, and well suited for wans, but not Consistent.

View on HN

Offtopic, but I find it funny how we use banks as the paramount example of a need for consistency, when they're actually not :)

I have worked in FSIs and the DBAs I met were absolutely paranoid about consistency and durability of writes to core banking databases. Curiously it was atomicity and isolation that took a back seat, errors due to those would be corrected by applications (or by hand in exception processing) with reversing transactions.

I would be interested if you could elaborate a bit.

Banks basically don't use database transactions to record financial transactions. Instead, failed operations are rolled back with an inverse operation. It's done this way to ensure that there is an audit trail of every operation, rolled back or not.

Huh. So banks really couldn't use event sourcing could they? Oh maybe they could so long as every failure was a new event.

I would assume that banks can be the best enterprise profile user of event sourcing. For traditional application we use the DB rollback for failure mitigation and banks are actually explicitly doing that. I think the event is already there and they are essentially using the same concept as event sourcing if I'm not mistaken.

And I think its much easier to make it work. There is a lot of associated domain and logic but the core of banks is a series of transactions (never worked so could be completely wrong) .. source, destination, amount. It looks poster child for event sourcing/log based architecture.

perhaps refering to this? http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on...

XL has a global transaction manager, keeping the whole cluster consistent as a whole, and allows you to query the whole database for analytics, etc.

BDR on the other hand doesn't have such global component, so each node is consistent on it's own, but the nodes may be at slightly different states. Still, the replicated changes are applied transactionally (i.e. you won't see just a partial update from another node, etc.)

Not to offend, but "consistent on it's own" is a poor way to say "not consistent" in the way that matters.

Well, if you're looking for a solution where the whole cluster is perfectly/strongly consistent, then BDR is not for you I guess. What BDR gives you is a guarantee that the changes are applied atomically (i.e. matching transactions from the source node), and in the commit order. But there's no global consistency guarantee - that's a consequence of of the asynchronous behavior.

Over WAN you pretty much can't make things consistent. Well... I suppose you can, but it will be really slow due to speed of light.

Reply on news.ycombinator.com