Webinar: How We Evaluated MongoDB as a Relational Database Replacement

2,037 views

Published on

This webinar will explain the process, methodology, and results used at Apollo Group to evaluate MongoDB and ultimately replace Oracle for a core platform component.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,037
On SlideShare
0
From Embeds
0
Number of Embeds
1,343
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Webinar: How We Evaluated MongoDB as a Relational Database Replacement

  1. 1. Brig Lamoreaux Shekhar Vemuri Apollo Group 12/12/12brig.lamoreaux@apollogrp.edu briglamoreaux.wordpress.com1
  2. 2. •  Tell  our  story  •  Teach  evalua/on  Principles  •  Share  our  Results   2
  3. 3. •  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
  4. 4. Company Overview 4
  5. 5. •  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
  6. 6. 6
  7. 7. 7
  8. 8. 8
  9. 9. 9
  10. 10. 10
  11. 11. 11
  12. 12. 12
  13. 13. 13
  14. 14. 2_ 1 _ > 1017 14
  15. 15. 15
  16. 16. The Problem 16
  17. 17. 17
  18. 18. We don’t know anything about MongoDB 18
  19. 19. Methodology / Approach 19
  20. 20. •  Gain  valuable  informa3on    about  terrain  •  Viable  vs  100%  •  Boyed  Loop   –  Observe   –  Orient   –  Decide   –  Act     20
  21. 21. 21
  22. 22. •  Gain  valuable  informa3on    about  terrain  •  Accept  Threshold     –  Viable  vs  100%  •  Boyed  Loop   –  Observe   –  Orient   –  Decide   –  Act     22
  23. 23. •  Problem  •  Objec3ve  •  Timetable  •  Gather  Info     23
  24. 24. The Results 24
  25. 25. 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
  26. 26. 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  effec3veness     26
  27. 27. What  do  we  want  to  know  about  MongoDB    •  Resiliency  •  Stability  •  Adaptability  of  Data  Model  •  Performance  •  Configura3on  Flexibility  •  Time  to  Implement  •  Administrator  Func3onality  •  Training  •  Data  Migra3on  •  Conformity  with  Standards  •  Quality  of  Support   27
  28. 28. 28
  29. 29. Conference 10gen Training 10gen Lab Consulting Env.Run Book(Deploy) X X XRun Book(Maintenance) X X XObject Model X X X XMeasureEffectiveness XJava Client X 29
  30. 30. Course  Offering  System:    •  Manages  Courses  •  Manages  enrolment  status  of  students  in  course  •  Balances  number  of  students  in  course  •  Schedules  faculty  to  teach   30
  31. 31. 31
  32. 32. •  Design  Data  Model  •  Small  Server  •  Run  Use  Case     32
  33. 33. 33
  34. 34. 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
  35. 35. {      "_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
  36. 36. •  Analyze  our  Data*   –  Applica3on  API  review   –  Performance   –  Call  Type   –  Query/Data  Usage   •  Small  Scope  * One of the pearls discovered 36
  37. 37. •  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
  38. 38. •  MongoDB  Farm  Architecture  •  Chef/Puppet  Scripts  to   –  Deploy  new  farm   –  Add  replica3on  sets  •  Monitor  Servers  •  High  Avail.  •  Disaster  Recoverability   38
  39. 39. Configuration ResultsA: Clients on Same Typical Response Time: 0-1.7 msMachine Maximum Throughput: 9,000 queries/sec CPU-bound. Typical CPU Utilization: 100%B: Clients and Typical Response Time: 1.2-8.5 msMongoDB on Maximum Throughput: 12,000 queries/secSeparate Amazon Typical CPU Utilization: 80%C: Clients and Typical Response Time: 1.2-10.6 msMongoDB in Maximum Throughput: 12,200 queries/secSeparate Typical CPU Utilization: 85%Availability Zones, Approximately the same response time, throughput, and CPUbut within One utilization as Configuration B.Amazon EC2RegionD: Clients and Typical Response Time: 85.6-87.3 ms.MongoDB in Maximum Throughput: 1,600 queries/secDifferent Amazon Typical CPU Utilization: 2%. Very low; EC2 instance wasEC2 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
  40. 40. Local Client 40
  41. 41. Same Zone 41
  42. 42. Same Region 42
  43. 43. Two Regions 43
  44. 44. 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
  45. 45. 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
  46. 46. •  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  •  Definitely  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
  47. 47. Questions 47
  48. 48. End 48
  49. 49. Appendix 49
  50. 50. 50

×