When we started working on our initial product, I was very interested in putting a newish distributed data store named Riak through its paces. It's a pretty solid piece of technology, but also somewhat new, so when we started down that road, I was far from convinced that we'd stick with it. And sure enough, we recently switched from Riak to MySQL. This is a brief tale of how that came about.
The good
Riak generally performs as advertised on the label: it's a bare-bones distributed key/value store, with little extra. It behaves quite solidly and predictably.
The not-so-good
What drove us to switch away from Riak was a mismatch that emerged between our needs and what it currently offers. Like many applications, we internally deal with not one, but a large number of collections of data, so we need to be able to manipulate those collections efficiently. The executive summary is that Riak does not currently provide a way to do this, so we were forced to drop it, at least for now.
The slightly longer version of this story is that the usual way to manage a collection is via an index. Riak supports exactly one index, which is by object name. The Riak engineering team is working on support for secondary indices, but I only found out about this by accident (if I were them, I'd be clarifying my public roadmap), and it's not clear when secondary indices will be available or whether they'll perform well.
It's possible to emulate a secondary index in Riak by storing a collection of object names as an object in its own right, but this is intrinsically slow due to the indirection it introduces, and managing a collection quickly becomes a bottleneck if it must be updated frequently. The first chart below tells the story: it illustrates the cost of adding an item to a collection as the collection grows in size. The blue line represents a hand-maintained secondary index in Riak, and ignore the others for now (they're what we're doing instead; read on).
That looks a little uncomfortable, but it's hardly surprising: our "hey, let's fake a secondary index" approach gets slower as the collection grows. The overall effect of those increasing costs should make us squirm some more: check out the blue line in the cumulative chart below. This shows the passage of time as we successively add items to a collection.
That's far from the kind of performance curve you can comfortably ship with.
Our initial response
As an initial proof of concept, we switched from Riak to MySQL, using the Haskell HDBC library to talk to MySQL. This improved our performance dramatically, since we can use MySQL's indices to manage our collections. MySQL can of course incrementally update an index, and this incrementality is really the part that's critical to predictably decent performance for our application.
I would be untroubled by Riak being much slower than MySQL (which it is) if I could manage collections with it. It has enough other nice operational features (and I've been burned in production enough times by MySQL) that it still looks pretty attractive. I'll be quite interested to follow Basho's work on secondary indices.
What we did next
The HDBC library (the green lines in the charts above) has been around quite a long time, and it's a little long in the tooth. I am unthrilled by a few aspects of working with it: its performance is poor; its API isn't particularly easy to use; and it's too easy to write code that's vulnerable to SQL injection attacks.
As a result, I wrote the mysql-simple library, which addresses all three issues:
- Performance: simply switching from HDBC to mysql-simple improved the overall performance of our application by 50%. That's a big deal!
- Ease of use: the amount of DB-related code in the application dropped by 30%, and the code became easier to write and to read.
- Security: the library intentionally makes it difficult to construct arbitrary query strings, and automatically performs safe quoting of data.
And because no good thing should be enjoyed alone, we've released this library under the liberal 3-clause BSD license. Enjoy!
