CouchDB on Ubuntu

I’ve been meaning to play around with couchDB lately, and finally took the time to get it installed on my Linux VM at home running Ubuntu Server 7.10. I ran into a few problems while getting the thing to compile, so I figured I’d outline them here.

First, look at the instructions in the INSTALL file, or at the wiki. They’ll give you a good starting point — especially for all the development tools you’ll need to begin compiling things (automake, libtool, etc. — Ubuntu doesn’t install these by default). If you’re running a headless machine (like my VM) without X, however, you won’t want to install the erlang meta-package, as this will install a bunch of X related crap. And you can’t just install erlang-base, since this won’t give you everything you need, as evidenced by a failing make (trust me).

Now, before you go and search the Internet and decide that you should compile erlang from source — hardly an attractive option — keep reading. The silver bullet is that you need the erlang-nox package (that’s “no X”, not some form of nitrous oxide). The description is very vague, but it’s apparently a bunch of erlang stuff that doesn’t require X11. I also installed erlang-dev, since the description made it sound important (i.e., I’m not sure if it’s required).

Hopefully this helps somebody else.

3 Comments so far

  1. Matt on December 28th, 2007

    I did some looking, and get what it is and what it does, but I’m not entirely sure why you’d want to use it. Is it faster?

    Maybe I’m old-school, but SQL seems to do the job well.

  2. andrew on December 31st, 2007

    But all the cool people are using it!

    Seriously, I’m not 100% sure why it’s gaining all this press, which is part of the reason I wanted to play around with it. And after the cursory look that I’ve given it… I’ve gained no additional insight.

  3. andrew on December 31st, 2007

    One advantage is that the flat structure makes it easy to combine multiple types of documents into a single index. If you were doing this in an RDBMS, you’d probably have a table for each type of document, and would have to do some futzing to get a combined list. With Couch’s insight into the JSON objects you’re (presumably) storing, you can create

    For instance, if you were trying to optimize pulling a list of blog posts in chronological order, you’d probably start off by adding an index to the date. MySQL’s BTree indexes are stored in sorted order, so you’ve now reduced a sort to a straight read from the index.

    If you wanted to add blog posts and photos, though (in separate tables), you’d have to do additional work to interlace the results into a single sorted list. While not quite as strenuous as a completely out of order list, it’s still additional work.

    But CouchDB also stores its indexes in sorted order, and you could create an index that contains both the blog posts and the photos. Now you’re back to a single index scan.

    In addition, you can modify the information contained in a document without worrying about having to change the underlying schema, which, when you start talking about large tables, could be a significant advantage.

    On the other hand, there seem to be serious drawbacks, at least in its current form. For instance, it doesn’t appear that old document revisions (a new revision is created with every modification) are ever deleted; your database just continues to grow and grow. (Looks like the best they have currently is a PHP script which creates a copy of the entire database, document by document, and then deletes the old one.)

    While it may be interesting to play with, I’m not sure its anywhere near ready for a real application.

Leave a Reply