This document compares relational databases to MongoDB and discusses some key differences in their data models and functionality. MongoDB uses a flexible schema with embedded documents that allows for polymorphism and avoids the object-relational impedance mismatch of relational databases. While relational databases emphasize normalization to reduce redundancy, MongoDB favors denormalization for performance. MongoDB also offers relaxed ACID properties with atomicity at the document level and eventual consistency. To scale, MongoDB uses sharding to partition data across multiple servers.
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
Product_id
1234
5678
91011
•
Maker
Nokia
Apple
Samsung
Name
Lumia
iPad
Galaxy
Categories
“electronics,hand held, smart phone”
“PDA,tablet”
“smart phone,tablet”
Can't use equality to match elements
8. 1st Normal Form: No repeating
groups
Product_id
1234
5678
91011
Maker
Nokia
Apple
Samsung
Name
Lumia
iPad
Galaxy
Categories
“electronics,hand held, smart phone”
“PDA,tablet”
“smart phone,tablet”
•
Can't use equality to match elements
•
Must use regular expressions to find
data
9. 1st Normal Form: No repeating
groups
Product_id
1234
5678
91011
Maker
Nokia
Apple
Samsung
Name
Lumia
iPad
Galaxy
Categories
“electronics,hand held, smart phone”
“PDA,tablet”
“smart phone,tablet”
•
Can't use equality to match elements
•
Must use regular expressions to find
data
•
Aggregate functions are difficult
10. 1st Normal Form: No repeating
groups
Product_id
1234
5678
91011
Maker
Nokia
Apple
Samsung
Name
Lumia
iPad
Galaxy
Categories
“electronics,hand held, smart phone”
“PDA,tablet”
“smart phone,tablet”
•
Can't use equality to match elements
•
Must use regular expressions to find
data
•
Aggregate functions are difficult
•
Updating a specific element is difficult
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
Vehicle_id
1234
5678
91011
Maker
M.V
Agusta
M.V.
Agusta
Triton
Name
F4
A104
Triton 95
Type
sportbike
helicopter
submarine
34. Table Per Class Family
•
Classes mapped to a single table
•
Discriminator column to identify class
discriminator
Vehicle_id
1234
5678
91011
Maker
M.V
Agusta
M.V.
Agusta
Triton
Name
F4
A104
Triton 95
Type
sportbike
helicopter
submarine
35. Table Per Class Family
•
Classes mapped to a single table
•
Discriminator column to identify class
•
Many empty columns, nullability issues
Vehicle_id
1234
5678
91011
Maker
M.V
Agusta
M.V.
Agusta
Triton
Name
F4
A104
Triton 95
Type
sportbike
helicopter
submarine
36. Table Per Class Family
•
Classes mapped to a single table
•
Discriminator column to identify class
•
Many empty columns, nullability issues
Vehicle_id
1234
5678
91011
Maker
M.V
Agusta
M.V.
Agusta
Triton
maker = “M.V.
Agusta”,
Name
type =F4
“sportbike”,
num_doors = 0,
A104
wing_area = 0,
Triton 95
maximum_depth = 0
Type
sportbike
helicopter
submarine
???
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
56. Relational if you need to
•
Enforce data constraints
•
Service a broad set of queries
•
Minimize redundancy
57. The Tao of MongoDB
•
Avoid ad-hoc queries
•
Model data for use, not storage
•
Index effectively, index efficiently
58. Next Steps
• Webinar: From Relational Databases to MongoDB
- Considerations and Best Practices
– November 7
– 11am PT / 2pm ET / 6 pm UTC
• Register now at: mongodb.com/events