Webinar: Best Practices for Evaluating MongoDB
 

Webinar: Best Practices for Evaluating MongoDB

on

  • 1,270 views

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.

Statistics

Views

Total Views
1,270
Views on SlideShare
820
Embed Views
450

Actions

Likes
6
Downloads
57
Comments
0

7 Embeds 450

http://www.mongodb.com 410
https://www.mongodb.com 30
https://live.mongodb.com 4
http://www.slideee.com 3
http://bigg.icmb.utexas.edu 1
https://corpwww-dev-drupal.10gen.com 1
https://comwww-drupal.10gen.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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

Webinar: Best Practices for Evaluating MongoDB Webinar: Best Practices for Evaluating MongoDB Presentation Transcript

  • Best Practices for Evaluating MongoDB Thomas Boyd Senior Solutions Architect, MongoDB April 2, 2014
  • 2 • Data stores, NoSQL, & MongoDB • Software Evaluation Principles • Functionality • Performance • Scalability • Organizational Readiness • MongoDB “Path to Proof” Program Agenda
  • Data Stores, NoSQL & MongoDB
  • 4 Data store landscape is Fuzzy Source: 451 Group, http://blogs.the451group.com/information_management/2012/11/02/updated-database-landscape-graphic, 2012
  • 5 Data store landscape
  • 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
  • Software Evaluation Principles
  • 8 1) Know your Use Case(s) Three Practical Rules 2) Involve your Stakeholders 3) Formalize you Evaluation
  • 9 Formal Details
  • 10 Formal Summary
  • 11 A Fourth Rule? 4) Fish or Cut Bait
  • Functionality
  • 13 Data Write Functionality • Data types • Field-level updates • Upsert • Test and Set • Array operations • BLOB support • Transaction support • more …
  • 14 Data Read Functionality • Primary key lookups • Secondary index lookups • Range scans • Complex queries • Aggregations • Map-Reduce • Geospatial queries • Text search • more…
  • 15 3rd Party Integrations • ETL Tools • Reporting Tools • Hadoop Integrations • more…
  • 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 Right Tool for the Right Job
  • 18 Data HubUser Data Management Big Data Content Mgmt & Delivery Mobile & Social Wide ranging use cases
  • Performance
  • 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 Finding the Knee working set size latency throughput i/o boundmemory
  • 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 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 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: http://docs.mongodb.org/ecosystem/use-cases/
  • Scalability
  • 26 Looking for linear scaling Number of nodes latency throughput
  • 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 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 A word about Gorillas
  • Organizational Readiness
  • 31 Lots of Resources Resource Location MongoDB Downloads mongodb.com/download Free Online Training education.mongodb.com Webinars and Events mongodb.com/events White Papers mongodb.com/white-papers Case Studies mongodb.com/customers Presentations mongodb.com/presentations Documentation docs.mongodb.org Additional Info info@mongodb.com Resource Location
  • 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 Manage you Project’s Risk • Understand Project Criticality • Training • Proactive monitoring • Development to Operations Handoff Procedures • Defined escalation paths • Testing, including Ops Procedures
  • MongoDB Path to Proof Program
  • 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 Path to Proof Program • Three Simple Steps – Form: http://www.mongodb.com/lp/path-proof-program – MongoDB Engineer will evaluate fit for Program – If accepted, account rep with coordinate call with MongoDB Engineer
  • http://www.mongodb.com/lp/path-proof-program