6 ms·
(I work on Deno KV) A read-modify-write retry loop causes a high number of commit conflicts, e.g. for atomic increments on integers. Getting higher than 1/RTT
by losfair 2y ago
(I work on Deno KV)
A read-modify-write retry loop causes a high number of commit conflicts, e.g. for atomic increments on integers. Getting higher than 1/RTT per-key throughput requires the "backend" to understand the semantics of the operations - apply a function to the current value, instead of just checking whether timestamp(value) < timestamp(txn.start) and aborting commit if not.
- ec109685 2y agoWhy not funnel all writes to a single region and leverage simpler transaction semantics.
- losfair 2y agoDistributed consensus + fsync() determines the lower bound on commit latency. We have to wait for the data to be durable on a quorum of transaction logs before returning success for a transaction. That's usually 5-10ms, even within a single region.
- pstuart 2y agoA small tangent on the subject of databases on top of FDB -- mvsqlite is such an insanely cool project and it looks like it's gone quiet. Any plans to pursue that further? For those that haven't seen it, SQLite on top of FoundationDB: https://github.com/losfair/mvsqlite https://github.com/losfair/mvsqlite