A few weeks ago I blogged about implementing optimistic concurrency control using the Dynamo clone storage engines. I need to give an update to this technique that is specific to Riak.
Riak supports an "if-match" header that allows you to implement OCC out of the box. The only quirk with this technique—per my understanding—is that it is single-node based. In other words, if I have two concurrent writers that are updating a particular value and they are operating against two different nodes, the "if-match" header doesn't offer true OCC protection. With two concurrent writers against two different nodes we will still end up with two versions of the same value. I need to confirm this 100% with the Basho guys. Specifically, I need to verify if this still holds true in a quorum setting: W > N / 2.
Supposing the above statement to be true, the easiest way to implement OCC would be to direct writes to a single "master" node. But that would severely affect our write performance and would effectively simulate a MySQL master/slave configuration, which we are trying to avoid because we want write availability and write performance.
Instead, what if we still adopted the "write to any, read from any" style? But instead of directing the writes to any random node, we used a deterministic formula to elect a master on a per-request basis, e.g. a modulo on the primary key. In this way, we could easily scale out the writes through this multi-master topology while still maintaining the ability to read from any node. Furthermore, we would still realize all of the benefits of optimistic concurrency.
Somewhere Werner is smiling. [Well, at least he's not crying.]