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.

1. Engineer
Bryan Reinero
@blimpyacht
Relational to MongoDB

2. Unhelpful Terms
• NoSQL
• Big Data
• Distributed
What’s the data model?

3. MongoDB
• Non-relational
• Scalable
• Highly available
• Full featured
• Document database

4. RDBMS MongoDB
Table, View ➜ Collection
Row ➜ Document
Index ➜ Index
Join ➜ Embedded Document
Foreign Key ➜ Reference
Partition ➜ Shard
Terminology

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. 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" } }
);

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. 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. 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
Tally the occurrences

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. 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

21. Normalize or Denormalize
Commonly held that denormalization is faster

22. Normalize or Denormalize
Commonly held that denormalization is faster
• Normalization can be fast, right?

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

28. Object–Relational
Impedance Mismatch
• Inheritance hierarchies
• Polymorphic associations

29. Table Per Subclass
Vehicles
vin
registration
maker
Motorcycle
Engine
rake
trial Racebike
racing number
class
team
rider

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

41. Relaxed ACID
• Atomic operations at the Document level

42. Relaxed ACID
• Atomic operations at the Document level
• Consistency – strong / eventual

43. Replication

44. Relaxed ACID
• Atomic operations at the Document level
• Consistency – strong / eventual
• Isolation - read lock, write lock / logical
database

45. Relaxed ACID
• Atomic operations at the Document level
• Consistency – strong / eventual
• Isolation - read lock, write lock / logical
database
• Durability – write ahead journal,
replication

46. The Tao of MongoDB
• Document database
• Flexible schema
• Relaxed ACID
This favors denormalization.
What’s the consequence?

47. Scaling MongoDB
Client
Application
Single Instance
Or
Replica Set
MongoDB
Sharded cluster

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. The Mechanism of Sharding
Complete Data Set
Define shard key on vehicle id
3456 56781234 45672345

50. The Mechanism of Sharding
Chunk Chunk
Define shard key on title
3456 56781234 45672345

51. The Mechanism of Sharding
Chunk Chunk ChunkChunk
Define shard key on vehicle id
3456 56781234 45672345

52. Chunk Chunk ChunkChunk
Shard 1 Shard 2 Shard 3 Shard 4
3456 56781234 45672345
Define shard key on vehicle id

53. Shard 1 Shard 2 Shard 3 Shard 4
Targeted
Operations
Client
mongos

54. Shard 1 Shard 2 Shard 3 Shard 4
Data Growth

55. Shard 1 Shard 2 Shard 3 Shard 4
Load Balancing

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. Engineer, 10gen
Bryan Reinero
@blimpyacht
Thank You