Day 30: Riak
This is it, folks. For the final stop on this tour, I took a look at Riak, another entry in the NoSQL race. It feels most similar to MongoDB with its use of JSON to store documents and ability to execute map-reduce functions written in Javascript, though the documentation refers to it as a key-value store, which would put it closer to Redis. Unlike CouchDB, installing Riak with Homebrew went off without a hitch. With that finished, I headed to the project homepage and opened the Getting Started guide. It showed how to start the Riak server and make a basic query using cURL. That it can be accessed via HTTP using a RESTful interface as well as with native Erlang is one of my favorite features of Riak.
After that, I opened the doc page outlining Riaks’s entire REST API and played around with storing, retrieving, and deleting my own documents, which all worked about as expected. Then I opened the Riak Fast Track, and worked through that. I thought it was especially cool that you can store binary data (e.g. an image) in Riak and then retrieve it with a web browser, though maybe I’m easily impressed.
Once I felt like I had a good handle on basic Riak functionality, I took a look at Ripple, the Riak Ruby library written by Sean Cribbs, a local developer. Ripple depends on a number of libraries that I don’t use on a daily basis, so I had to do some RVM wrangling to get everything working. The library has two parts (from the docs):
riak-clientcontains a basic wrapper around typical operations, including bucket manipulation, object CRUD, link-walking, and map-reduce.ripplecontains an ActiveModel-compatible modeling layer that is inspired by ActiveRecord, DataMapper, and MongoMapper.
Both libraries work well. Ripple has support for ActiveRecord-style has_many relationships using embedded documents. I spent some time reading through the source, and I especially liked its extensive use of tap, a method I was aware of but tend to underuse in favor of returning.
Riak is very cool. I stand by my earlier assertion that it feels more like Mongo than Redis, mainly because it seems like it’s intended to be an application’s primary data store. That it’s built to scale up quickly and easily is compelling, but I think it needs to do more to differentiate itself from the rest of the NoSQL pack.
