MongoDB .local Chicago 2019: From SQL to NoSQL -- Changing Your Mindset

#MDBlocal
[Jumpstart] From SQL to NoSQL:
Changing your Mindset
@JoeKarlsson1
Joe Karlsson

Did you know that the
two main bottlenecks
for web app
performance are:
@JoeKarlsson1Source: https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4
* Network speed
* Database execution speed

We can only
control one of
these things
@JoeKarlsson1Source: https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4

{
name: “Joe Karlsson”,
company: “MongoDB”,
pronouns: “He/They”,
title: [
“Developer Advocate”,
“Software Engineer”
],
twitter: “@JoeKarlsson1”,
website: “joekarlsson.com”,
}

@JoeKarlsson1
MagicMirror^2
@JoeKarlsson1

@JoeKarlsson1
Moodlite
@JoeKarlsson1

@JoeKarlsson1
Want to watch
me make stuff?
https://www.twitch.tv/joe_karlsson
@JoeKarlsson1

Before we
get started…
@JoeKarlsson1

Thank you so
much for coming!
@JoeKarlsson1

Who’s this
talk for?
@JoeKarlsson1

How’s this talk
going to work?
@JoeKarlsson1

Feel free to ask
questions at
anytime
@JoeKarlsson1

Want to
follow along?
@JoeKarlsson1
http://bit.ly/FromSQLtoNoSQLChicago

Get the slides/
resources on my
Twitter after the
talk:
@JoeKarlsson1
@JoeKarlsson1

Quick
Audience
Poll
@JoeKarlsson1

Agenda
1.Map terms & concepts from SQL to MongoDB
2.Discover the 4 humongous advantages of MongoDB
3.Change your mindset in 3 key ways
@JoeKarlsson1

Agenda
@JoeKarlsson1
Row Column Table Database Index Join Join
Left Outer
Join
Recursive
Common Table
Expressions
View Transaction
Document Field Collection Database Index Embedding
Database
References
$lookup $graphLookup View Transaction

@JoeKarlsson1
MongoDB stores data in documents

@JoeKarlsson1
MongoDB stores data in documents
{
first_name: "Paul",
surname: "Miller",
cell: "447557505611",
city: "London",
location: [45.123,47.232],
profession: ["banking", "finance", "trader"],
cars: [
{
model: "Bentley",
year: 1973
},
{
model: "Rolls Royce",
year: 1965
}
]
}

@JoeKarlsson1
Modeling data in MongoDB vs SQL
{
first_name: "Paul",
surname: "Miller",
cell: "447557505611",
city: "London",
location: [45.123,47.232],
cars: [
{
model: "Bentley",
year: 1973
},
{
year: 1965
}
]
}

@JoeKarlsson1
{
first_name: "Paul",
surname: "Miller",
cell: "447557505611",
city: "London",
location: [45.123,47.232],
cars: [
{
model: "Bentley",
year: 1973
},
{
year: 1965
}
]
}
ID first_name surname cell city location_x location_y
1 Paul Miller 447557505611 London 45.123 47.232
Users

@JoeKarlsson1
{
first_name: "Paul",
surname: "Miller",
cell: "447557505611",
city: "London",
location: [45.123,47.232],
cars: [
{
model: "Bentley",
year: 1973
},
{
year: 1965
}
]
}
ID user_id profession
10 1 banking
11 1 finance
12 1 trader
Professions
Users

@JoeKarlsson1
{
first_name: "Paul",
surname: "Miller",
cell: "447557505611",
city: "London",
location: [45.123,47.232],
cars: [
{
model: "Bentley",
year: 1973
},
{
year: 1965
}
]
}
ID user_id model year
20 1 Bentley 1973
21 1 Rolls Royce 1965
Cars
10 1 banking
11 1 finance
12 1 trader
Professions
Users

@JoeKarlsson1
Collections vs Tables
{
first_name: "Paul",
surname: "Miller",
cell: "447557505611",
city: "London",
location: [45.123,47.232],
cars: [
{
model: "Bentley",
year: 1973
},
{
year: 1965
}
]
}
{
first_name: ”Joe",
surname: ”Karlsson",
cell: ”1235552222",
city: ”Minneapolis”,
profession: [”software engineer", ”developer advocate"],
}
{
first_name: ”BMO",
city: ”Minneapolis",
}
UsersUsers
ID first_name surname cell city
location_
x
location_y
2 Joe Karlsson 1235552222 Minneapolis NULL NULL
3 Sydney Schaefer NULL Minneapolis NULL NULL

@JoeKarlsson1
Collections vs Tables
{
first_name: "Paul",
surname: "Miller",
cell: "447557505611",
city: "London",
location: [45.123,47.232],
cars: [
{
model: "Bentley",
year: 1973
},
{
year: 1965
}
]
}
{
cell: ”1235552222",
}
{
}
UsersUsers
ID first_name surname cell city
location_
x
location_y
2 Joe Karlsson 1235552222 Minneapolis NULL NULL
3 BMO Karlsson NULL Minneapolis NULL NULL

Don’t panic!
Use schema validation.
Flexible
schema 
database

Document Row(s)
ID a ...
1 b ...
2 ... ...
3 ... ...
... ... ...
... ... ...
... ... ...
... ... ...
... ... ...
... ... ...
{
... 
a: “b” 
...
}

Field
ID a ...
1 b ...
2 c ...
3 ... ...
{
... 
a: “b” 
...
}
{
... 
a: “c” 
...
}
Column

TableCollection
{
...
}
... ... ...
... ... ...
... ... ...
... ... ...
{
...
}
{
...
}

@JoeKarlsson1
Time for a
terrible joke

@JoeKarlsson1
So a DBA walks 
into a NoSQL bar…
But immediately leaves because
they couldn’t find table.

DatabaseDatabase
... ... ...
... ... ...
... ... ...
... ... ...
{
...
}
{
...
}
{
...
}
{
...
}
{
...
}
{
...
}
{
...
}
... ... ...
... ... ...
... ... ...
... ... ...
... ... ...

IndexIndex
{
...
}
{
...
}
{
...
}
{
...
}
... ... ...
... ... ...
... ... ...
... ... ...
... ... ...

ViewView
{
...
}
... ... ...
... ... ...
... ... ...
... ... ...
{
...
} {
...
}

Embedding
{
... 
a: “b”, 
...
c: { 
d: “e” 
... 
}, 
...
}
ID a ...
1 b ...
2 ... ...
3 ... ...
... d ...
1 e ...
... ... ...
Join

Multi-Record ACID
Transaction
Multi-Document
ACID
Transaction
{
...
}
{
...
}
{
...
}
{
...
}
{
...
}
{
...
}
{
...
}
... ... ...
... ... ...
... ... ...
... ... ...
... ... ...
... ... ...
... ... ...

@JoeKarlsson1
The journey from SQL to MongoDB

@JoeKarlsson1
Row Column Table Database Index Join Join
Left Outer
Join
Recursive
Common Table
Expressions
View Transaction
Document Field Collection Database Index Embedding
Database
References
$lookup $graphLookup View Transaction
1) Map terms & concepts from SQL to MongoDB

Agenda
2.Discover the 4 humongous advantages of
MongoDB
@JoeKarlsson1
1.Program faster
2.Pivot easier
3.Query faster
4.Scale Cheaper

@JoeKarlsson1
Program faster!
Update Your Profile
Documents map to data structures in most popular languages.

@JoeKarlsson1
Program faster!
{
first_name: "Paul",
surname: "Miller",
cell: "447557505611",
city: "London",
location: [45.123,47.232],
}
Users
10 1 banking
11 1 finance
12 1 trader
Professions

import pymongo 
from pymongo import MongoClient
# CONNECT TO THE DB
client = MongoClient()
client = 
pymongo.MongoClient("mongodb+srv:// 
username:password@cluster0nsdia. 
mongodb.net/test?retryWrites=true")
db = client.fabapp
 
# THE ID OF THE USER WHOSE PROFILE WE
WILL BE RETRIEVING AND UPDATING
userId = 1
Program faster!
import mysql.connector
 
# CONNECT TO THE DB
mydb = mysql.connector.connect( 
host="localhost", 
user=”username", 
passwd=”password", 
database=”fabapp” 
)
mycursor = mydb.cursor()
 
# THE ID OF THE USER WHOSE PROFILE WE
WILL BE RETRIEVING AND UPDATING
userId = 1

# GET THE USER'S PROFILE INFORMATION
### Pull the info from the Users table
& put it in the user dictionary
sql = "Select * FROM Users WHERE
Users.ID=%s” 
values = (userId,) 
mycursor.execute(sql, values) 
result = mycursor.fetchone()
user = { 
"first_name": result[1], 
"surname": result[2], 
"cell": result[3], 
"city": result[4], 
"location_x": result[5], 
"location_y": result[6] 
}
# GET THE USER'S PROFILE INFORMATION
## We can pull all of the info from
the same document since we used
embedding
user = db['Users'].find_one({"_id":
userId})
Program faster!
### Pull the info from the Professions
table & put it in the user dictionary
sql = "Select * FROM Professions WHERE 
Professions.user_id=%s” 
results = mycursor.fetchall()
professions = [] 
for result in results: 
professions.append(result[2]) 
user["professions"] = professions

# UPDATE THE USER DICTIONARY BASED
ON USER INPUT IN THE APP
### We'll update the user
dictionary manually for simplicity
user = { 
"first_name": "NewFirst", 
"surname": "NewSurname", 
"cell": "123-456-7890", 
"city": "NewCity", 
"location": [40.762, -73.979], 
"professions": [”Manager",
"Engineer"] 
}
Program faster!
# UPDATE THE USER DICTIONARY BASED
ON USER INPUT IN THE APP
### We'll update the user dictionary
manually for simplicity
user = { 
"first_name": "NewFirst", 
"surname": "NewSurname", 
"cell": "123-456-7890", 
"city": "NewCity", 
"location_x": 40.762,  
"location_y": 73.979, 
"professions": [”Manager",
"Engineer"] 
}

# UPDATE THE USER'S PROFILE IN THE DATABASE
### First update what is stored in the
Users table
sql = "UPDATE Users SET first_name=%s,
surname=%s, cell=%s, city=%s,
location_x=%s, location_y=%s WHERE (ID=%s)" 
values = ( 
user["first_name"],  
user["surname"],  
user["cell"],  
user["city"],  
user["location_x"],  
user["location_y"],  
userId) 
mycursor.execute(sql, values)
mydb.commit()
# UPDATE THE USER'S PROFILE IN THE
DATABASE
### Since the user's data is stored
in a single document, we only have to
make one update
result = db['Users'].update_one( 
{"_id": userId}, {"$set": user})
 
Program faster!
### Delete existing records in
Professions table and add new ones
sql = "DELETE FROM Professions WHERE
user_id=%s” 
mydb.commit()
if(len(user["professions"]) > 0): 
sql = "INSERT INTO Professions  
(user_id,profession) VALUES
(%s, %s)” 
values = [] 
for profession in
user["professions"]: 
values.append((userId,
profession)) 
mycursor.executemany(sql,values) 
mydb.commit()

30 lines of code
Program faster!
73 lines of code

@JoeKarlsson1
Pivot easier!
Easily change the shape of your data as your app evolves.
SQLMongoDB
{ 
a: “b”, 
c: “one”, 
e: “f”
}
{ 
a: “b”, 
c: 1, 
new: “no biggee”
}
ALTER TABLE `mydb`.`letters_table`
DROP COLUMN `e`,
ADD COLUMN `New` VARCHAR(45) NULL AFTER `C`,
CHANGE COLUMN `C` `C` INT NULL DEFAULT NULL ;

@JoeKarlsson1
Query faster!
Stop doing expensive joins to get your data.
SQLMongoDB
ID a ...
1 b ...
2 ... ...
3 ... ...
... ... ...
... ... ...
... ... ...
... ... ...
... ... ...
... ... ...
{
... 
a: “b”, 
...
c: { 
d: “e” 
... 
}, 
...
}

@JoeKarlsson1
Scale cheaper!
As the size of your server grows, scale horizontally.

@JoeKarlsson1
2) Discover the 4 humongous advantages of MongoDB

@JoeKarlsson1
1. Program faster
### First update what is stored in the Users table
sql = "UPDATE Users SET first_name=%s, surname=%s, cell=%s,
city=%s, location_x=%s, location_y=%s WHERE (ID=%s)" 
values = ( 
user["first_name"],  
user["surname"],  
user["cell"],  
user["city"],  
user["location_x"],  
user["location_y"],  
userId) 
mycursor.execute(sql, values)
mydb.commit()
### Since the user's data is stored in a single
document, we only have to make one update
result = db['Users'].update_one( 
{"_id": userId}, {"$set": user})

@JoeKarlsson1
2. Scale cheaper
1. Program faster

@JoeKarlsson1
3. Query faster
2. Scale cheaper
1. Program faster

@JoeKarlsson1
4. Pivot easier
3. Query faster
2. Scale cheaper
1. Program faster

Agenda
@JoeKarlsson1
1.Not all documents in a collection need to
have the same fields.
2.Data that is accessed together should be
stored together.
3.Stop using transactions regularly.

@JoeKarlsson1
Not all documents in a collection need to

@JoeKarlsson1
The Polymorphic Pattern
{
first_name: "Paul",
surname: "Miller",
cell: "447557505611",
city: "London",
location: [45.123,47.232],
cars: [
{
model: "Bentley",
year: 1973
},
{
year: 1965
}
]
}
{
cell: ”1235552222",
}
{
}

@JoeKarlsson1
The Outlier Pattern
{
_id: ”JoeKarlsson1",
displayName: ”JoeKarlsson1”,  
numFollowers: 2095
followers: [ 
“jessicaewest”, 
“wesley83”,  
“GraceFr” 
...
]
}
{
_id: ”KimKardashian",
displayName: ”Kim Kardashian
West",  
numFollowers: 62104245
followers: [ 
“c_hotaling”, 
“IAmJerdog”,  
“ChloeCondon” 
...
],
has_extras: true
{
_id: ”KimKardashian_1",
twitter_id: “KimKardashian”, 
is_overflow: true,
followers: [ 
“StephenAtHome”, 
“TheEllenShow”,  
“hulu” 
...
]
}

@JoeKarlsson1
Data that is accessed together should be
stored together.

@JoeKarlsson1
Storage vs Developer Costs
0
25000
50000
75000
100000
1985 2017
Storage Cost per GB
Developer Salary
stored together.

@JoeKarlsson1
stored together.
Don’t normalize your data for the sake of normalizing it.
{ 
a: “b”,
c: { 
d: “e” 
... 
},
f: [“g”, “h”, “i”],
j: [  
{
k: “l”
},  
{
m: “n”
}
]
}

@JoeKarlsson1
Stop using transactions regularly.
Relying on transactions is a bad design smell.
{
...
}
{
...
}
{
...
}
{
...
}
{
...
}
{
...
}
{
...
}

@JoeKarlsson1
3) Change your mindset in 3 key ways

@JoeKarlsson1
1. Not all documents in a collection need to have the same fields.
{
first_name: "Paul",
surname: "Miller",
cell: "447557505611",
city: "London",
location: [45.123,47.232],
cars: [
{
model: "Bentley",
year: 1973
},
{
year: 1965
}
]
}
{
cell: ”1235552222",
}
{
}

@JoeKarlsson1
2. Data that is accessed together should be stored together.
{ 
a: “b”,
c: { 
d: “e” 
... 
},
f: [“g”, “h”, “i”],
j: [  
{
k: “l”
},  
{
m: “n”
}
]
}

@JoeKarlsson1
2. Data that is accessed together should be stored together.
3. Stop using transactions regularly.
{
...
} {
...
} {
...
}
{
...
} {
...
} {
...
} {
...
}

MongoDB Community
• MongoDB University:
• university.mongodb.com 
• Recommended Course:
• M001: MongoDB Basics
@JoeKarlsson1

http://bit.ly/MongoDBChicago2019

Recommended Sessions:
• A MongoDB Journey: Moving from a Relational Database to MongoDB
Atlas [Northwestern Mutual]

• 9:30am - 10:15am: Ballroom 2

• Tutorial: Practical Data Modeling for MongoDB

• 12:30pm - 2:15pm: Ballroom 3

• Tips and Tricks++ for Querying and Indexing MongoDB [MongoDB]

• 2:35pm - 3:20pm: Ballroom 5
@JoeKarlsson1

{
name: “Joe Karlsson”,
company: “MongoDB”,
title: [
“Developer Advocate”,
“Software Engineer”
],
twitter: “@JoeKarlsson1”,
website: “joekarlsson.com”,
}

#MDBlocal
[Jumpstart] From SQL
to NoSQL - Changing
your Mindset
https://www.surveymonkey.com/r/6NS88JY
Every session you rate enters you into a
drawing for a $250 Visa gift card, sponsored by

Additional Resources
•http://bit.ly/MongoDBChicago2019
•$200 in free Atlas credits
• Advanced Schema Design Patterns (webinar)
• Building with Patterns: A Summary (blog
series)
• M320: Data Modeling (MongoDB University
Course)
@JoeKarlsson1

Additional Resources
@JoeKarlsson1
• The MongoDB Docs
• JSON Schema Validation – Locking down
your model the smart way
• JSON Schema Validation - Checking Your
Arrays
• M121: The MongoDB Aggregation Framework

MongoDB .local Chicago 2019: From SQL to NoSQL -- Changing Your Mindset

MongoDB .local Chicago 2019: From SQL to NoSQL -- Changing Your Mindset

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a MongoDB .local Chicago 2019: From SQL to NoSQL -- Changing Your Mindset

Semelhante a MongoDB .local Chicago 2019: From SQL to NoSQL -- Changing Your Mindset (20)

Mais de MongoDB

Mais de MongoDB (20)

Último

Último (20)

MongoDB .local Chicago 2019: From SQL to NoSQL -- Changing Your Mindset