3 ms·
The first CRDTs have been remarkably impractical, e.g. WOOT[0]. These days, state-of-the-art CRDT databases are not much different from your regular LSM perform
by gritzko 1y ago
The first CRDTs have been remarkably impractical, e.g. WOOT[0]. These days, state-of-the-art CRDT databases are not much different from your regular LSM performance-wise. For example, RDX CRDTs[1,2] are all implemented by a merge-sort-like algorithm, pure O(N). Metadata overheads have been tamed in most implementations.
[0]: https://github.com/el10savio/woot-crdt https://github.com/el10savio/woot-crdt
[1]: https://github.com/gritzko/librdx https://github.com/gritzko/librdx
[2]: https://github.com/gritzko/go-rdx https://github.com/gritzko/go-rdx
- meindnoch 1y ago>For example, RDX CRDTs No affiliation, right?
- gritzko 1y agoI am the author of RDX. I let others brag about thier implementations.
- sgarland 1y agoDo you have benchmarks at scale, ideally compared to other store / DB implementations? I’ve seen other CRDT libraries using Postgres (inadvisedly) bring it to its knees due to the massive amount of chattiness and updates.
- gritzko 1y agoRDX works as a merge operator inside virtually any LSM database. It is strictly O(N), so almost every LSM db benchmark would be relevant here. There is an RDX-specific LSM engine BRIX, but that one is good for its Merkle properties. Chotki is basically Pebble.