The document outlines a two-part webinar series on MongoDB application development and operations. The first part will cover schema design, querying, indexing, and aggregation over four sessions. The second part will cover deployment, monitoring, and backup/recovery over three sessions. An example application will be a content management system utilizing MongoDB features like querying, geospatial queries, and aggregation. Questions can be asked via the online chat.

1. Staffel 1: MongoDB
Applikationsentwicklung
Marc Schwering
@m4rcsch
#MongoDBBasics
Einführung in MongoDB – “Back to Basics”

2. 2
• Fragen im Chat oder via Twitter:
#MonogDBBasics
• Das Webinar ist auf deutsch, die Folien sind in
englisch
• Die Serie wird ist in zwei Staffeln gegliedert
– Applikationsentwicklung mit MongoDB
– MongoDB in produktion / „operations“
• Das Webinar wird aufgezeichnet
Generelle Informationen

3. 3
• About the Webinar Series
• Data Model
• Query Model
• Scalability
• Availability
• Deployment Architectures
• Performance
• Next Session
Introduction

4. 4
• Split into 2 seasons
– Application Development (4 parts)
• Schema Design
• Interacting with the database query and update operators
• Indexing
• Aggregation & Reporting
– Operations (3 parts)
• Deployment – scale out and high availability
• Monitoring and performance tuning
• Backup and recovery
Series Outline & Approach

5. 5
• Content Management System
– Will utilise :
• Query & update operators
• Aggregation Framework
• Geospatial queries
• Pre Aggregated reports for fast analytics
• Polymorphic documents
• And more…
• Take away framework
• An approach that you can reuse in your own
applications
Application Overview

6. 6
• Virtual Genius Bar
– Use the chat to post
questions
– EMEA Solution
Architecture team are
on hand
– Make use of them
during the sessions!!!
Q & A

7. MongoDB

8. 8
Operational Database

9. 9
Document Data Model
Relational - Tables
{ first_name: ‘Paul’,
surname: ‘Miller’,
city: ‘London’,
location: {
type: “Point”,
coordinates :
[-0.128, 51.507]
},
cars: [
{ model: ‘Bentley’,
year: 1973,
value: 100000, … },
{ model: ‘Rolls Royce’,
year: 1965,
value: 330000, … }
}
}
Document - Collections

10. 10
Document Model
• Agility and flexibility – dynamic schema
– Data models can evolve easily
– Companies can adapt to changes quickly
• Intuitive, natural data representation
– Remove impedance mismatch
– Many types of applications are a good fit
• Reduces the need for joins, disk seeks
– Programming is more simple
– Performance can be delivered at scale

11. 11
Simplify development

12. 12
Simplify development

13. 13
Rich database interaction

14. Query Model

15. 15
Shell
Command-line shell for
interacting directly with
database
Shell and Drivers
Drivers
Drivers for most popular
programming languages and
frameworks
> db.collection.insert({company:“10gen”,
product:“MongoDB”})
>
> db.collection.findOne()
{
“_id” : ObjectId(“5106c1c2fc629bfe52792e86”),
“company” : “10gen”
“product” : “MongoDB”
}
Java
Python
Perl
Ruby
Haskell
JavaScript

16. 16
MongoDB is full featured
Queries
• Find Paul’s cars
• Find everybody in London with a car
built between 1970 and 1980
Geospatial
• Find all of the car owners within 5km of
Trafalgar Sq.
Text Search
• Find all the cars described as having
leather seats
Aggregation
• Calculate the average value of Paul’s
car collection
Map Reduce
• What is the ownership pattern of colors
by geography over time? (is purple
trending up in China?)
{ first_name: ‘Paul’,
surname: ‘Miller’,
city: ‘London’,
location: {
type: “Point”,
coordinates :
[-0.128, 51.507]
},
cars: [
{ model: ‘Bentley’,
year: 1973,
value: 100000, … },
{ model: ‘Rolls Royce’,
year: 1965,
value: 330000, … }
}
}

17. 17
Query Example
Rich Queries
• Find Paul’s cars
• Find everybody in London with a car
built between 1970 and 1980
db.cars.find({
first_name: ‘Paul’
})
db.cars.find({
city: ‘London’,
”cars.year" : {
$gte : 1970,
$lte : 1980
}
})
{ first_name: ‘Paul’,
surname: ‘Miller’,
city: ‘London’,
location: {
type: “Point”,
coordinates :
[-0.128, 51.507]
},
cars: [
{ model: ‘Bentley’,
year: 1973,
value: 100000, … },
{ model: ‘Rolls Royce’,
year: 1965,
value: 330000, … }
}
}

18. 18
Geo Spatial Example
db.cars.find( {
location:
{ $near :
{ $geometry :
{ type: 'Point' ,
coordinates :
[-0.128,
51.507]
}
},
$maxDistance :5000
}
} )
Geospatial
• Find all of the car owners within 5km of
Trafalgar Sq.
{ first_name: ‘Paul’,
surname: ‘Miller’,
city: ‘London’,
location: {
type: “Point”,
coordinates :
[-0.128, 51.507]
},
cars: [
{ model: ‘Bentley’,
year: 1973,
value: 100000, … },
{ model: ‘Rolls Royce’,
year: 1965,
value: 330000, … }
}
}

19. 19
Aggregation Framework Example
db.cars.aggregate( [
{$match : {"first_name" : "Paul"}},
{$project : {"first_name":1,"cars":1}},
{$unwind : "$cars"},
{ $group : {_id:"$first_name",
average : {
$avg : "$cars.value"}}}
])
{ "_id" : "Paul", "average" : 215000 }
Aggregation
• Calculate the average value of Paul’s
car collection
{ first_name: ‘Paul’,
surname: ‘Miller’,
city: ‘London’,
location: {
type: “Point”,
coordinates :
[-0.128, 51.507]
},
cars: [
{ model: ‘Bentley’,
year: 1973,
value: 100000, … },
{ model: ‘Rolls Royce’,
year: 1965,
value: 330000, … }
}
}

20. Scalability

21. 21
Automatic Sharding
• Three types of sharding: hash-based, range-based, tag-
aware
• Increase or decrease capacity as you go
• Automatic balancing

22. 22
Query Routing
• Multiple query optimization models
• Each sharding option appropriate for different apps

23. Availability

24. 24
• High Availability – Ensure application availability during
many types of failures
• Disaster Recovery – Address the RTO and RPO goals
for business continuity
• Maintenance – Perform upgrades and other maintenance
operations with no application downtime
Availability Considerations

25. 25
Replica Sets
• Replica Set – two or more copies
• “Self-healing” shard
• Addresses many concerns:
- High Availability
- Disaster Recovery
- Maintenance

26. 26
Replica Set Benefits
Business Needs Replica Set Benefits
High Availability Automated failover
Disaster Recovery Hot backups offsite
Maintenance Rolling upgrades
Low Latency Locate data near users
Workload Isolation Read from non-primary replicas
Data Privacy Restrict data to physical location
Data Consistency Tunable Consistency

27. Performance

28. 28
Better Data
Locality
Performance
In-Memory
Caching
In-Place
Updates

29. 29
• Document Model
– Simplify development
– Simplify scale out
– Improve performance
• MongoDB
– Rich general purpose database
– Built in High Availability and Failover
– Built in scale out
Summary

30. 30
• Marc Schwering
– Schema design for the CMS application
• Collections
• Design decisions
– Application architecture
• Example technologies
• RESTful interface
• We’ve chosen python for the examples
– Code Examples
Next Week – 7th May