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