RailsConf – Day 3 – Million Dollar Mongo

Million Dollar Mongo - Obie Fernandez (Hashrocket), Durran Jordan (Hashrocket)
mongo was a good choice because only one patient record was worked on at a time

get entire object graph in a single query
previously did 35 joins and took 20 minutes to return

comparison between mongo, couch & cassandra
big selling point was dynamic queries – nice happy medium when coming from relational databases
“I don’t want to write any more ****** XML, so goodbye Cassandra”

No universal agreement that a NOSQL solution was the right idea

“Easiest database to install ever (except maybe Redis)”
No schema migrations

Forked MongoMapper -> Monoid
- MongoMapper was very young

Mongoid
- Prefers Embedding Documents
- Atomic Operations by Default, based on attribute changes
- rich criteria api
- master/slave suppor
- simple versioning
- is NOT ActiveRecord (and should be treated as such)
- Features always have performance in mind

mongo – can index in background as of 1.4
regex queries on fields
Denormalization is acceptable, embed as much as possible (no FK constraints)

Hybrid DB model
- Hierarchical Data Stored in MongoDB
- Relational Data stored in MySQL
- Data that required transactions stored in MySQL
- Simple Data in Redis
- Favor suitability over simplicity

It’s ok to use more than one datastore

Working without transactions
- Atomic updates generally cover you
- fairly easy to roll your own optimistic locking
- need to do manual rollback in integration tests
- selenium tests can run in a separate process

in production
- deployed on engine yard cloud / ec2
- 0.5 TB of data
- put mongodb on it’s own utility space
- feed it lots of ram, lots of disk space
- chef scripts easy due to simple installation

Tags: monogodb, railsconf