News for hackers. Stuff that matters.

A comment on Consistency Without Clocks: FaunaDB's Distributed Transaction Protocol. Parent comment

Re:Consistency Without Clocks: FaunaDB's Distributed Transac... by jchanimal on Friday October 19, 2018 @02:10PM (#18258704)
The log segments committed by FaunaDB contain batches of transactions, which means our throughput is constrained not by our consensus protocol, but rather by conflicts as transactions are resolved. The benchmarked 3300 transactions/second mentioned is for complex transactions with dozens of reads and writes. Additionally, read-only transactions are not run through the transaction pipeline, since they can be served consistently with low latency from replicas using FaunaDB's snapshot storage.

More important for most applications than theoretical benchmarks is taking a sound approach and using a database you can depend on. Asking your development team to manage isolation is going to introduce more costs than benefits, except in the most specialized of circumstances.

FaunaDB's model is always ACID, so you never have to guess what's in the database, even in the presence of region failures or other anomalies.

[ Parent | on HN ]
Re:Consistency Without Clocks: FaunaDB's Distributed Transac... by jamesblonde on Friday October 19, 2018 @02:19PM (#18258776)
We built HopsFS on NDB, not CalvinDB, because we needed performance for cross-partition transactions. Some workloads need it. In the filesystem workload, when FS path components are normalized and stored on different partitions, practically all transactions cross partitions. So if you serialize them, then writing a file in /home/jchan will block writing a file in /home/jim. This is what most distributed filesystems already do - have a global write lock on the filesystem metadata. I like having the freedom to build my the concurrency model on top of READ_COMMITTED, as i can squeeze out 16X performance improvemnts by doing so (ref: https://www.usenix.org/conference/fast17/technical-sessions/... )
[ Parent | on HN ]
Re:Consistency Without Clocks: FaunaDB's Distributed Transac... by evanweaver on Friday October 19, 2018 @03:26PM (#18259287)
Sure, if you don't care about serializability, you don't need to pay consensus costs to enforce it, but you will be subject to read and write skew.
[ Parent | on HN ]
Re:Consistency Without Clocks: FaunaDB's Distributed Transac... by notacoward on Saturday October 20, 2018 @11:54PM (#18266659)
> This is what most distributed filesystems already do - have a global write lock on the filesystem metadata

Absolutely untrue. Stop lying about other systems.

[ Parent | on HN ]
Re:Consistency Without Clocks: FaunaDB's Distributed Transac... by jamesblonde on Friday October 19, 2018 @02:29PM (#18258854)
I should add that when you don't serialize cross-partition transactions, you have the hard problem of system recovery - transaction coordinators need to reach consensus on a consistent set of transactions to recover. Here's NDB's protocol for doing so: NDB’s solution to this problem was only published this year in Mikael Ronstrom's book on MySQL Cluster : https://drive.google.com/file/d/1gAYQPrWCTEhgxP8dQ8XLwMrwZPc...
[ Parent | on HN ]
Re:Consistency Without Clocks: FaunaDB's Distributed Transac... by jamesblonde on Friday October 19, 2018 @02:46PM (#18258979)
I should add that it is not correct to say 'our throughput is constrained not by our consensus protocol'. A trivial example would be a workload of transactions, where each transaction has at least two non-conflicting writes on different partitions. FaunaDB will serialize those transactions, and you will bottleneck on the consensus protocol - compared to NDB.
[ Parent | on HN ]
Re:Consistency Without Clocks: FaunaDB's Distributed Transac... by ummonk on Sunday October 21, 2018 @12:51PM (#18268849)
What he's saying is that the throughput number they mention is constrained by transaction conflicts. The limit for non-conflicting transactions allowed by the consensus protocol is no doubt much higher.
[ Parent | on HN ]
Re:Consistency Without Clocks: FaunaDB's Distributed Transac... by mcguire on Friday October 19, 2018 @05:24PM (#18260172)
Can you partition your batch transactions, so that all up to the conflict succeed?
[ Parent | on HN ]
Re:Consistency Without Clocks: FaunaDB's Distributed Transac... by jchanimal on Friday October 19, 2018 @06:15PM (#18260494)
My understanding is yes, we commit to the log in batches, but abort conflicts at the transaction level. So only the conflicts have to suffer the retry loop, everything else is durably committed.
[ Parent | on HN ]