4 ms·

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

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.

pgaddict 10y ago
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.)
- gleenn 10y ago
  Not to offend, but "consistent on it's own" is a poor way to say "not consistent" in the way that matters.
  - pgaddict 10y ago
    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.
    - takeda 10y ago
      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.
icebraining 10y ago
Offtopic, but I find it funny how we use banks as the paramount example of a need for consistency, when they're actually not :)
- rantanplan 10y ago
  I would be interested if you could elaborate a bit.
  - chillax 10y ago
    perhaps refering to this? http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on-why-banks-are-base-not-acid-availability.html http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on...
  - DrJokepu 10y ago
    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.
    - djsumdog 10y ago
      Huh. So banks really couldn't use event sourcing could they? Oh maybe they could so long as every failure was a new event.
      - tmd83 10y ago
        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.

pgaddict 10y ago

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

gleenn 10y ago
Not to offend, but "consistent on it's own" is a poor way to say "not consistent" in the way that matters.
- pgaddict 10y ago
  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.
  - takeda 10y ago
    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.

icebraining 10y ago

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

rantanplan 10y ago
I would be interested if you could elaborate a bit.
- chillax 10y ago
  perhaps refering to this? http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on-why-banks-are-base-not-acid-availability.html http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on...
- DrJokepu 10y ago
  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.
  - djsumdog 10y ago
    Huh. So banks really couldn't use event sourcing could they? Oh maybe they could so long as every failure was a new event.
    - tmd83 10y ago
      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.