Recap of my sdruby presentation on mongodb

Here I recap my presentation on mongodb at sdruby last night.

Slides

Introduction

I am using mongodb on Twinstang redesigned. I started with couchdb, but encountered difficulties grasping the concept of map/reduce for more powerful but necessary querying.

Because of this limitation in my skills (and partially because couchdb is limited to doing map/reduce on your documents and cannot do an additional map/reduce on top of a previous map/reduce) I began running into barriers in development of features for my app, and I foresaw more issues on the way.

I switched to mongodb using MongoMapper and have been super satisfied.

Installation & Running it

Installation of mongodb is from source but is quick and painless. After installation type sudo mongod run to run mongodb. You will probably want to use something like monit or god to monitor the process.

Mongo vs Couch

Couchdb is really cool and I can't say enough how much I've enjoyed it - especially the concepts it is pushing. It has huge potential to open up applications to the masses with its embedded apps. It is essentially a framework and server rolled into one. And it has convinced me that the language of the future is javascript. Furthermore, it's idea to run apps in the browser locally and then replicate/sync is mouthwatering. There are a lot of promises and hopes.

However, map/reduce is difficult to grasp and couchdb's map/reduce feels like a neutered version. How come I can't do map/reduces on already built design documents? In the end, couchdb left me somewhat disappointed. It was wrong for my app but was so exciting. I will be using couchdb in the future to build simple api based web apps that users can hook into.

Mongodb on the other hand feels more traditional. It is not trying to shake things up. Instead, Mongodb accomplishes its main goal very well - to bridge the gap between key/value stores and sql databases. It's fast, is focused on solving scaling issues that have haunted mysql, and it maintains the ease of use and power of dynamic queries.

Use mongodb for your traditional web app - where your users are doing a lot of updates but where you are generally controlling the interface and features. Use couchdb for focused web apps that are mostly an api or web hook and where your users are controlling the interface.

Mongodb (C++) Couchdb (Erlang)
drivers (php driver, ruby, python, and more) REST (very cool, but slightly slower. not really slower in practice though - except when it comes to replication as a tool to scale)
bson, document, schema-free json, document, schema-free
Dynamic queries, indexing (familiar, and great for development time. it works.) map/reduce (needs a way to do map/reduce on a design document - essentially a map/reduce on top of a map/reduce)
gridfs (needs an nginx/apache module. using send_data through an app or even through rack is too slow. however, supposed to be comparative to S3 if a module becomes available) embedded attachments (think email attachments. i really like the way couchdb handles attachments)
RAM http cache
Good at the web, faster development time (dynamic queries are what we are used to User.first(:login => 'jennifer')) Good at the web, slower development time (because of map/reduce and you have to construct all your queries from javascript)
Update in place (good for high update rates) MVCC (fault tolerant, but requires compacting.)
master-master (auto-sharding is under development and planned. which should make things quite easy to scale. *thanks Mark) replication (great for peer shared apps, but will be slow for large traditional web app databases replicating across servers - it's http)
50s kid (Traditional, yet rock n' roll, fast cars. Feels comfortable yet feels like the future. good for traditional web apps) indy kid (Untraditional, crazy cool ideas (like embedded apps and running in your browser), but uncertain. better for untraditional web apps right now)

Mongodb orms

If you are a rubyist use MongoMapper. Hands down it's the best orm. It basically makes the driver easy to use and familiar with rails/merb.

Using MongoMapper

Installation

sudo gem install mongomapper

config.gem 'jnunemaker-mongomapper'

dependency 'jnunemaker-mongomapper'

Model

Controller

Validations

Callbacks

Relationships

Embedded Documents

Additional info

Conclusion

Overall, I think mongodb with mongomapper is a smart way to go for a traditional web apps that are somewhat complicated (think facebook, basecamp, social networks) where you are providing an interface for your users to put information and then doing all kinds of things with that information.

I think couchdb is more suited to simple applications with express purposes (think blogs, a 'twitter' of your friends, apis) and where replicating that data from computer to computer and going offline is important.

You should follow me on twitter here