23/10/2022

BUCKET PATTERN

Patterns in NOSQL Data Modeling

1. Attribute Pattern 7. Tree Patterns
2. Extended Reference Pattern 8. Polymorphic Pattern
3. Subset Pattern 9. Other Patterns
4. Computed Pattern
5. Bucket Pattern
6. Schema Versioning Pattern

1
 23/10/2022

Bucket Pattern

Too Many or Too Big

˗ One document per piece of
information per device

˗ One document will all the

information for a device

2
 23/10/2022

Just the Right Amount

One document per device per day One document per device per hour
{ “device_id”: 00123456, { “device_id”: 00123456,
“type”: “2A” “type”: “2A”
“date”: ISODate(“2018-03-02”) “date”: ISODate(“2018-03-02T13”)
“temp”: [ [20.0, 20.1, 20.2, …], “temp”: { 1: 20.0, 2: 20.1, 3: 20.2, …}
[22.1, 22.1, 22.0, …] }
.... ] }
{ “device_id”: 00123456, { “device_id”: 00123456,
“type”: “2A” “type”: “2A”
“date”: ISODate(“2018-03-03”) “date”: ISODate(“2018-03-02T14”)
“temp”: [ [20.1, 20.2, 20.3, …], “temp”: { 1: 22.1, 2: 22.1, 3: 20.0, …}
[22.4, 22.4, 22.3, …] }
....] }

Collaboration Platform Example

˗ Many channels
{
˗ Design alternatives “channel_id”, “13579246”,
“name”: “mongodb_tech”,
 One document per message “date”: ISODatte(“2018-03-02T03:14:16”),
“message”:”<Daniel joined the group>”
}

3
 23/10/2022

Collaboration Platform Example

˗ Many channels
˗ Design alternatives
{
 One document per message “channel_id”, “13579246”,
 One document for all “name”: “mongodb_tech”,
“message”: [
massages in a channel “<Channel created>”,
“< Nathan joined the group >”,
“< Daniel joined the group >”,
“Nathan: welcome Daniel”,
“Daniel: Thanks!”
…
}

Collaboration Platform Example

˗ Many channels
˗ Design alternatives
 One document per message
 One document for all
massages in a channel
 One document per channel,
per day

4
 23/10/2022

Row-based vs Column-based approach

Column Oriented Data

5
 23/10/2022

Gotchas with Buckets

˗ Random insertions or deletions in buckets
˗ Difficult to sort across buckets
˗ Ad hoc queries may be more complex, again across buckets
˗ Works best when the “complexity” is hidden through the
application code

Bucket Pattern

6
 23/10/2022

Summary
˗ Alternative to fully
embedding or fully linking a
1-to-Many relationship
˗ Advanced pattern that
requires a good understand
of the workload

Lab: Apply the Bucket Pattern

7
 23/10/2022

Patterns in NOSQL Data Modeling

1. Attribute Pattern 7. Tree Patterns

2. Extended Reference Pattern 8. Polymorphic Pattern
3. Subset Pattern 9. Other Patterns
4. Computed Pattern
5. Bucket Pattern
6. Schema Versioning Pattern

SCHEMA VERSIONING PATTERN

8
 23/10/2022

Alter table nightmares - Relational Database

MongoDB Database

9
 23/10/2022

Updating a Relational Database Schema

˗ Need time to update the Data
˗ Usually done by stopping the Application
˗ Hard to revert if something goes wrong

NoSQL Database - MongoDB

10
 23/10/2022

Schema versioning pattern

Application Lifecycle

11
 23/10/2022

Document Lifecycle

Timeline of the Migration

12
 23/10/2022

Schema Versioning Pattern

Summary

13
 23/10/2022

Lab: Apply the Schema Versioning Pattern

˗ Problem:
Which of the following scenarios are best suited for applying the Schema Versioning Pattern?
˗ Scenario A:
Your team was assigned to upgrade the current schema with additional fields and transforming the
type of different fields without bringing the system down for this upgrade. However, all documents
need to be updated to the new shape quickly.
˗ Scenario B:
The performance of your application became suboptimal over time. Your team has identified that
the most commonly used collection could profit from embedding additional information from other
collections using the Subset and Computed Patterns. All documents in the commonly-used
collection will need to undergo this modification. If possible, you would like the transition to be
done without downtime.
˗ Scenario C:
Your company was bought by its slightly more successful competitor. Thankfully both your and
your new owner's applications are flexible enough to handle both document shapes well. You do
not have to modify the application or your document shape, but due to the merger, you have to
keep documents with different structures in the same collection.

Patterns in NOSQL Data Modeling

1. Attribute Pattern 7. Tree Patterns

2. Extended Reference Pattern 8. Polymorphic Pattern
3. Subset Pattern 9. Other Patterns
4. Computed Pattern
5. Bucket Pattern
6. Schema Versioning Pattern

14
 23/10/2022

TREE PATTERNS

Tree Patterns

15
 23/10/2022

Tree Patterns

Tree Patterns

16
 23/10/2022

Tree Patterns

Tree Patterns

17
 23/10/2022

Tree Patterns
˗ Who are the ancestors of node X?
˗ Who report to Y?
˗ Find all nodes that are under Z?
˗ Change all categories under N to under P

Tree Patterns

18
 23/10/2022

Model Tree Structures

˗ Parent References
˗ Child References
˗ Array of Ancestors
˗ Materialized Paths

Parent References
{
Name: “Office”,
Parent: “Swag”,
…
}

19
 23/10/2022

Parent References
{
Name: “Office”,
Parent: “Swag”,
…
}

Parent References
{
Name: “Office”,
Parent: “Swag”,
…
}

20
 23/10/2022

Parent References
˗ Who are the ancestors of node X? (!)
˗ Who report to Y? ()
˗ Find all nodes that are under Z? (!)
˗ Change all categories under N to under P ()

Child References
{
name: “Office”,
Children“:[“Books”,
“Electronics”, “Stickers”]
…
}

21
 23/10/2022

Child References
˗ Who are the ancestors of node X? (!)
˗ Who report to Y? (!)
˗ Find all nodes that are under Z? ()
˗ Change all categories under N to under P (!)

Array of Ancestors
{
Name: “Books”,
Parent: [“Swag”, “Office”]
…
}

22
 23/10/2022

Array of Ancestors
˗ Who are the ancestors of node X? ()
˗ Who report to Y? ()
˗ Find all nodes that are under Z? ()
˗ Change all categories under N to under P (!)

Array of Ancestors
˗ Who are the ancestors of node X? ()
˗ Who report to Y? ()
˗ Find all nodes that are under Z? (!)
˗ Change all categories under N to under P (!)

23
 23/10/2022

Materialized Paths
{
Name: “Books”,
Parent: “.Swag.Office”]
…
}

Materialized Paths
{
Name: “Books”,
Parent: “.Swag.Office”]
…
}

24
 23/10/2022

Materialized Paths
˗ Who are the ancestors of node X? ()
˗ Who report to Y? (!)
˗ Find all nodes that are under Z? (!)
˗ Change all categories under N to under P (!)

MongoMark Solution: Ancestor Array +

Parent Reference
{
“_id” : 8,
“name” : “Umbrellas”,
“parent” : [ “Swag”, “Fashion”]
}

25
 23/10/2022

MongoMark Solution: Ancestor Array +

Parent Reference
{
“_id” : 8,
“name” : “Umbrellas”,
“parent” : [ “Swag”, “Fashion”]
}

Tree Patterns

26
 23/10/2022

Recap
˗ Documents are good data structure to represent hierarchical
data
˗ Several different patterns to represent trees
˗ Focus on the most common queries and operations to select
the most effective tree pattern

Patterns in NOSQL Data Modeling

1. Attribute Pattern 7. Tree Patterns

2. Extended Reference Pattern 8. Polymorphic Pattern
3. Subset Pattern 9. Other Patterns
4. Computed Pattern
5. Bucket Pattern
6. Schema Versioning Pattern

27
 23/10/2022

POLYMORPHIC PATTERN

Differences in Objects

28
 23/10/2022

More in Common than Differences

Vehicles

29
 23/10/2022

Products

Polymorphic Subdocuments

30
 23/10/2022

Single View

Single View Example

31
 23/10/2022

Polymorphism in the Schema Versioning

Pattern

Polymorphic Patterns

32
 23/10/2022

Summary
˗ Basic Pattern
˗ Base of many other Patterns

Patterns in NOSQL Data Modeling

1. Attribute Pattern 7. Tree Patterns

2. Extended Reference Pattern 8. Polymorphic Pattern
3. Subset Pattern 9. Other Patterns
4. Computed Pattern
5. Bucket Pattern
6. Schema Versioning Pattern

33
 23/10/2022

Other Patterns
˗ Approximation Pattern
˗ Outlier Pattern

Approximation Pattern

34
 23/10/2022

Approximation Pattern

Outlier Pattern

35
 23/10/2022

Movies Site Solution

Outlier Pattern

36
 23/10/2022

Recap
These are some other notable patterns
˗ Approximation Pattern
 Avoiding performing an operation too often
˗ Outlier Pattern
 Keeping the focus on the most frequent use cases

Summary of Patterns

37
 23/10/2022

Summary of Patterns
˗ Pattern are Powerful Transforms for your Schema
˗ Provide a common Language for your Team
˗ More Predictable Methodology

38