| Edited to say I'm a Basho employee and did a lot of the development work on CRDTs in Riak. Also, Hi! You can use any CRDT implementation you want from the client. You can roll your own, or you can use riak_dt, or some other library. Indeed using a 3rd party CRDT library with Riak should be trivial, since conflicts are exposed to the user. Though there aren't many out there (yet?) Writing your own Ad Hoc merge logic is somewhat more complex. Shapiro et al describe it as "complex, and error prone" in their CRDT paper. Google's F1 paper says: "We also have a lot of experience with eventual consistency systems at Google. In all such systems, we find developers spend a significant fraction of their time building extremely complex and error-prone mechanisms to cope with eventual consistency" and "Designing applications to cope with concurrency anomalies in their data is very error-prone, time- consuming, and ultimately not worth the performance gains." Building CRDTs into Riak is an attempt to mitigate this. I don't think CRDTs built in to Riak will "save the world" but hopefully, for a portion of application developers, or potential developers, on Riak, built in CRDTs will make data modelling easier. It will, I hope, allow these developers to focus on their application, and not conflict resolution, when working with Riak. Built in CRDTs are a step towards maturity for EC systems, I'm pretty excited about this work and think it opens up a lot of possibilities. If you find making a general purpose, reusable library of state based CRDTs trivial, please send Basho a CV. |