A question about read-modify-write performance testing.

I've raised a related discussion in the RocksDB community - https://groups.google.com/g/rocksdb/c/LVAIgW8rR6k.

In "Read Modify Write Benchmarks(https://github.com/facebook/rocksdb/wiki/Read-Modify-Write-Benchmarks)", you use MergeRandom and UpdateRandom for comparison. But is there a fundamental difference in the semantics of the two operations?
The steps RocksDB take to use UpdateRandom are:
1.Read a random key
2.Write a new value to the random key

In the Counter example you gave, its semantics are fundamentally different from MergeRandom . Because the new value written using UpdateRandom has no relationship to the value read, which is different from Merge (the semantics of the Merge in Counter is: the value written is the value read + 1).

This problem may not be apparent in Counter example.Considering the StringAppendOperator,if we use this MergeOperator, the semantics of MergeRandom will make the size of the value continuously increase, but the semantics of UpdateRandom will not continuously append the value, so the size of the value will remain unchanged.

If the different semantics of MergeRandom and UpdateRandom are within your expectations, what is the point of comparing them? In my opinion, it is as meaningless as the comparison between read and write (an exaggeration example). If their different semantics are not what you expected, should it be fixed? Some good approaches came to my mind, like adding a benchmark called RMWRandom, in which case the new value written is a value relative to the previously read value. Or modify the code of your UpdateRandom to make its semantics more suitable for read-modify-write.