Webinar: How We Evaluated MongoDB as a Relational Database Replacement

Brig Lamoreaux
Shekhar Vemuri
Apollo Group
12/12/12

brig.lamoreaux@apollogrp.edu
briglamoreaux.wordpress.com1

•  Tell
our
story

•  Teach
evalua/on
Principles

•  Share
our
Results

2

•  Company
Overview:
Who
we
are.

•  Background:
Looking
beyond
rela3onal

•  The
Problem:
We
have
no
exper3se
in
MongoDB

•  Approaching
MongoDB?
How
do
we
solve
this
problem

•  Results.
What
did
we
learn

3

•  Founded
in
1973

•  Leading
provider
of
higher
educa3on
for
working
adults

•  Parent
company
of

–  University
of
Phoenix

–  Apollo
Global

–  Apollo
Educa3on
Services

–  Carnegie
Learning

–  College
of
Financial
Planning

–  Ins3tute
for
Professional
Development

•  Educate
over
350
thousand
students
per
year

5

We don’t know anything about MongoDB

18

Methodology / Approach

19

•  Gain
valuable
informa3on

about
terrain

•  Viable
vs
100%

•  Boyed
Loop

–  Observe

–  Orient

–  Decide

–  Act

20

•  Gain
valuable
informa3on

about
terrain

•  Accept
Threshold

–  Viable
vs
100%

•  Boyed
Loop

–  Observe

–  Orient

–  Decide

–  Act

22

•  Problem

•  Objec3ve

•  Timetable

•  Gather
Info

23

Two
week
phased
approach

•  Phase
1.
Form
Team,
goals,
data

•  Phase
2.
Develop
Model,
small
server

•  Phase
3.
Large
deployment

•  Phase
4.
Performance
test

25

Implemen3ng
a
new
repository
solu3on
introduces

new
areas
of
needs
such
as:

•  Plan
and
deploy
a
solu3on

•  Opera3onal
procedures

•  Designing
object
models

•  Determine
MongoDB
Client
and
Frameworks

•  Measuring
eﬀec3veness

26

What
do
we
want
to
know
about
MongoDB

•  Resiliency

•  Stability

•  Adaptability
of
Data
Model

•  Performance

•  Conﬁgura3on
Flexibility

•  Time
to
Implement

•  Administrator
Func3onality

•  Training

•  Data
Migra3on

•  Conformity
with
Standards

•  Quality
of
Support

27

Conference 10gen Training 10gen Lab
Consulting Env.

Run Book
(Deploy) X X X
Run Book
(Maintenance) X X X
Object Model
X X X X
Measure
Effectiveness X
Java Client
X

29

Course
Oﬀering
System:

•  Manages
Courses

•  Manages
enrolment
status
of
students
in
course

•  Balances
number
of
students
in
course

•  Schedules
faculty
to
teach

30

•  Design
Data
Model

•  Small
Server

•  Run
Use
Case

32

SQL ID Executions Percentage
15,572,099 46%
4,339,293 13%
3,232,297 10%
3,016,176 9%
2,541,686 8%
2,485,334 7%
2,384,839 7%

34

{

"_id":
"8738728763872",

"role"
:
"Student",

"user
:{

"id"
:
"b7ed789f198a",

"firstName"
:
"Rick",

"lastName"
:
"Matin"

},

"course"
:
{

"dateRange"
:
{

"startDate"
:
ISODate("2011-‐12-‐30T07:00:00Z"),

"endDate"
:
ISODate("2012-‐01-‐30T07:00:00Z")

},

"courseId"
:
"734234274",

"code"
:
"MATH/101",

"title"
:
"Introduction
to
Mathematics"

}

}

35

•  Analyze
our
Data*

–  Applica3on
API
review

–  Performance

–  Call
Type

–  Query/Data
Usage

•  Small
Scope

* One of the pearls discovered

36

•  Install
and
Ac/vate.
We
quickly
spun
up
a
blank

virtual
machine

on
Amazon
EC2,
and
then
installed

MongoDB
on
it.

•  Populate
with
Data.
We
used
approximately
300,000

very
simple
records.
We
used
a
Python
script
to

import
the
data

37

•  MongoDB
Farm
Architecture

•  Chef/Puppet
Scripts
to

–  Deploy
new
farm

–  Add
replica3on
sets

•  Monitor
Servers

•  High
Avail.

•  Disaster
Recoverability

38

Configuration Results

A: Clients on Same Typical Response Time: 0-1.7 ms
Machine Maximum Throughput: 9,000 queries/sec CPU-bound.
Typical CPU Utilization: 100%
B: Clients and Typical Response Time: 1.2-8.5 ms
MongoDB on Maximum Throughput: 12,000 queries/sec
Separate Amazon Typical CPU Utilization: 80%

C: Clients and Typical Response Time: 1.2-10.6 ms
MongoDB in Maximum Throughput: 12,200 queries/sec
Separate Typical CPU Utilization: 85%
Availability Zones, Approximately the same response time, throughput, and CPU
but within One utilization as Configuration B.
Amazon EC2
Region
D: Clients and Typical Response Time: 85.6-87.3 ms.
MongoDB in Maximum Throughput: 1,600 queries/sec
Different Amazon Typical CPU Utilization: 2%. Very low; EC2 instance was
EC2 Regions unstressed.
East coast-west coast network was bottleneck in this
configuration – EC2 instances were not stressed. Response
times were much higher than when instances were located
within a single Amazon EC2 region (configurations B & C).

39

Primary

•  Data
driven
Data
Model

•  Data
driven
deployment
architecture

•  Hybrid
deployment
are
possible
(Cloud,
on
premise)

•  High
latency
between
EC2
regions

•  85%
CPU
Mongo
behavior
changes

Secondary

•  Opera3ons/Developer/DBA
trained

•  Roadmap
Development/opera3ons/

44

Evalua3ng

•  Fail
Fast

•  Boyd
loop

•  Stand
on
the
shoulders
of
others

•  Have
a
prac3cal
use
case

Paper
vs.
Real
live

•  Time
table
was
more
organic

•  Nice
list
of
evalua3on
items

•  Weekly
changes

•  Usage
data
slowly
came
in

•  Learned
as
we
went
45

•  8
applica3ons/services
built
or
being
built
on
top
of
Mongo

–  More
being
discussed

•  Content
Management
system
moving
to
mongodb

•  No
sharding
yet

•  Developer
experience
has
been
good
so
far

•  Deﬁnitely
a
learning
curve
in
moving
from
rela3onal
schema

design
to
document
schema
design

–  Personal
experience
has
been
to
do
some
analysis,
build
an
end
to
end

test
and
then
iterate

–  Pay
aden3on
to
access
paderns

•  Plans
to
move
towards
Cross
region
deployments

46

Webinar: How We Evaluated MongoDB as a Relational Database Replacement

More Related Content

Similar to Webinar: How We Evaluated MongoDB as a Relational Database Replacement

More from MongoDB

Recently uploaded

Webinar: How We Evaluated MongoDB as a Relational Database Replacement