Download the 64bit Linux binaries from here and unzip the contents to /usr/local.

cd /tmp
wget http://fastdl.mongodb.org/linux/mongodb-linux-x86_64-1.8.1.tgz
sudo tar -zxf /tmp/mongodb-linux-x86_64-1.8.1.tgz -C /usr/local

Setup some symbolic links.

sudo ln -s /usr/local/mongodb-linux-x86_64-1.8.1 /usr/local/mongodb
sudo ln -s /usr/local/mongodb/bin/bsondump /usr/local/bin/bsondump
sudo ln -s /usr/local/mongodb/bin/mongo /usr/local/bin/mongo
sudo ln -s /usr/local/mongodb/bin/mongod /usr/local/bin/mongod
sudo ln -s /usr/local/mongodb/bin/mongodump /usr/local/bin/mongodump
sudo ln -s /usr/local/mongodb/bin/mongoexport /usr/local/bin/mongoexport
sudo ln -s /usr/local/mongodb/bin/mongofiles /usr/local/bin/mongofiles
sudo ln -s /usr/local/mongodb/bin/mongoimport /usr/local/bin/mongoimport
sudo ln -s /usr/local/mongodb/bin/mongorestore /usr/local/bin/mongorestore
sudo ln -s /usr/local/mongodb/bin/mongos /usr/local/bin/mongos
sudo ln -s /usr/local/mongodb/bin/mongosniff /usr/local/bin/mongosniff
sudo ln -s /usr/local/mongodb/bin/mongostat /usr/local/bin/mongostat

The first “ln -s” above sets up a handy symbolic link between the versioned mongodb folder and its unversioned counterpart. When 10Gen release updates, say version 1.8.2, all you need to do is download, unzip, and link the ’1.8.2 mongodb folder’ to the unversioned folder and ‘hey presto’ everything should just work.

To get an init script working cleanly with this setup, download mine from my Github ‘dotfiles’ repo. Please note – my init script enables journaling and the REST interface (on line 51).

wget https://github.com/ijonas/dotfiles/raw/master/etc/init.d/mongod
sudo mv mongod /etc/init.d/mongod
sudo chmod +x /etc/init.d/mongod

You’ll need to add a mongodb user and prep some folders

sudo useradd mongodb
sudo mkdir -p /var/lib/mongodb
sudo mkdir -p /var/log/mongodb
sudo chown mongodb.mongodb /var/lib/mongodb
sudo chown mongodb.mongodb /var/log/mongodb

Also, you need to activate your MongoDB service’s init script by adding it to your system’s run-level configuration. That way the service will startup during the boot sequence and stop nicely during the OS’ shutdown procedure.

sudo update-rc.d mongod defaults

Lastly to launch MongoDB

/etc/init.d/mongod start

Good luck!

UPDATE: Since April 6 Ubuntu now has prefabbed packages containing MongoDB 1.8.1, maintained by 10Gen. See the instruction below.

apache, opensource, documents, metadata, database, json, javascript, REST, addressability, horizontal scaling, erlang.

So I found myself at Railscamp UK on the weekend without a ruby+rails topic to really talk about during the presentations part of the camp. I’m still a noob wrt. Rails, you see. Realising that CouchDB is relevant to most web developers because most developers deal with document-based content at some point and that Ruby, Rails, and Erlang are kindda like the current bratpack (in a John Hughes-sense) of computer languages, I thought it would be a great little topic for a 15-minute presentation.

So I thought I share the slides and some of the code I hacked up on the weekend. First of all the slides…

(click me)

You can play about with some sample code that was expanded upon after the presentation. Here’s a little helper class to interface into CouchDB using JSON and HTTP:

require 'rubygems'
require 'httparty'
require 'json/pure'
require 'find'

class CouchHack
  include HTTParty
  base_uri 'http://127.0.0.1:5984'
  format :json

  def update( path, document )
    options = { :body => JSON.generate(document) }
    puts self.class.put(path, options )
  end

  def get(path)
    self.class.get(path)
  end

  def create(db_path, document )
    options = { :body => JSON.generate(document) }
    self.class.post(db_path, options )
  end

  def define_view(db_path, design_doc_name, views )
    document = { "views" => views }
    options = { :body => JSON.generate(document) }
    self.class.put("#{db_path}/_design/#{design_doc_name}", options)
  end
end

Once that’s in place you can use the CouchHack class by defining a view like so:

ch = CouchHack.new
gem_views = {
  "small_gems" =>
    {
      "map" => "function(doc) { if (doc.length < 3000) emit(doc.path, doc) }",
    },
  "large_gems" =>
    {
      "map" => "function(doc) { if (doc.length > 3000) emit(doc.path, doc) }",
    }
}
ch.define_view("/railscamp", "gems", gem_views)

This design document, as is its known in CouchDB parleance, defines two views (think ‘baked queries’), to return a list of small gems – those less than 3000 bytes – and a list of large gems – those larger than 3000 bytes.

So where do these gems come from and how do they end up in CouchDB ? That’s what the next and last little fragment of Ruby code does.

Find.find('/Library/Ruby/Gems/1.8/gems/' ) do |f|
  if File.file?(f) and f.ends_with?('.rb' )
    begin
      gem_contents = IO.read(f)
      gem_document = { "path" => f, "length" => gem_contents.length, "content" => gem_contents }
      ch.create( "/railscamp", gem_document )
    rescue Exception => bang
      puts "Skipping #{f}"
    end
  end
end

So what happens is that the last little fragment traverses the filesystem starting at /Library/Ruby/Gems/1.8/gems/ and looks for *.rb files. When it finds one it POSTs that whole document including the file length to CouchDB, where it becomes part of the resultset of one of the pre-defined views. These views can be accessed through the following two URLs (assuming the ‘railscamp’ DB was used).

• http://localhost:5984/railscamp/_view/gems/large_gems
• http://localhost:5984/railscamp/_view/gems/small_gems

Feel free to post comments and ask questions.

Enjoy.

P.S. and if you get a chance to go to a *camp conference, GO! They’re an amazing format and you’ll learn soooo much!.