4. Not a RDBMS Mongo is not a relational database like MySQL No transactions No referential integrity No joins No schema, so no columns or rows NoSQL
5. Not a Key-Value Store Mongo is not simply a key-value store like Redis Stores structured data Rich query interface Indexes Map/Reduce Automatic sharding, GridFS, geospatial indexing, etc.
6. Document-oriented Database Records are JSON documents (actually BSON) Stored in collections No predefined schema Docs in the same collection don’t even need to have the same fields Atomic in-place operators for contention-free updates $set, $inc, $push, $pop, etc.
7. Mongo Document user = { name: "Frank Furter", occupation: "A scientist", location: "Transylvania" }
9. It’s Stupid Fast! Anywhere from 2 to 10 times faster than MySQL Depends on which contrived benchmark you’re looking at Here’s one I just made up:
10. It’s Stupid Fast! About 50 times faster than CouchDB According to http://www.idiotsabound.com/did-i-mention-mongodb-is-fast-way-to-go-mongo 2 important points: It’s pretty quick Benchmarks are worthless unless you do them on your actual workload
11. It’s Web Scale! Sharding built-in, automatic, and *Just Works™ *Just Works™ guarantee applies only if you have a cluster of shard replica sets with config servers and routing servers and you define your own shard key(s) with appropriate uniformity and granularity Asynchronous replication for failover and redundancy
12. It’s Pretty Painless Schemaless No more configuring database columns with types No more defining and managing migrations Just stick your data in there, it’s fine NoSQL ORMs exist mostly because writing SQL sucks Mongo’s query language is basically JSON The Mongo driver for your favorite language is really nice and officially supported Handy JavaScript shell for the CLI
13. It’s Pretty Painless MySQL /* First go create the database, the table, the schema, etc. */ mysql_connect("localhost", "username", "password") or die(mysql_error()); mysql_select_db("test") or die(mysql_error()); $sql = "INSERT INTO users (name, age) VALUES ('Janet', 23)"; mysql_query($sql); $result = mysql_query("SELECT * FROM users WHERE age = 23"); $row = mysql_fetch_assoc($result); echo "Oh, " . $row['name'] . "!"; // prints "Oh, Janet!" MongoDB $mongo = new Mongo(); // defaults to localhost with no auth $users = $mongo->test_db->users; // database and collection created implicitly $users->insert( array('name' => 'Brad', 'age' => 25) ); $user = $users->findOne( array('age' => 25) ); echo "Oh, " . $user->name . "!"; // prints "Oh, Brad!"
14. All the Cool Kids Are Doing It http://www.mongodb.org/display/DOCS/Production+Deployments
16. Documents and Collections Documents are the records Like objects in OOP, or rows in RDBMS Collections are groups of documents Usually represent a top-level class in your app Heterogeneous set Unlike RDBMS tables, no predefined schema No foreign keys, so how do we reference other objects? Don't! Just embed the sub-item in the parent doc Or, use a key for references and deal with the fact that you don't get integrity or joins
17. Embedded Objects Documents can embed other documents Used to efficiently represent a relation For example: { name: 'Brad Majors', address: { street: 'Oak Terrace', city: 'Denton' } }
22. JS Shell Comes with MongoDB Launch it with 'mongo' on the command-line Try a simplified version at http://www.mongodb.org/ Great fit since Mongo docs are basically JSON
25. I thought you said no schema? There is no predefined schema Your application creates an ad-hoc schema with the objects it creates The schema is implicit in the queries your application runs
26. Schema Design Use collections to represent the top-level classes of your application But don't just make a collection for every object type These aren't like tables in an RDBMS Less normalization, more embedding
27. Obligatory Blog Post Example A blog post has an author, some text, and many comments The comments are unique per post, but one author has many posts How would you design this in SQL? Let's look at how we might design it in Mongo
28. Bad Schema Design: References Collections for posts, authors, and comments References by manually created ID post = { id: 150, author: 100, text: 'This is a pretty awesome post.', comments: [100, 105, 112] } author = { id: 100, name: 'Michael Arrington' posts: [150] } comment = { id: 105, text: 'Whatever this sux.' }
29. Better Schema Design: Embedding Collection for posts Embed comments, author name post = { author: 'Michael Arrington', text: 'This is a pretty awesome post.', comments: [ 'Whatever this post sux.', 'I agree, lame!' ] }
30. Benefits Embedded objects brought back in the same query as parent object Only 1 trip to the DB server required Objects in the same collection are generally stored contiguously on disk Spatial locality = faster If the document model matches your domain well, it can be much easier to comprehend than nasty joins
31. Indexes Mongo supports indexes to greatly improve query performance No need to create in advance Create idempotent indexes in your app with "ensure_index"
32. Schema Design Limitations No referential integrity High degree of denormalization means updating something in many places instead of one Lack of predefined schema is a double-edged sword Hopefully you have a model in your app Objects within a collection can be completely inconsistent in their fields
34. Final Thoughts MongoDB is fast no matter how you slice it It achieves high performance by literally playing fast and loose with your data That's not necessarily a bad thing, just a tradeoff Very rapid development, open source Document model is simple but powerful Advanced features like map/reduce, geospatial indexing etc. are very compelling Surprisingly great drivers for most languages