> If you don't have reproducible, fair benchmarking, you can be blinded by your own hubris. Our contributors and maintainers depend on benchmarks to ensure that as we strive to improve TiDB, we don't negatively impact its performance. To us, not having benchmarks is like not having logging or metrics.
> In a write skew anomaly, two transactions (T1 and T2) concurrently read an overlapping data set (e.g. values V1 and V2), concurrently make disjoint updates (e.g. T1 updates V1, T2 updates V2), and finally concurrently commit, neither having seen the update performed by the other. Were the system serializable, such an anomaly would be impossible, as either T1 or T2 would have to occur “first”, and be visible to the other. In contrast, snapshot isolation permits write skew anomalies.
FoundationDB has a workaround, but I don't know how well that works in practice.
> In TiDB, you can use SELECT … FOR UPDATE statement to avoid write skew anomaly. In this case, TiDB will use locks to serialize writes together with MVCC to gain some of the performance gains and still support the stronger “serializability” level of isolation.
Serializability is more expensive of course, since the database needs to track what was read and not only what was modified. It is possible to achieve this in a distributed database, FoundationDB is one example that supports it.
https://tikv.org/deep-dive/distributed-transaction/isolation...
