‘This section is about airplanes’, ‘this section is about trains’ ], comments: [ { author: ‘Kevin Hanson’, comment: ‘dude, what about driving?’ }, { author: ‘John Smith’, comment: ‘this blog is aWful!!11!!!!’ } ], } Wednesday, April 18, 12
the blog for results • Cleanly encapsulated Cons • What if we get too many comments? (16MB mongoDB doc size) • What if we want our results to be comments, not blog posts? Wednesday, April 18, 12
Work’, blog-text: [ ‘This section is about airplanes’, ‘this section is about trains’] } { commenter: ‘Kevin Hanson’, comment: ‘dude, what about driving?’ } { commenter: ‘John Smith’, comment: ‘this blog is aWful!!11!!!!’ } Wednesday, April 18, 12
Oriented • Application Level Implications For example... Blog Post 1: Paul enters his name as “Paul” Blog Post 2: Paul enter his name as “Paul Pedersen” We want to avoid this. Wednesday, April 18, 12
Grow Larger than Pre- Allocated Size • Document May Increase Max Doc Size of 16MB Can this be avoided?? • Yes! • A Hybrid of Linking and Embedding • Somewhere Between Methods 2 and 3 Wednesday, April 18, 12
• Will this partitioning create hotspots? • Can our partitioning actually improve overall performance? “Bad” Shard Key Example: Sharding on “date” field and constantly inserting most recent data... Possible* Good Shard Key Example... Sharding blog posts on “author” field *depends on usage patterns Wednesday, April 18, 12