Deeper Dive Into Riak

I was able to devise a strategy today for how my Tic Tac Toe library can provide persistance using Riac. The basic idea is that when a new game is created, I store the game as a new “key” in a “games” bucket. I already have a game history object as an attribute of each game, so that I can keep track of the moves made in the game so far. The “games” bucket then will contain a list of all games as “keys”, which can be accessed by simply doing a dump of all the “keys” in my “games” bucket. This will allow any interface to provide the user with a list of previously played games. If the user wants to view a previously played game, the interface just needs to send a message back to the library asking for the game at the associated “key”. Since I’m serializing a game object when I create a new “key”, then when I retrieve that key, the game object is deserialized and the interface can simply display the game information to the user. It’s a very simple idea that doesn’t take advantage of many of Riac’s interesting features, but in the context of the user story this is for, the more advanced features of Riac don’t apply.

I was curious though about some of Riac’s other features, and how it provides availability and manages consistency across a cluster of nodes. So I spent time reading through Riac’s documentation to get a better handle on how it achieves consistency, and discovered some interesting things.

When a cluster of nodes is joined together to create a Riac ring-cluster, each node by default is given an “N value” of 3. This means that when a node is written to, the data is written to three other nodes in the ring-cluster. Riac is able to resolve out of date nodes by comparing a key’s vclock value, which is a value Riac creates that is used to determine which data is more recent. In many cases Riac is able to resolve out of sync data by simply comparing the vclock values of two keys on two separate nodes. The more recent vlock value is considered to be the more recent value.

For reading data and ensuring a certain level of consistency, Riac also offers the configuration of “R values”. A R value represents the minimum number of nodes from a cluster-ring that are read from when a Riac query is performed. If there is an R value of 3, then that means when a read query is issued to a cluster-ring, three nodes will be queried for that key’s data. If the keys are found to be incongruous, the vclock value is used automatically by Riac by default to manage the conflict.

I was also intrigued by the idea of “Link Walking”. This is where a relative link (since Riac offers an HTTP API for querying the ring-cluster) is set as a property of a key at the time of writing. If a link is provided, then it is possible to retrieve a key, read it’s link, and go to that key either in the same bucket or a different bucket. This is a powerful feature, because it allows for a “relational” feel between keys and buckets, depending on the use case. Unfortunately the Ruby Riac client doesn’t seem to have much support for link walking at this time, and gauging on the commit history, it appears that the gem is not being actively maintained. Perhaps at some point in the future, it would make for a fun open source project to contribute to - and work on providing link walking as a more developed feature of the Ruby Riac client.

Today was also amazing because I got to visit Table XI for their monthly Pecha Kucha talks. Pecha Kucha is a style of presenting in which a presenter uses 20 slides, and each slide is displayed for 20 seconds. This gives each presenter about 7 minutes to present anything they want. The format is engaging because it forces the presenter to move quickly and the audience is treated to a new image every 20 seconds. What was particularly fun about the Pecha Kucha talks today was that the two founders of Pecha Kucha were visiting Table XI and they both gave Pecha Kucha talks. It was interesting to learn about the history of Pecha Kucha, and the other talks given by the presenters were excellent. In the future, I think it would be great to see some Pecha Kucha talks at 8th Light!

After the talks, I was able to lay down some specs for my persistance class, and then I paired with a new novice apprentice named Kelly. I walked her through the basic structure of my Tic Tac Toe library and how the Rails, Command Line and Limelight interfaces talk with the core library. We also talked about an approach I was using to pass back game history for a game object using a hash of hashes, and why that’s generally a bad idea. We came up with a solution that instead passes an array of move history objects back to the interfaces. I was happy with that approach, it simplified the process, and made it much easier for the interfaces to work with the data.