hyhac VS refound

When I was writing a Haskell client library for Hyperdex, another distributed kv store, I found it incredibly helpful to implement a simulator for correctness. This helped me identify which behavior was unspecified (arithmetic overflow: should error) or where my simulator deviated.

https://github.com/AaronFriel/hyhac/blob/master/test/Test/Hy...

Alas, I think Hyperdex development paused a few years later. It's a shame that it stopped then.

100%. I don't have the time to read the paper but online schema changes, with the ability to fail and abort the entire operation if one row is invalid, are basically the same problem as background index building.

If instead of using some generic K/V backend, it made use of specific FDB features, it might be even better. Conflict ranges and snapshot reads have been useful for me for some background index building designs, and atomic ops have their uses.

It is not necessary to store a version on each row. I can't remember why I did things this way, but https://github.com/srh/refound has no versions on persisted objects, has online background index building, and could do schema updates the same way. (That system doesn't have schemas.) When there is an active index build, incoming writes already read about active index build ranges and can participate in index building if it's interfering with their keys, to avoid starving it out if they're hammering the table with writes. So they know based on the ranges which keys have index entries. Adding versions would be sensible for performance reasons, and it would also minimize the occasions that writes have to read sindex build metadata while supporting this starvation mitigation.

> Oh yes, it also has a Raft implementation, so if you want multi-cluster FDB with Raft-driven failover you could do that too (iirc, FDB doesn't have this out of the box).

I don't know what you mean by this. Multiple FDB clusters?