Webinar: From Relational Databases to MongoDB - What You Need to Know

10,313 views
10,763 views

Published on

Relational databases weren't designed to cope with the scale and agility challenges that face modern applications. MongoDB can offer scalability, performance and ease of use - but proper design will be a critical factor to that success. We'll take a dive into how MongoDB works to better understand what non-relational design is, why we might use it and what advantages it gives us. We'll develop schema designs by example, and consider strategies for scale out.

Published in: Technology, Business
0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
10,313
On SlideShare
0
From Embeds
0
Number of Embeds
8,442
Actions
Shares
0
Downloads
88
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide
  • 1970’s design normalization
  • Base class mapped to separate tableSupports polymorphic relationshipsRequires joinsIsn’t practical to map every class to the parent
  • If the hierarchy grows joins on every derived classIsn’t practical to map every class to the parent
  • Closer to denormalizationUNION required to cover the entire inheritance
  • Closer to denormalizationUNION required to cover the entire inheritance
  • Independent node operations
  • Independent node operations
  • Independent node operations
  • Independent node operations
  • Independent node operations
  • Multi-row documentation
  • Webinar: From Relational Databases to MongoDB - What You Need to Know

    1. 1. EngineerBryan Reinero@blimpyachtRelational to MongoDB
    2. 2. Unhelpful Terms• NoSQL• Big Data• DistributedWhat’s the data model?
    3. 3. MongoDB• Non-relational• Scalable• Highly available• Full featured• Document database
    4. 4. RDBMS MongoDBTable, View ➜ CollectionRow ➜ DocumentIndex ➜ IndexJoin ➜ Embedded DocumentForeign Key ➜ ReferencePartition ➜ ShardTerminology
    5. 5. Sample Document{maker : "M.V. Agusta",type : sportbike,rake : 7,trail : 3.93,engine : {type : "internal cumbustion",layout : "inline"cylinders : 4,displacement : 750,},transmission : {type : "cassette",speeds : 6,pattern : "sequential”,ratios : [ 2.7, 1.94, 1.34, 1, 0.83, 0.64 ]}}
    6. 6. Relational DBs• Attribute columns are valid for every row• Duplicate rows are not allowed• Every column has the same type andsame meaningAs a document store, MongoDB supports aflexible schema
    7. 7. 1st Normal Form: Norepeating groups• Cant use equality to match elementsNameLumiaiPadGalaxyCategories“electronics,hand held, smart phone”“PDA,tablet”“smart phone,tablet”Product_id1234567891011MakerNokiaAppleSamsung
    8. 8. 1st Normal Form: Norepeating groups• Cant use equality to match elements• Must use regular expressions to find dataNameLumiaiPadGalaxyCategories“electronics,hand held, smart phone”“PDA,tablet”“smart phone,tablet”Product_id1234567891011MakerNokiaAppleSamsung
    9. 9. 1st Normal Form: Norepeating groups• Cant use equality to match elements• Must use regular expressions to find data• Aggregate functions are difficultNameLumiaiPadGalaxyCategories“electronics,hand held, smart phone”“PDA,tablet”“smart phone,tablet”Product_id1234567891011MakerNokiaAppleSamsung
    10. 10. 1st Normal Form: Norepeating groups• Cant use equality to match elements• Must use regular expressions to find data• Aggregate functions are difficult• Updating a specific element is difficultNameLumiaiPadGalaxyCategories“electronics,hand held, smart phone”“PDA,tablet”“smart phone,tablet”Product_id1234567891011MakerNokiaAppleSamsung
    11. 11. The Tao of MongoDB{ _id : ObjectId(),maker : “Nokia”name : “Lumia”,categories : ["electronics","handheld","smart phone"]}
    12. 12. The Tao of MongoDB{ _id : ObjectId(),maker : “Nokia”name : “Lumia”,categories : ["electronics","handheld","smart phone"]}// querying is easydb.products.find( { "categories": ”handheld" } );
    13. 13. The Tao of MongoDB{ _id : ObjectId(),maker : “Nokia”name : “Lumia”,categories : ["electronics","handheld","smart phone"]}// querying is easydb.products.find( { "categories": ”handheld" } );// can be indexeddb.products.ensureIndex( { "categories”: 1 } );
    14. 14. The Tao of MongoDB{ _id : ObjectId(),maker : “Nokia”name : “Lumia”,categories : ["electronics","handheld","smart phone"]}// Updates are easydb.products.update({ "categories": "electronics"},{ $set: { "categories.$" : "consumer electronics" } });
    15. 15. The Tao of MongoDB{ _id : ObjectId(),maker : “Nokia”name : “Lumia”,categories : ["electronics","handheld","smart phone"]}db.products.aggregate({ $unwind : "$categories" },{ $group : {"_id" : "$categories", "counts" : { "$sum" : 1 }}});
    16. 16. The Tao of MongoDB{ _id : ObjectId(),maker : “Nokia”name : “Lumia”,categories : ["electronics","handheld","smart phone"]}db.products.aggregate({ $unwind : "$categories" },{ $group : {"_id" : "$categories", "counts" : { "$sum" : 1 }}});Unwind the array
    17. 17. The Tao of MongoDB{ _id : ObjectId(),maker : “Nokia”name : “Lumia”,categories : ["electronics","handheld","smart phone"]}db.products.aggregate({ $unwind : "$categories" },{ $group : {"_id" : "$categories", "counts" : { "$sum" : 1 }}});Unwind the arrayTally the occurrences
    18. 18. The Tao of MongoDB"result" : [{ "_id" : "smart phone”, "counts" : 1589 },{ "_id" : "handheld”, "counts" : 2403 },{ "_id" : "electronics”, "counts" : 4767 }]db.products.aggregate({ $unwind : "$categories" },{ $group : {"_id" : "$categories", "counts" : { "$sum" : 1 }}});
    19. 19. Meh, big deal…. Right?Aren’t nested structures just a pre-joined schema?• I could use an adjacency list• I could use an intersection table
    20. 20. Goals of Normalization• Model data an understandable form• Reduce fact redundancy and datainconsistency• Enforce integrity constraintsPerformance is not a primarygoal
    21. 21. Normalize or DenormalizeCommonly held that denormalization is faster
    22. 22. Normalize or DenormalizeCommonly held that denormalization is faster• Normalization can be fast, right?
    23. 23. Normalize or DenormalizeCommonly held that denormalization is faster• Normalization can be fast, right? Requiresproper indexing, indexing effects writeperformance
    24. 24. Normalize or DenormalizeCommonly held that denormalization is faster• Normalization can be fast, right? Requiresproper indexing, indexing effects writeperformance• Does denormalization commit me to a joinstrategy?
    25. 25. Normalize or DenormalizeCommonly held that denormalization is faster• Normalization can be fast, right? Requiresproper indexing, indexing effects writeperformance• Does denormalization commit me to a joinstrategy? Indexing overhead is a commitmenttoo
    26. 26. Normalize or DenormalizeCommonly held that denormalization is faster• Normalization can be fast, right? Requiresproper indexing, indexing effects writeperformance• Does denormalization commit me to a joinstrategy? Indexing overhead is a commitmenttoo• Does denormalizaiton improve a finite set ofqueries at the cost of several others?
    27. 27. Normalize or DenormalizeCommonly held that denormalization is faster• Normalization can be fast, right? Requiresproper indexing, indexing effects writeperformance• Does denormalization commit me to a joinstrategy? Indexing overhead is a commitmenttoo• Does denormalizaiton improve a finite set ofqueries at the cost of several others? MongoDBworks best in service to an application
    28. 28. Object–RelationalImpedance Mismatch• Inheritance hierarchies• Polymorphic associations
    29. 29. Table Per SubclassVehiclesvinregistrationmakerMotorcycleEngineraketrial Racebikeracing numberclassteamrider
    30. 30. Table Per SubclassVehicles- electric- car- bus- motorcycle- internal combustion-motorcycle- aircraft- human powered- bicycle- skateboard-horsedrawn
    31. 31. Table Per Concrete Class• Each class is mapped to a separate table• Inherited fields are present in each class’ table• Can’t support polymorphic relationships
    32. 32. Table Per Concrete Class• Each class is mapped to a separate table• Inherited fields are present in each class’ table• Can’t support polymorphic relationshipsSELECT maker FROM Motorcycles WHERE Motorcycles.country ="Italy"UNIONSELECT maker FROM Automobiles WHERE Automobiles.country ="Italy"
    33. 33. Table Per Class Family• Classes mapped to a single tableNameF4A104Triton 95TypesportbikehelicoptersubmarineVehicle_id1234567891011MakerM.VAgustaM.V.AgustaTriton
    34. 34. Table Per Class Family• Classes mapped to a single table• Discriminator column to identify classdiscriminatorNameF4A104Triton 95TypesportbikehelicoptersubmarineVehicle_id1234567891011MakerM.VAgustaM.V.AgustaTriton
    35. 35. Table Per Class Family• Classes mapped to a single table• Discriminator column to identify class• Many empty columns, nullability issuesNameF4A104Triton 95TypesportbikehelicoptersubmarineVehicle_id1234567891011MakerM.VAgustaM.V.AgustaTriton
    36. 36. Table Per Class Family• Classes mapped to a single table• Discriminator column to identify class• Many empty columns, nullability issuesmaker = “M.V.Agusta”,type = “sportbike”,num_doors = 0,wing_area = 0,maximum_depth = 0???NameF4A104Triton 95TypesportbikehelicoptersubmarineVehicle_id1234567891011MakerM.VAgustaM.V.AgustaTriton
    37. 37. The Tao of MongoDB{ maker : "M.V. Agusta",type : sportsbike,engine : {type : ”internal combustion",cylinders: 4,displacement : 750},rake : 7,trail : 3.93}{ maker : "M.V. Agusta",type : Helicopterengine : {type : "turboshaft"layout : "axial”,massflow : 1318},Blades : 4undercarriage : "fixed"}
    38. 38. The Tao of MongoDB{ maker : "M.V. Agusta",type : sportsbike,engine : {type : ”internal combustion",cylinders: 4,displacement : 750},rake : 7,trail : 3.93}{ maker : "M.V. Agusta",type : Helicopter,engine : {type : "turboshaft"layout : "axial”,massflow : 1318},Blades : 4,undercarriage : "fixed"}Discriminator column
    39. 39. The Tao of MongoDB{ maker : "M.V. Agusta",type : sportsbike,engine : {type : ”internal combustion",cylinders: 4,displacement : 750},rake : 7,trail : 3.93}{ maker : "M.V. Agusta",type : Helicopterengine : {type : "turboshaft"layout : "axial”,massflow : 1318},Blades : 4,undercarriage : "fixed"}Shared indexing strategy
    40. 40. The Tao of MongoDB{ maker : "M.V. Agusta",type : sportsbike,engine : {type : ”internal combustion",cylinders: 4,displacement : 750},rake : 7,trail : 3.93}{ maker : "M.V. Agusta",type : Helicopterengine : {type : "turboshaft"layout : "axial”,massflow : 1318},Blades : 4undercarriage : "fixed"}Polymorphic attributes
    41. 41. Relaxed ACID• Atomic operations at the Document level
    42. 42. Relaxed ACID• Atomic operations at the Document level• Consistency – strong / eventual
    43. 43. Replication
    44. 44. Relaxed ACID• Atomic operations at the Document level• Consistency – strong / eventual• Isolation - read lock, write lock / logicaldatabase
    45. 45. Relaxed ACID• Atomic operations at the Document level• Consistency – strong / eventual• Isolation - read lock, write lock / logicaldatabase• Durability – write ahead journal,replication
    46. 46. The Tao of MongoDB• Document database• Flexible schema• Relaxed ACIDThis favors denormalization.What’s the consequence?
    47. 47. Scaling MongoDBClientApplicationSingle InstanceOrReplica SetMongoDBSharded cluster
    48. 48. Partitioning• User defines shard key• Shard key defines range of data• Key space is like points on a line• Range is a segment of that line
    49. 49. The Mechanism of ShardingComplete Data SetDefine shard key on vehicle id3456 56781234 45672345
    50. 50. The Mechanism of ShardingChunk ChunkDefine shard key on title3456 56781234 45672345
    51. 51. The Mechanism of ShardingChunk Chunk ChunkChunkDefine shard key on vehicle id3456 56781234 45672345
    52. 52. Chunk Chunk ChunkChunkShard 1 Shard 2 Shard 3 Shard 43456 56781234 45672345Define shard key on vehicle id
    53. 53. Shard 1 Shard 2 Shard 3 Shard 4TargetedOperationsClientmongos
    54. 54. Shard 1 Shard 2 Shard 3 Shard 4Data Growth
    55. 55. Shard 1 Shard 2 Shard 3 Shard 4Load Balancing
    56. 56. Relational if you need to• Enforce data constraints• Service a broad set of queries• Minimize redundancy
    57. 57. The Tao of MongoDB• Avoid ad-hoc queries• Model data for use, not storage• Index effectively, index efficiently
    58. 58. Engineer, 10genBryan Reinero@blimpyachtThank You

    ×