Use Case: Apollo Group at Oracle Open World

Like this? Share it with your network

Share

Use Case: Apollo Group at Oracle Open World

  • 1,030 views
Uploaded on

Slides from Brig Lamoreaux's of Apollo Group talk at Oracle Open World 2012 on their use case with MongoDB.

Slides from Brig Lamoreaux's of Apollo Group talk at Oracle Open World 2012 on their use case with MongoDB.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to like this
No Downloads

Views

Total Views
1,030
On Slideshare
993
From Embeds
37
Number of Embeds
11

Actions

Shares
Downloads
8
Comments
1
Likes
0

Embeds 37

http://www.10gen.com 9
http://ww.mongodb.org 6
http://pinterest.com 6
http://ww.w.mongodb.org 4
http://iwvhrfe.mongodb.org 4
http://www.linkedin.com 3
http://sample-php.10gen.com 1
http://archive.10gen.com 1
http://tray.mongodb.org 1
http://babble.10gen.com 1
http://aws.10gen.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • We decided to look for a solution with a better technological fitand the team developed a short list of potential solutions. While we strongly favored a solution that was already in-house, we added MongoDB to the short list because our research indicated that it might provide excellent query performance with less investment in software licenses and hardware than other solutions. However, our primary concern with MongoDB was that we had no hands-on experience with it. Apollo management tasked the Forward Engineering group within IT – my team – with assessing MongoDB. We responded with an evaluation process designed to determine in a rigorous yet time-sensitive manner whether it would suit our needs.
  • At the outset, our mission was somewhat loosely defined: to learn about MongoDB and to determine its suitability as a data store. Nevertheless, we identified specific areas of focus.
  • Our problem was “We didn’t know anything about MongoDB”.We have a saying on Forward Engineering to Fail Fast. So how do we fill in the gaps quickly? We engage the experts, the community, and get our hands dirty with a lab environment.
  • Reached out to our Operations Team to help stand up a large farm and automate.Our Architecture Standards Groups requires High Availability and Disaster Recoverability.(Keep in mind, our standard for success in Forward Engineering is the 80% rule.
  • The most fundamental difference between Oracle and MongoDB is the data modelThe scope was limited to Course offering. What courses are offered and who is associated with each course (student, faculty)
  • The most important analysis was looking at our queries. There were several tables, many joins, and several indexes. We found more than 75% of the queries we all about finding which people are in which classes.Query 1. Find Courses for a givent studentQuery 2. Find users in a given courseQuery 3. Find courses for a facultyAnd so on
  • The scope was limited to Course offering. What courses are offered and who is associated with each course (student, faculty)
  • The scope was limited to Course offering. What courses are offered and who is associated with each course (student, faculty)
  • The scope was limited to Course offering. What courses are offered and who is associated with each course (student, faculty)
  • The scope was limited to Course offering. What courses are offered and who is associated with each course (student, faculty)

Transcript

  • 1. Brig Lamoreaux Apollo Group Oracle Open World 2012brig.lamoreaux@apollogrp.edu briglamoreaux.wordpress.com 1
  • 2. • Company Overview• The Problem• Approaching MongoDB?• Results 2
  • 3. Company Overview 3
  • 4. • Founded in 1973• Leading provider of higher education for working adults• Parent company of – University of Phoenix – Apollo Global – Carnegie Learning – College of Financial Planning – Institute for Professional Development• Educate over 350 thousand students per year 4
  • 5. The Problem 5
  • 6. • Scalability. We were unable to scale our current system to support the anticipated number of users and volume of content, which would increase significantly as we would add applications to the platform.• Technology Fit. Much of the data targeted for the platform was semi-structured and thus not a natural fit with relational databases.• Experience. We have experience in traditional databases with developing, maintaining, and defined processes but we don’t know how many of these skills can transfer to MongoDB. 6
  • 7. Approaching MongoDB? 7
  • 8. Implementing a new repository solution introducesnew areas of needs such as:• Plan and deploy a solution• Operational procedures• Designing object models• Determine MongoDB Client and Frameworks• Measuring effectiveness 8
  • 9. 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 9
  • 10. The Results 10
  • 11. • MongoDB Farm Architecture• Chef/Puppet Scripts to – Deploy new farm – Add replication sets• Monitor Servers• High Avail.• Disaster Recoverability 11
  • 12. • Analyze our Data* – Application API review – Performance – Call Type – Query/Data Usage • Small Scope* One of the pearls discovered 12
  • 13. 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% 13
  • 14. 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). 14
  • 15. 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 changesSecondary • Operations/Developer/DBA trained • Roadmap Development/operations/ 15
  • 16. Questions 16
  • 17. End 17
  • 18. Appendix 18
  • 19. Local Client 19
  • 20. Same Zone 20
  • 21. Same Region 21
  • 22. Two Regions 22