MongoDB Schema Design
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

MongoDB Schema Design

on

  • 26,103 views

 

Statistics

Views

Total Views
26,103
Views on SlideShare
26,102
Embed Views
1

Actions

Likes
7
Downloads
20
Comments
0

1 Embed 1

https://duckduckgo.com 1

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

MongoDB Schema Design Presentation Transcript

  • 1. Schema Designby Alex Litvinok
  • 2. Schema Design Basic unit of data – Document..
  • 3. Schema DesignWhat is document?• BSON Document• Embedding• Links across documents
  • 4. Schema DesignExample 01. event = { 02. _id: ObjectId(‘47cc67093475061e3d95369d’), 03. name: ‘MeetUP #2’, 04. date: ISODate(‘2012-04-05 19:00:00), 05. where: { 06. city: ‘Minsk’, 07. adress: ‘Nezavisimosti, 186’ } 08. }
  • 5. Schema DesignRDBMS? @#$.? NoSQL!Relation DB Document DBDatabase DatabaseTable CollectionRow(s) DocumentIndex IndexJoin Embedding and LinksPartition ShardPartition Key Shard Key
  • 6. Schema DesignWhy?• Make queries easy and fast• Facilitate sharding and automaticity
  • 7. Schema DesignStrategy• Start with a normalized model• Embed docs for simplicity and optimization
  • 8. Schema Design Normalized? Denormalized?
  • 9. Schema DesignNormalized schema01. Order = {02. _id : orderId, Order03. user : userInfo, • _id04. items : [ • user05. productId1, • items *06. productId2,07. productId308. ] Product09. } • _id10. Product = { • name11. _id: productId, • price12. name : name, • desc13. price : price,14. desc : description * Link to collection of product15. }
  • 10. Schema DesignNormalized schema• Normalized documents are a perfectably acceptable way to use MongoDB.• Normalized documents provide maximum flexibility.
  • 11. Schema DesignLinks across documentsDBRef{ $ref : <collname>, $id : <idvalue>[, $db : <dbname>] }Or simple storage of _id..
  • 12. Schema DesignDenormalized schema01. Order = {02. _id : orderId, Order03. user : userInfo, • _id04. items : [ { • user05. _id: productId1, • items06. name : name1,07. price : price1 • _id • name08. }, { • price09. _id: productId2,10. name : name2, • _id11. price : price3 • name12. }] • price13. }
  • 13. Schema DesignDenormalized schema• Embedded documents are good for fast queries.• The embedded documents always available with the parent documents.• Embedded and nested documents are good for storing complex hierarchies.
  • 14. Schema DesignEmbedding documents01. {02. title : "Contributors",03. data: [04. { name: “Grover" },05. { name: “James", surname: “Madison" },06. { surname: “Grant" }07. ]08. }09.
  • 15. Schema Design ..fast queries
  • 16. Schema DesignIndexesBasics> db.collection.ensureIndex({ name:1 });Indexing on Embedded Fields> db.collection.ensureIndex({ location.city:1 })Compound Keys> db.collection.ensureIndex({ name:1, age:-1 })
  • 17. Schema DesignAlso indexes..The _id Index• Automatically created except capped collection• Index is special and cannot be deleted• Enforces uniqueness for its keysIndexing Array Elements• Indexes for each element of the arrayCompound Keys• Direction of the index ( 1 for ascending or -1 for descending )
  • 18. Schema DesignAgain indexes...Create optionssparse, unique, dropDups, background, v…Geospatial Indexing> db.places.ensureIndex( { loc : "2d" } )> db.places.ensureIndex( { loc : "2d" } , { min : -500 , max : 500 } )> db.places.ensureIndex( { loc : "2d" } , { bits : 26 } )
  • 19. Schema Design Analysis and Optimization Profiler | Explain
  • 20. Schema DesignDatabase ProfilerProfiling Level• 0 - Off• 1 - log slow operations (by default, >100ms is considered slow)• 2 - log all operations> db.setProfilingLevel(2);
  • 21. Schema DesignDatabase ProfilerViewing the Data – collection system.profile> db.system.profile.find() { "ts" : "Thu Jan 29 2009 15:19:32 GMT-0500 (EST)" , "info" : "querytest.$cmd ntoreturn:1 reslen:66 nscanned:0 <br>query: { profile: 2 }nreturned:1 bytes:50" , "millis" : 0}
  • 22. Schema DesignExplain> db.collection.find( … ).explain(){ cursor : "BasicCursor", indexBounds : [ ], nscanned : 57594, nscannedObjects : 57594, nYields : 2 , n:3, millis : 108, indexOnly : false, isMultiKey : false, nChunkSkips : 0}
  • 23. Schema Design From theory to Actions..
  • 24. Schema DesignSeating plan { _id: ObjectId, event_id: ObjectId seats: { A1:1, A2:1, A3:0, … H30:0 } }
  • 25. Schema DesignSeating plan{ _id: { event_id: ObjectId, seat: ‘C9’ }, updated: new Date(), state: ‘AVALIBLE’}
  • 26. Schema DesignFeed reader • Users • Feed • Entries
  • 27. Schema DesignFeed readerStorage users{ _id: ObjectId, name: ‘username’, feeds: [ ObjectId, ObjectId, … ]}
  • 28. Schema DesignFeed readerStorage feeds{ _id: ObjectId, url: ‘http://bbc.com/news/feed’, name: ‘BBC News’, latest: Date(‘2012-01-10T12:30:13Z’), enties:[{ latest: Date(‘2012-01-10T12:30:13Z’), title: ‘Bomb kills Somali sport officials’, description: ‘…’, … }]}
  • 29. Schema DesignSome tips1. Duplicate data for speed, reference data for integrity2. Try to fetch data in a single query3. Design documents to be self-sufficient4. Override _id when you have your own simple, unique id5. Don’t always use an index
  • 30. Schema DesignConclusion• Embedded docs are good for fast queries• Embedded and nested docs are good for storing hierarchies• Normalized docs are a most acceptable
  • 31. Schema Design ? ? ? ?