Consistency Without Clocks: FaunaDB's Distributed Transaction Protocol
1–10 of 105 posts
Re: Consistency Without Clocks: FaunaDB's Distributed Transaction Protocol
#2Re: Consistency Without Clocks: FaunaDB's Distributed Transaction Protocol
#3We're here, ready for your questions to be consistently replicated across the WAN at the lowest latency information science allows ;-)
My understanding is you're essentially shipping a "stored procedure" to the database where every input and condition is known up-front.
It seems like a reasonable trade-off for lowering the latency of WAN transactions, but it might make application development more complicated.
Re: Consistency Without Clocks: FaunaDB's Distributed Transaction Protocol
#4We're here, ready for your questions to be consistently replicated across the WAN at the lowest latency information science allows ;-)
Has the lack of interactive transactions and only supporting entirely deterministic transactions been a big issue for your customers? My understanding is you're essentially shipping a "stored procedure" to the database where every input and condition is known up-front. It seems like a reasonable trade-off for lowering the latency of WAN transactions, but it might make application development more complicated.
Most read/modify/write cycles end up being essentially that, but with the added confusion of local application threading and standard library. We eliminate that, but preserve the general ability to express a complex query in application code (which also increases application concurrency since the database executes transactions with maximum parallelism.)
Transactions do not have to be pre-registered as stored procedures.
Re: Consistency Without Clocks: FaunaDB's Distributed Transaction Protocol
#5Re: Consistency Without Clocks: FaunaDB's Distributed Transaction Protocol
#6We're here, ready for your questions to be consistently replicated across the WAN at the lowest latency information science allows ;-)
Has the lack of interactive transactions and only supporting entirely deterministic transactions been a big issue for your customers? My understanding is you're essentially shipping a "stored procedure" to the database where every input and condition is known up-front. It seems like a reasonable trade-off for lowering the latency of WAN transactions, but it might make application development more complicated.
If you want to see a query with precondition checks etc, the code at the end of this post is another example: https://fauna.com/blog/distributed-ledger-without-the-blockc...
Re: Consistency Without Clocks: FaunaDB's Distributed Transaction Protocol
#7As an aside, can somebody explain the constraints FoundationDB puts on replica distance?
In the discussed proposal datacenter failure is considered an extraordinary event with major performance implications, which is different than a global "write anywhere, read anywhere" multi-datacenter partitioned log model like Fauna.
Re: Consistency Without Clocks: FaunaDB's Distributed Transaction Protocol
#8Any plans to have Jepsen / Aphyr conduct a rigorous test and write a report on the results?
Re: Consistency Without Clocks: FaunaDB's Distributed Transaction Protocol
#9Re: Consistency Without Clocks: FaunaDB's Distributed Transaction Protocol
#10This looks like a fascinating approach. Unfortunately I’m not well versed enough to intelligently compare it to alternatives. Any plans to have Jepsen / Aphyr conduct a rigorous test and write a report on the results?