Recap of my sdruby presentation on mongodb
Here I recap my presentation on mongodb at sdruby last night.
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.
- Dynamic queries are a welcome return
- There is a good balance of speed, features, and schema-less freedom
- It should scale better than mysql with less effort
- MongoMapper makes it a pleasure to work with
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
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)|
|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)|
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.
sudo gem install mongomapper
- created_at and updated_at are included automatically by MongoMapper
- _id cannot currently be set with MongoMapper like it can in Couchrest
- cannot currently do @doc[‘custom_field’] like in couchrest.
- indexing: @doc.ensure_index :login
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