pmuellr is Patrick Mueller

other pmuellr thangs: home page, twitter, flickr, github

Friday, January 11, 2008

why couchdb

Someone asked me today what I thought value proposition was behind CouchDb. Here goes.

  • It's a non-relational database. I've ranted on this before. Not like relational databases don't have have their place, but the fact of the matter is that so many people are familiar with them today, that they've become the first tool many people look at when trying to solve a persistance problem. I'm always happy to see conceptually simpler database tools get some attention, because not every problem needs a relational database.

  • It's a schema-free database. Now, you've heard me rant about how important I think schema is for things like JSON and REST, so now you're no doubt confused about why I would claim a schema-challenged database is good. The problem with schema in most relational databases is that it's terribly brittle. It's painful to deal with. Not terribly portable. Schema has a place in the world, but at the lowest level of the database, it seems like it just gets in the way. At the very least, I think it'll be interesting to see how much trouble the lack of schema for this semi-structured database causes.

  • It's a web server. W00t! My database driver is my HTTP client. Almost every language has a decent HTTP client library baked in. Almost.

  • Erlang with it actor-ish programming model. Getting some traction right on the eve of our multi-core future. The nice thing about this particular usage of Erlang is that I think it's in the exactly perfect spot. The engine. Which you never see. You'll see other languages (JavaScript, et al), but in general the Erlang is all under the covers.

  • JSON. I need not say more.

  • A 'stored procedure'-ish language, that's actually a real language. A simple and powerful language. JavaScript. And other languages, if you wish.

  • Designed for distributed usage.

  • Seems like classic disruptive innovation.

  • It's a web server and a database. And to me, this is the most interesting point. Just as we've seen client programs start to embed web browsing technology (like iTunes), there's really no reason why server programs like a database shouldn't be able to embed a web server. It's obviously a convenience factor (single install). It also has some potential nice performance aspects as the path-length between the server and the database is greatly, greatly shortened.

Let's noodle on that last point a bit more; it's a server AND a database. Now, whenever I see "server", I immediately ask the question - can I write a web app for that thing? Or is it just serving read-only documents up? Check the REST APIs. Read/write web, folks. But, there are some caveats. JSON objects are trivial to store in the database behind a simple URI, but anything else (something that's not JSON), needs to be stored as an 'attachment' for some JSON object. The raw data of the attachment is available at a particular fugly-ish URI, of the form:


Fugly, but possible.

What does all this mean? Well, it means you could, say, serve up HTML out of your CouchDb database, that could be rendered in a browser. Which might include some JavaScript (inline, or referenced as another 'attachment'), which could then read/write objects in the database. A self-contained app inside an app server. Oh yeah, the data for the app is stored there to.

That's the theory anyway. I intend to practice this weekend.

BTW, for any Mac folk that want to install CouchDb to play, I recommend installing it from MacPorts via:

sudo port install icu erlang couchdb
sudo cp /opt/local/Library/LaunchDaemons/org.couchdb.couchdb.plist  /Library/LaunchDaemons/
sudo launchctl load -w /Library/LaunchDaemons/org.couchdb.couchdb.plist 

The first command installs the icu package, then erlang, then couchdb. The last two commands launch CouchDb, and arrange to have it started at every boot. From memory, I think I had to do these after the port install, but I could be wrong; perhaps the port install did them for you. In any case, there's no harm in running those commands again.

As a quick check to make sure CouchDb is running, either open your browser on the following url: http://localhost:5984/_utils/index.html, or run the command, which should provide the short JSON object below:

$ curl localhost:5984
{"couchdb": "Welcome", "version": "0.7.2"}


JanL said...

Heya Patrick,
this is a fantastic writeup, thanks a lot!

I've got two small comments. The REST API for attachments (the "other data" beside JSON) is still in flux. It will look more like /database/attachment_doc/foo.txt being more RESTful and all.

Second, I'd like to point to *cough* my small tutorial Programming CouchDB with Javascript which neatly illustrates the look-ma-no-middleware concept of the Browser talking directly to CouchDB.

Thanks again,

grantmichaels said...

Thank You for the write-up, I learned a couple of things I wasn't aware of re: CouchDB - good stuff!