4 ms·

Explain how you can have availability in the face of network partitions and a perfect total ordering to events (ie: the sequentiality you claim.)

jamesaguilar 14y ago
Presumably they sacrifice availability? If your network is only partitioned 1/1000 of the time and you only need 99.9% uptime, that would be a viable approach.
DanWaterworth 14y ago
You can use Paxos. There will be some partitions that can cause an outage, but this is only the case when there is no majority of nodes that can communicate with each other, which in practice means you are exposing yourself to a vanishingly small risk.
- aaronblohowiak 14y ago
  3 rounds of communication to reach consensus for every transaction? Off the cuff, it seems like that would hinder the performance. I haven't tested it, though..
  - DanWaterworth 14y ago
    It doesn't have to be per transaction, it could be for a batch of transactions. There are also optimizations like multi-paxos that can reduce the number of round trips.
sausagefeet 14y ago
http://cs-www.cs.yale.edu/homes/dna/papers/calvin-sigmod12.pdf http://cs-www.cs.yale.edu/homes/dna/papers/calvin-sigmod12.p...
- surrealize 14y ago
  That system works by giving up interactive transactions. But the foundationdb page claims to have interactive transactions, so it must be doing something else. From Abadi's blog: http://dbmsmusings.blogspot.com/2012/05/if-all-these-new-dbms-technologies-are.html http://dbmsmusings.blogspot.com/2012/05/if-all-these-new-dbm... Calvin requires all transactions to be executed fully server-side and sacrifices the freedom to non-deterministically abort or reorder transactions on-the-fly during execution. In return, Calvin gets scalability, ACID-compliance, and extremely low-overhead multi-shard transactions over a shared-nothing architecture. The comments on that post are pretty interesting, too. And from the foundationdb features page: http://foundationdb.com/#features http://foundationdb.com/#features FoundationDB transactions are true interactive sessions, unlike distributed databases that require stored procedures. This means that client code can make an iterative series of reads and writes over the network to execute complex transactions.
  - sausagefeet 14y ago
    Thank you for clarifying. I don't know much about DBs and the Calvin paper is the only one I'm aware of that addressed the commenters question.

jamesaguilar 14y ago

Presumably they sacrifice availability? If your network is only partitioned 1/1000 of the time and you only need 99.9% uptime, that would be a viable approach.

DanWaterworth 14y ago

You can use Paxos. There will be some partitions that can cause an outage, but this is only the case when there is no majority of nodes that can communicate with each other, which in practice means you are exposing yourself to a vanishingly small risk.

aaronblohowiak 14y ago
3 rounds of communication to reach consensus for every transaction? Off the cuff, it seems like that would hinder the performance. I haven't tested it, though..
- DanWaterworth 14y ago
  It doesn't have to be per transaction, it could be for a batch of transactions. There are also optimizations like multi-paxos that can reduce the number of round trips.

sausagefeet 14y ago

http://cs-www.cs.yale.edu/homes/dna/papers/calvin-sigmod12.pdf http://cs-www.cs.yale.edu/homes/dna/papers/calvin-sigmod12.p...

surrealize 14y ago
That system works by giving up interactive transactions. But the foundationdb page claims to have interactive transactions, so it must be doing something else. From Abadi's blog: http://dbmsmusings.blogspot.com/2012/05/if-all-these-new-dbms-technologies-are.html http://dbmsmusings.blogspot.com/2012/05/if-all-these-new-dbm... Calvin requires all transactions to be executed fully server-side and sacrifices the freedom to non-deterministically abort or reorder transactions on-the-fly during execution. In return, Calvin gets scalability, ACID-compliance, and extremely low-overhead multi-shard transactions over a shared-nothing architecture. The comments on that post are pretty interesting, too. And from the foundationdb features page: http://foundationdb.com/#features http://foundationdb.com/#features FoundationDB transactions are true interactive sessions, unlike distributed databases that require stored procedures. This means that client code can make an iterative series of reads and writes over the network to execute complex transactions.
- sausagefeet 14y ago
  Thank you for clarifying. I don't know much about DBs and the Calvin paper is the only one I'm aware of that addressed the commenters question.