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.
6. Relational DBs
• Attribute columns are valid for every row
• Duplicate rows are not allowed
• Every column has the same type and
same meaning
As a document store, MongoDB supports a
flexible schema
7. 1st Normal Form: No
repeating groups
• Can't use equality to match elements
Name
Lumia
iPad
Galaxy
Categories
“electronics,hand held, smart phone”
“PDA,tablet”
“smart phone,tablet”
Product_id
1234
5678
91011
Maker
Nokia
Apple
Samsung
8. 1st Normal Form: No
repeating groups
• Can't use equality to match elements
• Must use regular expressions to find data
Name
Lumia
iPad
Galaxy
Categories
“electronics,hand held, smart phone”
“PDA,tablet”
“smart phone,tablet”
Product_id
1234
5678
91011
Maker
Nokia
Apple
Samsung
9. 1st Normal Form: No
repeating groups
• Can't use equality to match elements
• Must use regular expressions to find data
• Aggregate functions are difficult
Name
Lumia
iPad
Galaxy
Categories
“electronics,hand held, smart phone”
“PDA,tablet”
“smart phone,tablet”
Product_id
1234
5678
91011
Maker
Nokia
Apple
Samsung
10. 1st Normal Form: No
repeating groups
• Can't use equality to match elements
• Must use regular expressions to find data
• Aggregate functions are difficult
• Updating a specific element is difficult
Name
Lumia
iPad
Galaxy
Categories
“electronics,hand held, smart phone”
“PDA,tablet”
“smart phone,tablet”
Product_id
1234
5678
91011
Maker
Nokia
Apple
Samsung
11. The Tao of MongoDB
{ _id : ObjectId(),
maker : “Nokia”
name : “Lumia”,
categories : [
"electronics",
"handheld",
"smart phone"
]
}
12. The Tao of MongoDB
{ _id : ObjectId(),
maker : “Nokia”
name : “Lumia”,
categories : [
"electronics",
"handheld",
"smart phone"
]
}
// querying is easy
db.products.find( { "categories": ”handheld" } );
13. The Tao of MongoDB
{ _id : ObjectId(),
maker : “Nokia”
name : “Lumia”,
categories : [
"electronics",
"handheld",
"smart phone"
]
}
// querying is easy
db.products.find( { "categories": ”handheld" } );
// can be indexed
db.products.ensureIndex( { "categories”: 1 } );
14. The Tao of MongoDB
{ _id : ObjectId(),
maker : “Nokia”
name : “Lumia”,
categories : [
"electronics",
"handheld",
"smart phone"
]
}
// Updates are easy
db.products.update(
{ "categories": "electronics"},
{ $set: { "categories.$" : "consumer electronics" } }
);
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. Goals of Normalization
• Model data an understandable form
• Reduce fact redundancy and data
inconsistency
• Enforce integrity constraints
Performance is not a primary
goal
23. Normalize or Denormalize
Commonly held that denormalization is faster
• Normalization can be fast, right? Requires
proper indexing, indexing effects write
performance
24. Normalize or Denormalize
Commonly held that denormalization is faster
• Normalization can be fast, right? Requires
proper indexing, indexing effects write
performance
• Does denormalization commit me to a join
strategy?
25. Normalize or Denormalize
Commonly held that denormalization is faster
• Normalization can be fast, right? Requires
proper indexing, indexing effects write
performance
• Does denormalization commit me to a join
strategy? Indexing overhead is a commitment
too
26. Normalize or Denormalize
Commonly held that denormalization is faster
• Normalization can be fast, right? Requires
proper indexing, indexing effects write
performance
• Does denormalization commit me to a join
strategy? Indexing overhead is a commitment
too
• Does denormalizaiton improve a finite set of
queries at the cost of several others?
27. Normalize or Denormalize
Commonly held that denormalization is faster
• Normalization can be fast, right? Requires
proper indexing, indexing effects write
performance
• Does denormalization commit me to a join
strategy? Indexing overhead is a commitment
too
• Does denormalizaiton improve a finite set of
queries at the cost of several others? MongoDB
works best in service to an application
30. Table Per Subclass
Vehicles
- electric
- car
- bus
- motorcycle
- internal combustion
-motorcycle
- aircraft
- human powered
- bicycle
- skateboard
-horsedrawn
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. 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
SELECT maker FROM Motorcycles WHERE Motorcycles.country =
"Italy"
UNION
SELECT maker FROM Automobiles WHERE Automobiles.country =
"Italy"
33. Table Per Class Family
• Classes mapped to a single table
Name
F4
A104
Triton 95
Type
sportbike
helicopter
submarine
Vehicle_id
1234
5678
91011
Maker
M.V
Agusta
M.V.
Agusta
Triton
34. Table Per Class Family
• Classes mapped to a single table
• Discriminator column to identify class
discriminator
Name
F4
A104
Triton 95
Type
sportbike
helicopter
submarine
Vehicle_id
1234
5678
91011
Maker
M.V
Agusta
M.V.
Agusta
Triton
35. Table Per Class Family
• Classes mapped to a single table
• Discriminator column to identify class
• Many empty columns, nullability issues
Name
F4
A104
Triton 95
Type
sportbike
helicopter
submarine
Vehicle_id
1234
5678
91011
Maker
M.V
Agusta
M.V.
Agusta
Triton
36. Table Per Class Family
• Classes mapped to a single table
• Discriminator column to identify class
• Many empty columns, nullability issues
maker = “M.V.
Agusta”,
type = “sportbike”,
num_doors = 0,
wing_area = 0,
maximum_depth = 0
???Name
F4
A104
Triton 95
Type
sportbike
helicopter
submarine
Vehicle_id
1234
5678
91011
Maker
M.V
Agusta
M.V.
Agusta
Triton
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 : Helicopter
engine : {
type : "turboshaft"
layout : "axial”,
massflow : 1318
},
Blades : 4
undercarriage : "fixed"
}
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. 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"
}
Shared indexing strategy
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 : Helicopter
engine : {
type : "turboshaft"
layout : "axial”,
massflow : 1318
},
Blades : 4
undercarriage : "fixed"
}
Polymorphic attributes