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.
4. 4
Data store landscape is Fuzzy
Source: 451 Group, http://blogs.the451group.com/information_management/2012/11/02/updated-database-landscape-graphic, 2012
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
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…
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
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:
http://docs.mongodb.org/ecosystem/use-cases/
31. 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. 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
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: 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
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