MongoDB Schema Design (Event: An Evening with MongoDB Houston 3/11/15)

Schema Design

Sr. Solutions Architect, MongoDB, Inc. Jake Angerman

Agenda

•  Traditional Relational Model

•  MongoDB Document Model

•  Associating Entities in MongoDB

•  There will be a test at the end

Relational Model

Relational Model This is hard…

Long time to develop

Queries are complex

Difficult to change

What happens when the requirements change?

Hard to make changes New Table

New Table

New Column

Name Age Phone Email

New Column

Have to Manage Changes in 3 Places

Application

Code

Relational Database

Object Relational Mapping

XML Config DB Schema

Relational Model

Developers can be more productive

Application

Code

Developers can be more productive

Application

Code

Rich Queries Geospatial

Text Search

Map Reduce

Aggregation

The Document Model

Key → Value store

•  One-dimensional storage

•  Single value is a blob

•  Query on key only

•  No schema

•  Value can be replaced but not updated

Key Blob

Relational Record

•  Two-dimensional storage

•  Field contains a single value

•  Query on any field

•  Very structured schema

•  Poor data locality requires many tables, joins, and indexes.

Primary Key

MongoDB Document

_id •  N-dimensional storage

•  Field can contain many values and embedded values

•  Query on any field & level

•  Flexible schema

•  Optimal data locality requires fewer indexes and provides better performance

Documents are easier

Relational MongoDB { ! first_name: "Paul",! surname: "Miller"! city: "London",! location: [45.123,47.232],! cars: [ ! { model: "Bentley",! year: 1973,! value: 100000, … },! { model: "Rolls Royce",! year: 1965,! value: 330000, … }! }!}!

Terminology

MongoDB RDBMS

Document Row

Collection Table

Index Index

Embedded Document Join

Reference Foreign Key

Focus on data storage

Focus on data use

What answers do I have?

What questions do I have?

Modeling Data with MongoDB business card example

Business Card

Contact

Address

Referencing

Addresses {

_id : , street : , city : , state : ”, zip_code : , country :

}

Contacts { _id : , name : , title : , company : ”, phone : , address_id : }

Embedding

Contacts { _id : , name : , title : , company : , address : {

street : , city : , state : , zip_code : , country :

}, phone : }

Schema Flexibility – different shapes

{ _id: , name : , title : , company : , address : {

street : , city : , state : , zip_code :

}, phone : }

{ _id : , name : , url : , title : , company : , email : , address : { street : , city : , state : , zip_code : } phone : , fax }

{ “_id”: , “name”: , “title”: , “company”: , “address”: [

{ “street”: , “city”: , “state”: , “zip_code”: , “country”:

}, { “street”: , “city”: , “state”:

} ], “phone”: }

Schema Flexibility – easily changed

{ _id : , name : , title : , company : , address : {

street : , city : , state : , zip_code : , country :

}, phone : }

Modeling Data with MongoDB address book example

Address Book Entity-Relationship

Contacts

•  name •  company •  title

Addresses •  type •  street •  city •  state •  zip_code

Phones •  type •  number

Emails •  type •  address

Thumbnails •  mime_type •  data

Portraits •  mime_type •  data

Groups •  name

N

1

N

1

N

N

N

1

1

1

1 1

Twitter •  name •  location •  web •  bio

1

1

One-to-One

Contacts







Groups •  name

N

1

N

1

N

N

N

1

1

1

1 1

Twitter •  name •  location •  web •  bio

1

1

contact

•  twitter_id

twitter 1 1

Contact •  twitter

twitter 1

Schema Design Choices One-to-One

Contact •  twitter

twitter 1

You can query or index on embedded fields. For example:

db.contacts.find( { "twitter.account" : "@Decameron" } )

General Recommendation One-to-One

{ _id : 1375-12-21, name : "Giovanni Boccaccio", twitter : { account : "@Decameron", page : "https://twitter.com/RealBoccaccio" } }

One-to-Many

Contacts







Groups •  name

N

1

N

1

N

N

N

1

1

1

1 1

Twitters •  name •  location •  web •  bio

1

1

contact

•  phone_ids: [ ]

phone 1 N

Contact •  phones

phone N

Schema Design Choices One-to-Many

Contact •  phones

phone N

General Recommendation One-to-Many Few

{ _id : 1375-12-21, name : "Giovanni Boccaccio", twitter : { account : "@Decameron", page : "https://twitter.com/RealBoccaccio" } phone : [ work : "+39 0571-669811", home : "+39 671-946726", mobile : "+39 671-038747" ] }

Contacts







Groups •  name

N

1

N

1

N

N

N

1

1

1

1 1

Twitters •  name •  location •  web •  bio

1

1

Many-to-Many

Contacts •  name •  company •  title •  phone

Groups •  name

GroupContacts •  group_id •  contact_id

Use arrays instead

XTraditional Relational Association

Join Table

Many-to-Many

group

•  contact_ids: [ ]

contact N N

group contact •  group_ids: [ ] N N

Duplicated data must be updated for consistency

group •  contacts

contact N

contact •  groups

group N

Schema Design Choices

Many-to-Many

Reference Embed

group contact •  group_ids: [ ] N N

Many-to-Many

•  Use case: address book

•  Contact references groups

Reference

group

•  contacts

contact N

Many-to-Many

•  Use case: corporate email system

•  Group embeds contacts for performance

Embed

Contacts •  name •  company •  title

addresses •  type •  street •  city •  state •  zip_code

phones •  type •  number

emails •  type •  address

thumbnail •  mime_type •  data


Groups •  name

N

1

N

1

twitter •  name •  location •  web •  bio

N

N

N

1

1

Document model - holistic and efficient representation

Contact document example {

“name” : “Gary J. Murakami, Ph.D.”, “company” : “MongoDB, Inc.”, “title” : “Lead Engineer”, “twitter” : { “name” : “Gary Murakami”, “location” : “New Providence, NJ”, “web” : “http://www.nobell.org” }, “portrait_id” : 1, “addresses” :

, “phones” :

, “emails” :

}

Free training at university.mongodb.com

Download at mongodb.org/downloads

25% off discount code: JakeAngerman

MongoDB Schema Design (Event: An Evening with MongoDB Houston 3/11/15)

Data & Analytics