The Downside of Crowdsourcing
Update: After only 3 hours of uptime, I took my Riak server down. It was hacked (whitehat, thankfully) by Aphyr. I love you, Internets. I’d say how he did it, but he’s promised to do a write-up. I don’t want to spoil the fun.
Update 2: Well, here’s the fun.
I actually did this: http://databevy.com:8098. Feel free to play… explore! Just please keep the penis pics to a minimum.
People ask what I find so intriguing about Riak, especially in light of its considerable downsides and I find it hard to answer. It’s not merely its architecture, or tweakable consistency, but the fact that it speaks web more than any database out there. All interaction is an HTTP request or response (like the web) - in the truest sense of the word all. Sure, at its heart Riak is just a key/value store, in the same way that at its core The Beatles were just a band. Riak keys values by URL (like the web). Values are just base64 encoded data (like the web), meaning that if you store an image with a MIME type of jpeg, you GET the URL, and Riak returns a jpeg.
You point out that other DBs have HTTP interfaces, but it’s not the same. I can’t hit a URL in Couch and get anything other than a document, even if I encoded an image inside… it still requires some intermediary to decode that image and get the juicy picture underneath (although, to be fair, Couch has built-in this intermediary, called inline attachments. But let’s be clear… it is a workaround. The web doesn’t operate on the “attachment” principle). Riak has no such decoding, because it knows fuckall about documents. Actually, let me back up… Riak did know nothing of documents as of two weeks ago. The new 1.0 release has support for secondary indexes, so pushing in JSON data means you can query that data directly. So… I guess I should scratch a “downside” off the list (Though, to throw a bone to Couch, Riak’s understanding of documents is very, very weak by comparison).
- crudcomic posted this