Your SlideShare is downloading. ×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Webinar: Best Practices for Evaluating MongoDB


Published on

When it comes time to select a datastore for your project, there are a bewildering number of choices. How do you know if your project is a good fit for a relational database, or whether one of the …

When it comes time to select a datastore for your project, there are a bewildering number of choices. How do you know if your project is a good fit for a relational database, or whether one of the many NoSQL options is a better choice? In this webinar you will learn how to evaluate if MongoDB is a fit for your project. You will see how MongoDB's flexible document model is solving business problems in ways that were not previously possible, and how MongoDB's built-in features allow running at extreme scale. Topics will include evaluating MongoDB's functionality, performance, and scalability, as well as a discussion on how to ensure your organization is prepared to run MongoDB in a production environment. Practical examples and customer stories will be included to help you bootstrap your MongoDB evaluation.

Published in: Technology
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • Dotted line is the natural boundary of what is possible today. Eg, ORCL lives far out on the right and does things nosql vendors will ever do. These things come at the expense of some degree of scale and performance.NoSQL born out of wanting greater scalability and performance, but we think they overreacted by giving up some things. Eg, caching layers give up many things, key value stores are super fast, but give up rich data model and rich query model.MongoDB tries to give up some features of a relational database (joins, complex transactions) to enable greater scalability and performance. You get most of the functionality – 80% - with much better scalability and performance. Start with rdbms, ask what could we do to scale – take out complex transactions and joins. How? Change the data model. >> segue to data model section.May need to revise the graphic – either remove the line or all points should be on the line.To enable horizontal scalability, reduce coordination between nodes (joins and transactions). Traditionally in rdbms you would denormalize the data or tell the system more about how data relates to one another. Another way, a more intuitive way, is to use a document data model. More intuitive b/c closer to the way we develop applications today with object oriented languages, like java,.net, ruby, node.js, etc. Document data model is good segue to next section >> Data Model
  • Transcript

    • 1. Best Practices for Evaluating MongoDB Thomas Boyd Senior Solutions Architect, MongoDB April 2, 2014
    • 2. 2 • Data stores, NoSQL, & MongoDB • Software Evaluation Principles • Functionality • Performance • Scalability • Organizational Readiness • MongoDB “Path to Proof” Program Agenda
    • 3. Data Stores, NoSQL & MongoDB
    • 4. 4 Data store landscape is Fuzzy Source: 451 Group,, 2012
    • 5. 5 Data store landscape
    • 6. 6 Database for how we build and run many of today’s applications MongoDB in Practice Build – New and complex data – Flexible – New languages – Faster development Run – Big Data scalability – Real-time – Commodity hardware – Cloud Documents + Rich Data Access + Performance & Scale
    • 7. Software Evaluation Principles
    • 8. 8 1) Know your Use Case(s) Three Practical Rules 2) Involve your Stakeholders 3) Formalize you Evaluation
    • 9. 9 Formal Details
    • 10. 10 Formal Summary
    • 11. 11 A Fourth Rule? 4) Fish or Cut Bait
    • 12. Functionality
    • 13. 13 Data Write Functionality • Data types • Field-level updates • Upsert • Test and Set • Array operations • BLOB support • Transaction support • more …
    • 14. 14 Data Read Functionality • Primary key lookups • Secondary index lookups • Range scans • Complex queries • Aggregations • Map-Reduce • Geospatial queries • Text search • more…
    • 15. 15 3rd Party Integrations • ETL Tools • Reporting Tools • Hadoop Integrations • more…
    • 16. 16 Ops/Admin Functionality • Setup and Maintenance • Monitoring and troubleshooting • Security • High availability • Geographically distributed clusters • Backup and Restore • Chef/Puppet build scripts • GUI for cluster maintenance • more…
    • 17. 17 Right Tool for the Right Job
    • 18. 18 Data HubUser Data Management Big Data Content Mgmt & Delivery Mobile & Social Wide ranging use cases
    • 19. Performance
    • 20. 20 Understand your Targets • Crisp definition of each use case/transaction – Average throughput – Peak throughput (per second) – Timing of Peak – Latency Requirement (95th/99th percentile?) – Expected change (growth/decline) over time • Test your Workload – Full read/write mix – Maybe multiple scenarios
    • 21. 21 Finding the Knee working set size latency throughput i/o boundmemory
    • 22. 22 Isolate & Measure • Clean, repeatable tests • Automate metrics gathering • Look for bottlenecks at all components/layers – CPU – Disk – Network – Application/test harness tier – Data store tier
    • 23. 23 Selecting a Test Harness • Time invested versus meaningful results – Your full application stack – Running your app code inside test harness – Generic DB test harnesses • Understand critical MongoDB settings – Write concern, read preference, connection pool size, etc.
    • 24. 24 MongoDB: Schema & Indexing • Look out for a few common mistakes – Breaking data into to many separate documents – Documents that grow without bounds – Missing or sub-optimal indexes – Too many indexes – Expecting change (growth/decline) over time • Lots of experience with different use cases:
    • 25. Scalability
    • 26. 26 Looking for linear scaling Number of nodes latency throughput
    • 27. 27 MongoDB: Replica Set & Sharing • Replica Sets – High availability – Maintenance – Workload isolation – Some read scaling • Sharding – Horizontal scaling – Shard key is crucial – # of router processes
    • 28. 28 MongoDB Performance Top 5 Marketing Firm Government Agency Top 5 Investment Bank Data Key/value 10+ fields, arrays, nested documents 20+ fields, arrays, nested documents Queries Key-based 1 – 100 docs/query 80/20 read/write Compound queries Range queries MapReduce 20/80 read/write Compound queries Range queries 50/50 read/write Servers ~250 ~50 ~40 Ops/sec 1,200,000 500,000 30,000 * These figures are provided as examples. Your application governs your performance.
    • 29. 29 A word about Gorillas
    • 30. Organizational Readiness
    • 31. 31 Lots of Resources Resource Location MongoDB Downloads Free Online Training Webinars and Events White Papers Case Studies Presentations Documentation Additional Info Resource Location
    • 32. 32 MongoDB Products and Services Training Online and In-Person for Developers and Administrators MongoDB Management Service (MMS) Cloud-Based Suite of Services for Managing MongoDB Deployments Subscriptions MongoDB Enterprise, MMS (On-Prem), Professional Support, Commercial License Consulting Expert Resources for All Phases of MongoDB Implementations
    • 33. 33 Manage you Project’s Risk • Understand Project Criticality • Training • Proactive monitoring • Development to Operations Handoff Procedures • Defined escalation paths • Testing, including Ops Procedures
    • 34. MongoDB Path to Proof Program
    • 35. 35 Path to Proof Program • MongoDB Engineering sponsored Program – Personal, expert advice on your project – Accelerate your evaluation of MongoDB – Complementary – No Obligation – Limited Time Offer
    • 36. 36 Path to Proof Program • Three Simple Steps – Form: – MongoDB Engineer will evaluate fit for Program – If accepted, account rep with coordinate call with MongoDB Engineer
    • 37.