Comment by baq | Hacker News Reader

Comment by baq | Hacker News Reader

Parent Full thread

It's not immediately clear for me when to use BDR and when would I choose XL. Can somebody do a quick comparison? I like this quote in the announcement email:

---

IS Postgres-BDR RIGHT FOR YOU?

BDR is well suited for databases where:

- Data is distributed globally

- Majority of data is written to from only one node at a time (For example, the US node mostly writes changes to US customers, each branch office writes mostly to branch-office-specific data, and so on.)

- There is a need for SELECTs over complete data set (lookups and consolidation)

- There are OLTP workloads with many smaller transactions

- Transactions mostly touching non overlapping sets of data

- There is partition and latency tolerance

However, this is not a comprehensive list and use cases for BDR can vary based on database type and functionality.

In addition, BDR aids business continuity by providing increased availability during network faults. Applications can be closer to the data and more responsive for users, allowing for a much more satisfying end-user experience.

---

But I can't seem to find something similar for XL and especially a diff between the two.

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.

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