"unlike Google Percolator, FoundationDB, or similar systems, FaunaDB places no constraints on replica distance and is practical to deploy at global internet latencies"
"For each batch of parallel transactions, they are inserted into a distributed, write-ahead transaction log"
"Replicas must achieve consensus for how to insert new transactions into the log. FaunaDB uses an optimized Raft implementation to achieve consensus."
There are constrains on running consensus across the world (Raft), it adds at least 200 ms to serialize txs. Also higher latency means longer interval between hearbeats and hence longer downtime if leader is isolated - known issue of leader based consensus protocols (see "There Is More Consensus in Egalitarian Parliaments" paper[1] or "In search of a simple consensus algorithm" post[2])
Google's Percolator doesn't depend on global consensus but just on global TSO (timestamp oracle) which is possible to implement in a way:
- it doesn't suffer from leader isolation (no leader)
- doesn't have bottleneck (each node handles requests)
- doesn't touch disk on each request
details in the "Quorum clock: leaderless distributed clock" post[3].
"For each batch of parallel transactions, they are inserted into a distributed, write-ahead transaction log"
"Replicas must achieve consensus for how to insert new transactions into the log. FaunaDB uses an optimized Raft implementation to achieve consensus."
There are constrains on running consensus across the world (Raft), it adds at least 200 ms to serialize txs. Also higher latency means longer interval between hearbeats and hence longer downtime if leader is isolated - known issue of leader based consensus protocols (see "There Is More Consensus in Egalitarian Parliaments" paper[1] or "In search of a simple consensus algorithm" post[2])
Google's Percolator doesn't depend on global consensus but just on global TSO (timestamp oracle) which is possible to implement in a way:
- it doesn't suffer from leader isolation (no leader)
- doesn't have bottleneck (each node handles requests)
- doesn't touch disk on each request
details in the "Quorum clock: leaderless distributed clock" post[3].
[1] https://www.cs.cmu.edu/~dga/papers/epaxos-sosp2013.pdf
[2] http://rystsov.info/2017/02/15/simple-consensus.html
[3] http://rystsov.info/2018/10/01/tso.html