I'm not so sure. Have the latencies claimed by FoundationDB been measured on multi-key transactions?
And if you need these guaranties, it seems like "Most of these operations can be implemented on top of the existing RAMCloud features". I would expect it to be possible to implement that and stay well withing the latency budget, provided that a single-key durable write is 100 times faster.
The writes we are measuring are individual keys, modified atomically in transactions of 20 keys at a time. So this test is doing 14 million writes per second as 720 thousand transactions per second.
Comments
I'm not so sure. Have the latencies claimed by FoundationDB been measured on multi-key transactions?
And if you need these guaranties, it seems like "Most of these operations can be implemented on top of the existing RAMCloud features". I would expect it to be possible to implement that and stay well withing the latency budget, provided that a single-key durable write is 100 times faster.
All of the transactions in the test noted in the blog are multi-key transactions. (20 key updates)
When claiming the 14.4MHz number, is that per 20-key update? Or a single key update in the 20-key update? And what's the latency on the 20-key update?
The writes we are measuring are individual keys, modified atomically in transactions of 20 keys at a time. So this test is doing 14 million writes per second as 720 thousand transactions per second.
Multi-key transactions means coordination. Coordination is not cheap. You'll be paying a hefty cost somewhere.