Number of nodes and links
siculars at gmail.com
Sat May 15 20:12:26 EDT 2010
Chests in the presumably "Chest" bucket sounds like the container where all the contention will take place. What you describe would almost certainly require a bucket with allow_mult=true and entail an enormous amount of transactional detection within your application and each of your players (clients) be uniquely named (X-Riak-ClientId).
What I would do in this scenario is pre-compute all those chest objects (it sounds like your'e already doing that) but put them in redis. In fairness, I do not know if Riak is where you want to do all that stuff. I would make each chest a key in redis as a set containing keys to all the individual items within that chest. Just pop the items off the set as requests come in. Redis guarantees atomic set operations. Once the client has it's loot key, just fetch it out of riak. If you absolutely insisted on using riak here, you would probably have to touch the loot item in the loot bucket by locking it somehow or flagging it as taken if you weren't confident in your transactional/chest locking solution.
I would continue to use riak as your long-term persistent data-store but in this specific use case I believe Riak is not the appropriate solution. Also, redis would be at least an order of magnitude faster.
On May 15, 2010, at 7:33 PM, Chris Hicks wrote:
> First of thank you for the responses.
> As far as the HTTP interface I don't plan on using that but will be connecting directly through Erlang, so that 8kb limit for that specific case, as far as I understand, won't affect me as much. I would like to get to understand the conflict handling a bit better as in my case I know that this is going to be something I will need to pay particular attention to.
> I'd like to spell out a scenario that shows how I understand the process to work so that you guys can tell me I have it or I'm totally off base. To start let me say that the project I'm working on is a game, so imagine a chest with a number of items in it which is little more than a chest object with links to the specific items contained in the chest.
> Player 1, Player 2 and Player 3 all decide to take something from the chest at the exact same time. They all retrieve version 0 (using version for simplicity) of the chest object from the DB. Player 1's connection/processing is lightning fast and they finish, updating the chest document to version 1. Player 2 & 3 finish at the same time and both try to update the chest document in the database, except that it has now changed and so there is a conflict. Now as far as I understand it you can tell the DB to return both versions and let the program handle it. Does that mean that both Player 2 and Player 3 will get version 1 of the document back along with their proposed modified version?
> If that is the case it seems like I could, if I plan for it from the beginning, simply restart the processing for Player 2 and Player 3 with version 1 acting like the original document. In this way I could make sure that actions taken from a player are done, more-or-less, in a first come first serve basis. If the above is true does it matter how many revisions the document has undergone, as far as what is returned after a conflict?
> By that I mean what happens if Player 4 tries to get something out of the chest at the same time as the other 3, only for some reason their processing is very very slow and Players 1, 2 and 3 all finish up completely and the chest document is at version 3 when player 4 tries to submit their document back to the D. Does Player 4 get version 3 of the document back along with their own proposed modified document?
> How close am I as far as how the DB handles this?
> Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. Learn more.
More information about the riak-users