introduction_to_mongodb汇.ppt

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? Lets look at how we might design it in Mongo 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. } 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! ] } 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 Indexes Mongo supports indexes to greatly improve query performance No need to create in advance Create idempotent indexes in your app with ensure_index 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 Final Thoughts MongoDB is fast no matter how you slice it It achieves high performance by literally playing fast and loose with your data Thats 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 Thanks! These slides are online