Re: First Write Wins
After some asking around, I suspect that any activity on the immutability front will have to wait until we've rolled strong consistency capabilities into Riak. Scott Fritchie pointed out something I hadn't considered: even with pw/pr values, it's still possible to end up in an inconsistent state after a partition heals, because a pw write that fails will still result in the new value being written to secondary vnodes. If you write to the "wrong" side of a partition, the write will report to the client as a failure (assuming pw=2) but the values will still be sitting on secondary vnodes waiting for handoff, at which point they would overwrite the primary vnode values, assuming the timestamps dictate that. So if you want to do this in Riak, you definitely should plan on siblings and client resolution, but I think your best bet is going to be to use a different solution than Riak for this part of your system. It's simply not a good fit when you need something approximating strong consistency. -John On May 19, 2013, at 10:44 PM, Jeremy Ong wrote: > Thanks and yes, for the case of the user creation example I gave, I am > setting pw=pr=quorum. > > Immutable values is a much better way of putting it, although I technically > need deletion as well for this particular example. > > Cheers, > Jeremy > > > On Sun, May 19, 2013 at 7:24 PM, John Daily wrote: > A few quick thoughts... > > We're tackling a very similar problem (perhaps even the identical problem) > with user accounts in Riak CS via the Stanchion subsystem. I know that > started out as a component running on a single node to avoid conflicts like > this, but I believe it is evolving into a more sophisticated solution. > > This feels like a feature request for allowing keys to be created with > immutable values. I would assume that topic has arisen before, but I'm not > aware of when or whether it's something we've seriously considering > implementing. > > Certainly one would have to be careful with sloppy quorums: in the event of a > network partition, with default settings it would be possible to create > identical keys on different parts of the cluster without an immediate > conflict. You should make certain the primary vnodes are always required by > specifying pw=quorum and pr=quorum (which would mean that attempting to write > the same key in a partitioned scenario would fail unless a majority of the > primary vnodes are reachable). > > Hopefully someone else who's given this some thought in the past will jump > in; I'll make further inquiries tomorrow. > > -John Daily > Technical Evangelist > > On May 19, 2013, at 7:29 PM, Jeremy Ong wrote: > >> For automatic conflict resolution, often times, the easiest thing to do is >> impose a Last Write Wins policy. >> >> However, in certain circumstances, First Write Wins makes more sense. For >> example, suppose you are handling user creation. Creating a single user will >> populate values for two keys: >> >> User Id => User data >> Username => User Id >> >> A unique User Id is generated to accommodate future username changes. In the >> event that another user attempts to create an account simultaneously with >> the same username, a conflict will exist. The easiest thing for me to do >> here, is after the account is created, check the username to see if it >> points to the correct User Id. If so, return a success message. Otherwise, >> rollback changes to the first key. >> >> I'm OK with last write wins for now, but is there a way of imposing a simple >> first write wins policy without needing siblings and client conflict >> resolution? >> >> Cheers, >> Jeremy >> ___ >> riak-users mailing list >> riak-users@lists.basho.com >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Re: First Write Wins
Thanks and yes, for the case of the user creation example I gave, I am setting pw=pr=quorum. Immutable values is a much better way of putting it, although I technically need deletion as well for this particular example. Cheers, Jeremy On Sun, May 19, 2013 at 7:24 PM, John Daily wrote: > A few quick thoughts... > > We're tackling a very similar problem (perhaps even the identical problem) > with user accounts in Riak CS via the Stanchion subsystem. I know that > started out as a component running on a single node to avoid conflicts like > this, but I believe it is evolving into a more sophisticated solution. > > This feels like a feature request for allowing keys to be created with > immutable values. I would assume that topic has arisen before, but I'm not > aware of when or whether it's something we've seriously considering > implementing. > > Certainly one would have to be careful with sloppy quorums: in the event > of a network partition, with default settings it would be possible to > create identical keys on different parts of the cluster without an > immediate conflict. You should make certain the primary vnodes are always > required by specifying pw=quorum and pr=quorum (which would mean that > attempting to write the same key in a partitioned scenario would fail > unless a majority of the primary vnodes are reachable). > > Hopefully someone else who's given this some thought in the past will jump > in; I'll make further inquiries tomorrow. > > -John Daily > Technical Evangelist > > On May 19, 2013, at 7:29 PM, Jeremy Ong wrote: > > For automatic conflict resolution, often times, the easiest thing to do is > impose a Last Write Wins policy. > > However, in certain circumstances, First Write Wins makes more sense. For > example, suppose you are handling user creation. Creating a single user > will populate values for two keys: > > User Id => User data > Username => User Id > > A unique User Id is generated to accommodate future username changes. In > the event that another user attempts to create an account simultaneously > with the same username, a conflict will exist. The easiest thing for me to > do here, is after the account is created, check the username to see if it > points to the correct User Id. If so, return a success message. Otherwise, > rollback changes to the first key. > > I'm OK with last write wins for now, but is there a way of imposing a > simple first write wins policy without needing siblings and client conflict > resolution? > > Cheers, > Jeremy > ___ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
Re: First Write Wins
A few quick thoughts... We're tackling a very similar problem (perhaps even the identical problem) with user accounts in Riak CS via the Stanchion subsystem. I know that started out as a component running on a single node to avoid conflicts like this, but I believe it is evolving into a more sophisticated solution. This feels like a feature request for allowing keys to be created with immutable values. I would assume that topic has arisen before, but I'm not aware of when or whether it's something we've seriously considering implementing. Certainly one would have to be careful with sloppy quorums: in the event of a network partition, with default settings it would be possible to create identical keys on different parts of the cluster without an immediate conflict. You should make certain the primary vnodes are always required by specifying pw=quorum and pr=quorum (which would mean that attempting to write the same key in a partitioned scenario would fail unless a majority of the primary vnodes are reachable). Hopefully someone else who's given this some thought in the past will jump in; I'll make further inquiries tomorrow. -John Daily Technical Evangelist On May 19, 2013, at 7:29 PM, Jeremy Ong wrote: > For automatic conflict resolution, often times, the easiest thing to do is > impose a Last Write Wins policy. > > However, in certain circumstances, First Write Wins makes more sense. For > example, suppose you are handling user creation. Creating a single user will > populate values for two keys: > > User Id => User data > Username => User Id > > A unique User Id is generated to accommodate future username changes. In the > event that another user attempts to create an account simultaneously with the > same username, a conflict will exist. The easiest thing for me to do here, is > after the account is created, check the username to see if it points to the > correct User Id. If so, return a success message. Otherwise, rollback changes > to the first key. > > I'm OK with last write wins for now, but is there a way of imposing a simple > first write wins policy without needing siblings and client conflict > resolution? > > Cheers, > Jeremy > ___ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
First Write Wins
For automatic conflict resolution, often times, the easiest thing to do is impose a Last Write Wins policy. However, in certain circumstances, First Write Wins makes more sense. For example, suppose you are handling user creation. Creating a single user will populate values for two keys: User Id => User data Username => User Id A unique User Id is generated to accommodate future username changes. In the event that another user attempts to create an account simultaneously with the same username, a conflict will exist. The easiest thing for me to do here, is after the account is created, check the username to see if it points to the correct User Id. If so, return a success message. Otherwise, rollback changes to the first key. I'm OK with last write wins for now, but is there a way of imposing a simple first write wins policy without needing siblings and client conflict resolution? Cheers, Jeremy ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
