Mysql to mongo

MYSQL TO
MONGO (FTW)
Thinking Differently About Schema Design

@AJSHARP

Alex Sharp
Lead Developer, OptimisCorp

alexjsharp.com

github.com/ajsharp

CVBEAST
Mongo has many cool
features such as schema-
free, aggregation w
map/reduce and many
others
Side project

interested more in
domain modeling more
than performance and
scaling benefits of
Mongo

EMBEDDED OBJECTS

CVBEAST

App to represent people’s curriculum vitae, but not in an
academic sense

CVBEAST

Focus on “micro” experiences not suitable for a typical CV
(deﬁnitely not suitable for a resumé)

CVBEAST

Simple object model, centered around highlighting attributes
of a person

CVBEAST

Started out building with MySQL, b/c it’s familiar

OBJECT MODEL
Person

has a

CV

has many

Experience

has many

... ... ...

OBJECT MODEL
Person

has a

CV

links, tags, and has many
other arbitrary
properties Experience

has many

... ... ...

RELATIONAL SCHEMA
people
- id
- name
- ...

cvs
- id
- person_id
- ...

experiences
- id
- cv_id
- ...

RELATIONAL SCHEMA

Lots of pointless JOINs

RELATIONAL SCHEMA
people
- id
- name
- ...

cvs tags
- id
- id - name
- person_id - ...
- ...
links
experiences - id
- name
- id - ...
- cv_id
- ...

not b/c of premature
optimization

this bothers me

It misrepresents the object model
at the storage layer

It also became difﬁcult to work with
despite my familiarity with MySQL

It makes sense to store object relationships in
ﬁrst-class entities/documents/tables

But true object properties should be
stored as properties

Especially when properties have no practical
meaning without the parent

CAVEAT

This is not always the case.

;-)
if you need to:
* store LOTS of embedded objects (i.e. papermill)

EXPERIENCE.LINKS = [...]

Dead-simple collection of links attached to
an experience

RUBY MODEL CODE
class Person
include Mongoid::Document

field :keywords, :type => Array

index :keywords
index 'cv.experiences.tags'
end

class Experience

embeds_many :links
end

class Link

field :url
field :title
embedded_in :experience, :inverse_of => :links
end

class Experience

embeds_many :links
end Both models are embedded in the
person collection
class Link

field :url
field :title
embedded_in :experience, :inverse_of => :links
end


A link is only relevant inside the
context of an experience object.


In other words, it is a property,
not a relationship.


Mongo brings the storage layer closer to
the object model

{
"title": "Presented at MongoLA",
"links": [
{ "title": "Event Site",
"url": "http://www.10gen.com/conferences/mongola2011"},
{ "title": "Slides",
"url": "http://alexjsharp.com/posts/mongola-2010-slides"}
]
}

MYSQL
An exercise in masochism

The difﬁculty in MySQL came in working with
properties of a person

These properties are represented as tables

SIMPLE SEARCH QUERY
select * from people
inner join cvs on cvs.person_id = people.id
inner join experiences on experiences.cv_id = cvs.id
inner join tags on tags.experience_id = experiences.id
where tags.name = 'ruby';

INDEXES NEEDED
- tags.experience_id
- tags.name
- experiences.cv_id
- cvs.person_id

Seems extremely unnecessary for such a
simple object model

MONGO
An exercise in ... not masochism

Embedded objects make this query easy.

MONGO DOCUMENT “SCHEMA”
{"name": "Alex Sharp",
"cv": {
"experiences": [
{ "title": "spoke at MongoLA",
"date" : "Thu Jan 13 2011",
"tags" : ["mongodb", "speaking"]
},
{"title": "..."}
]
}
}

MONGO DOCUMENT “SCHEMA”
{"name": "Alex Sharp",
"cv": {
"experiences": [
{ "title": "spoke at MongoLA",
"date" : "Thu Jan 13 2011",
"tags" : ["mongodb", "speaking"]
},
{"title": "..."}
]
}
}
we want to search for these

RUBY MODEL CODE
class Cv

embeds_many :experiences
end

class Experience

field :tags, :type => Array, :default => []

embedded_in :cv, :inverse_of => :experiences
embeds_many :links

after_save lambda { |exp| exp.cv.person.update_keywords }
end

RUBY MODEL CODE
class Cv
simple property
embeds_many :experiences
end (not relationship)
class Experience

field :tags, :type => Array, :default => []

embedded_in :cv, :inverse_of => :experiences
embeds_many :links

after_save lambda { |exp| exp.cv.person.update_keywords }
end

RUBY SEARCH CODE
class Person

# i.e. db.people.find({"cv.experiences.tags": "ruby"})
def self.search_by_tag(term)
collection.find('cv.experiences.tags' => 'ruby')
end

end

COMPARISON
select * from people
inner join cvs on cvs.person_id = people.id
inner join experiences on experiences.cv_id = cvs.id
inner join tags on tags.experience_id = experiences.id
where tags.name = 'ruby';

vs
db.people.find('cv.experiences.tags' => 'ruby')

WINS: IMPEDENCE MIS-MATCH

Object persistence format is closer to
application usage format

WINS: F(X)-ALITY

Plus, we don’t lose any functionality.

WINS: FAMILIARITY

Indexing principles are extremely familiar to
relational database users.

WINS: FAMILIARITY

Only simpler ;)

WINS: SIMPLICITY

Query syntax is simple.

WINS: SIMPLICITY

Dot notation > JOIN semantics ﬁlth

SUMMARY

Mongo is perfectly suited for
an app like CVBeast.

SUMMARY

Where a relational DB forces storing
object properties as relationships

SUMMARY

Mongo narrows this mismatch considerably

SUMMARY

A CV is a document...

SUMMARY

So a document-oriented datastore
seems appropriate.

SUMMARY

Many object models have this
tree-like structure.

SUMMARY

Be willing to step outside of your comfort zone

SUMMARY

And use Mongo when it’s practical.

Mysql to mongo

More Related Content

What's hot (20)

Similar to Mysql to mongo (20)

More from Alex Sharp (9)

Recently uploaded (20)

Mysql to mongo