Successfully reported this slideshow.
Your SlideShare is downloading. ×

Intro To Mongo Db

Upcoming SlideShare
Introduction to MongoDB
Introduction to MongoDB
Loading in …3

Check these out next

1 of 36 Ad

More Related Content

Similar to Intro To Mongo Db (20)


Recently uploaded (20)

Intro To Mongo Db

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