24 ms·

This gets a huge thumbs up from me. I've worked through a lot of the same reasoning as these people, and as technically correct as PAXOS might be, in the real

by socmag 10y ago

This gets a huge thumbs up from me. I've worked through a lot of the same reasoning as these people, and as technically correct as PAXOS might be, in the real world, causality at high frequency is a blur at best, and there is absolutely no need to impose the hard constraints that PAXOS and others imply. The only cases where guaranteed constraint systems are needed are when you don't have traffic and at each time step all parties are capable of asking each other to confirm that from all frames of reference they all agree who and why someone committed first. Which is great, but makes zero sense in the real world. At scale transactions are and should be committed on a best effort basis. You don't look at your bank account and wonder why the T-Mobile payment went out slightly after your ATM withdrawal. Why? Because... shrug. God said so. He works in mysterious ways. This is awesome. Sign me up.

MrBuddyCasino 10y ago
Maybe I didn't get it, but ordering is still guaranteed, it has just moved to the network layer and is kind of "hardware accelerared" by a smart switch or SDN node, or am I wrong?
- hardwaresofton 10y ago
  Ordering is definitely guaranteed -- it's the only thing that is, by this scheme (delivery is not, latency is unbounded). They provide 3 approaches in the paper: SDN node, programmed hardware, and software-only. Software-only approach lost some of the latency-gains, as might be expected.
  - MrBuddyCasino 10y ago
    Thanks, thats how I understood it. The tradeoffs are quite seductive, in my experience most companies do not operate their software on a scale where they really have to scale out, but they run multiple instances simply to increase availability. But then those are probably the same kind of companies that will probably not have the required network hardware, and won't for many years to come. I'm thinking about stuff like Redis or distributed caches like Hazelcast, maybe even Zookeeper and friends. Any ideas where this could shine? Cloud vendors could manage the hardware part, but is this model attractive to them, essentially being constrained to single-node performance?
    - hardwaresofton 10y ago
      I thought of mostly the same things (redis/some other database), maybe also IoT? This, in combination with the ultra low power wifi post that recently went up (https://news.ycombinator.com/item?id=13135607 https://news.ycombinator.com/item?id=13135607) seem like they would go together. I think cloud vendors would definitely charge a pretty high premium for this, since it requires more than zero work on their part. Also, aren't most simply-distributed databases constrained to single node performance (for writes, assuming one master)? I feel like you could work in fast reads to this scheme too, if you required replicas to have a complete log in order to respond to a read, since it's all or nothing. The possibility of a slightly (1 op) stale read is possible though.
lepacheco 10y ago
That's not what the paper is about. They still provide Consensus (i.e., total ordering).
jon-wood 10y ago
> You don't look at your bank account and wonder why the T-Mobile payment went out slightly after your ATM withdrawal. Your bank account isn't being used for even nearly the same things distributed data stores like this are being used for. And even then they have to make workarounds to ordering issues, otherwise if there were a day when my salary comes in and my rent went out I'd be hit with overdraft charges if they happened in the wrong order.
- ansible 10y ago
  For a while, banks were maliciously ordering such transactions, to create such scenarios. That's why I'm real cautious about debit cards.
  - function_seven 10y ago
    Yup. I don’t think they ever processed debits before credits in any given day. (The standard AFAIK has always been to process all credits first, then do the debits. This might be an antiquated understanding, though). But what they did do was to process the largest debit first, then the next largest, and so on. You have $100 in the account, and completed four transactions at $4, $8, $15, and $90? In that order? Too bad, 90 goes first, followed by three overdrafts.
  - tinco 10y ago
    You're cautious about debit cards? The only alternative being credit cards, where each transaction by definition is an overdraft? Maybe I'm getting this wrong, I'm from Europe where we don't really use credit cards. What fee are you talking about? If you use a debit card, and you don't have the money it will simply refuse the transaction right?
    - deleted 10y ago
      [deleted]
    - computerphage 10y ago
      No, they will charge you a fee called an overdraft fee for the "service" of allowing you to purchase the item. They basically extend you a small line of credit (there's some upper limit before they will deny the purchase) and then charge you, say, $35. Credit cards are always overdrawn in the sense that the bank has extended you a line of credit, but they don't have a fee associated with typical use.
pron 10y ago
You have misunderstood (as the title is a pun). It is "Say NO to Paxos Overhead", and is about a new Paxos invariant called NOPaxos (Network Ordering Paxos), that relies on code running in network switches to provide ordering. The same consensus guarantees apply -- in fact, it is still Paxos -- but the latency is significantly improved (and is within 4% of no replication at all). So it's Paxos with (almost) no overhead thanks to NO. You are also very mistaken about there being "no need" for consistency guarantees. Even systems that don't provide consistency for every data update, do enjoy consistency for some more rare events (like cluster membership). Without strong consistency at all, the range of distributed programs we can build is much reduced. The need for a greater range of distributed programs arises not from geographically separated applications (like ATMs), but from the mere fact that distributed computing is currently our only way to scale computational power (within that data center). If we cannot have consistent distributed computations, our computational power and the range of applications we can build in general would be greatly reduced.
- socmag 10y ago
  I was definitely NOt saying there is no need for consistency guarantees at all. I was saying that this is a much better way to do it.

by socmag 10y ago

MrBuddyCasino 10y ago

Maybe I didn't get it, but ordering is still guaranteed, it has just moved to the network layer and is kind of "hardware accelerared" by a smart switch or SDN node, or am I wrong?

hardwaresofton 10y ago
Ordering is definitely guaranteed -- it's the only thing that is, by this scheme (delivery is not, latency is unbounded). They provide 3 approaches in the paper: SDN node, programmed hardware, and software-only. Software-only approach lost some of the latency-gains, as might be expected.
- MrBuddyCasino 10y ago
  Thanks, thats how I understood it. The tradeoffs are quite seductive, in my experience most companies do not operate their software on a scale where they really have to scale out, but they run multiple instances simply to increase availability. But then those are probably the same kind of companies that will probably not have the required network hardware, and won't for many years to come. I'm thinking about stuff like Redis or distributed caches like Hazelcast, maybe even Zookeeper and friends. Any ideas where this could shine? Cloud vendors could manage the hardware part, but is this model attractive to them, essentially being constrained to single-node performance?
  - hardwaresofton 10y ago
    I thought of mostly the same things (redis/some other database), maybe also IoT? This, in combination with the ultra low power wifi post that recently went up (https://news.ycombinator.com/item?id=13135607 https://news.ycombinator.com/item?id=13135607) seem like they would go together. I think cloud vendors would definitely charge a pretty high premium for this, since it requires more than zero work on their part. Also, aren't most simply-distributed databases constrained to single node performance (for writes, assuming one master)? I feel like you could work in fast reads to this scheme too, if you required replicas to have a complete log in order to respond to a read, since it's all or nothing. The possibility of a slightly (1 op) stale read is possible though.

lepacheco 10y ago

That's not what the paper is about. They still provide Consensus (i.e., total ordering).

jon-wood 10y ago

> You don't look at your bank account and wonder why the T-Mobile payment went out slightly after your ATM withdrawal. Your bank account isn't being used for even nearly the same things distributed data stores like this are being used for. And even then they have to make workarounds to ordering issues, otherwise if there were a day when my salary comes in and my rent went out I'd be hit with overdraft charges if they happened in the wrong order.

ansible 10y ago
For a while, banks were maliciously ordering such transactions, to create such scenarios. That's why I'm real cautious about debit cards.
- function_seven 10y ago
  Yup. I don’t think they ever processed debits before credits in any given day. (The standard AFAIK has always been to process all credits first, then do the debits. This might be an antiquated understanding, though). But what they did do was to process the largest debit first, then the next largest, and so on. You have $100 in the account, and completed four transactions at $4, $8, $15, and $90? In that order? Too bad, 90 goes first, followed by three overdrafts.
- tinco 10y ago
  You're cautious about debit cards? The only alternative being credit cards, where each transaction by definition is an overdraft? Maybe I'm getting this wrong, I'm from Europe where we don't really use credit cards. What fee are you talking about? If you use a debit card, and you don't have the money it will simply refuse the transaction right?
  - deleted 10y ago
    [deleted]
  - computerphage 10y ago
    No, they will charge you a fee called an overdraft fee for the "service" of allowing you to purchase the item. They basically extend you a small line of credit (there's some upper limit before they will deny the purchase) and then charge you, say, $35. Credit cards are always overdrawn in the sense that the bank has extended you a line of credit, but they don't have a fee associated with typical use.

pron 10y ago

You have misunderstood (as the title is a pun). It is "Say NO to Paxos Overhead", and is about a new Paxos invariant called NOPaxos (Network Ordering Paxos), that relies on code running in network switches to provide ordering. The same consensus guarantees apply -- in fact, it is still Paxos -- but the latency is significantly improved (and is within 4% of no replication at all). So it's Paxos with (almost) no overhead thanks to NO. You are also very mistaken about there being "no need" for consistency guarantees. Even systems that don't provide consistency for every data update, do enjoy consistency for some more rare events (like cluster membership). Without strong consistency at all, the range of distributed programs we can build is much reduced. The need for a greater range of distributed programs arises not from geographically separated applications (like ATMs), but from the mere fact that distributed computing is currently our only way to scale computational power (within that data center). If we cannot have consistent distributed computations, our computational power and the range of applications we can build in general would be greatly reduced.

socmag 10y ago
I was definitely NOt saying there is no need for consistency guarantees at all. I was saying that this is a much better way to do it.