1. MongoDB Operations for
Developers
Chad Tindel
Senior Solution Architect, MongoDB Inc.
@ctindel
2. Agenda
• MongoDB Philosophy
• Data Model
• High Availability through Replication
• Scalability through Sharding
• Deployment Architectures & Operations
2
8. Documents are Rich Data Structures
8
{
first_name: ‘Paul’,
surname: ‘Miller’,
cell: ‘+447557505611’
city: ‘London’,
location: [45.123,47.232],
Profession: [banking, finance, trader],
cars: [
{ model: ‘Bentley’,
year: 1973,
value: 100000, … },
{ model: ‘Rolls Royce’,
year: 1965,
value: 330000, … }
}
}
Fields can contain an array of
sub-documents
Fields
Typed field values
Fields can
contain arrays
9. Document Model Benefits
• Agility and flexibility
9
– Data model supports business change
– Rapidly iterate to meet new requirements
• Intuitive, natural data representation
– Eliminates ORM layer
– Developers are more productive
• Reduces the need for joins, disk seeks
– Programming is more simple
– Performance delivered at scale
11. Why Replication?
• How many have faced node failures?
• How many have been woken up from sleep to do
11
a fail-over(s)?
• How many have experienced issues due to
network latency?
• Different uses for data
– Normal processing
– Simple analytics
12. Replica Sets
12
• Replica Set – two or more copies
• Self-healing shard
• Addresses availability
considerations:
– High Availability
– Disaster Recovery
– Maintenance
• Deployment Flexibility
– Data locality to users
– Workload isolation: operational &
analytics
Application
Driver
Primary
Secondary
Secondary
Repl ication
23. Single Data Center
23
• Automated failover
• Tolerates server failures
• Tolerates rack failures
• Number of replicas
defines failure tolerance
Primary – A Primary – B Primary – C
Secondary – B Secondary – A Secondary – A
Secondary – C Secondary – C Secondary – B
24. Active/Standby Data Center
Primary – A Primary – B Primary – C
Secondary – B Secondary – C Secondary – A
Secondary – A Secondary – B Secondary – C
• Tolerates server and rack failure
• Standby data center
24
Data Center - West
Data Center - East
25. Active/Active Data Center
Primary – A Primary – B Primary – C
Secondary – C Secondary – A Secondary – B
Data Center - West
Secondary – A Secondary – B Secondary – C
Secondary – B Secondary – C Secondary – A
Arbiter – A Arbiter – B Arbiter – C
• Tolerates server, rack, data center failures, network
25
partitions
Data Center - East
Data Center - Central
29. MongoDB Management Service
Management for MongoDB, created by the engineers who
develop the database
• Automation, for single-click
29
provisioning, scaling &
upgrades
• Monitoring, with charts,
dashboards and alerts on 100+
metrics
• Backup and restore, with point-in-
time recovery, support for
sharded clusters
34. For More Information
34
Resource Location
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
Notes de l'éditeur
This is where MongoDB fits into the existing enterprise IT stack
MongoDB is an operational data store used for online data, in the same way that Oracle is an operational data store. It supports applications that ingest, store, manage and even analyze data in real-time. (Compared to Hadoop and data warehouses, which are used for offline, batch analytical workloads.)
MongoDB aims to blend the scalability and performance of K/V stores with the rich query functionality of the RDBMS
With a document model, MongoDB can provide the flexible schema demanded by modern applications, supporting structured, semi structured, unstructured and polymorphic data. Through embedding data using sub-documents and arrays, they eliminate the need for expensive JOINs, enabling simple scaling across multiple nodes.
At the same time, support for powerful query operators, the aggregation framework and rich secondary indexes, users do not trade away the ability to run complex queries against data. MongoDB can do this in real time, across multi-structured data sets
Here we have greatly reduced the relational data model for this application to two tables. In reality no database has two tables. It is much more common to have hundreds or thousands of tables. And as a developer where do you begin when you have a complex data model?? If you’re building an app you’re really thinking about just a hand full of common things, like products, and these can be represented in a document much more easily that a complex relational model where the data is broken up in a way that doesn’t really reflect the way you think about the data or write an application.
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
Secondaries can be used for a variety of applications – failover, hot backup, rolling upgrades, data locality and privacy and workload isolation
Basic explanation
2 or more nodes form the set
Quorum
Initialize -> Election
Primary + data replication from primary to secondary
Primary down/network failure
Automatic election of new primary if majority exists
New primary elected
Replication established from new primary
Down node comes up
Rejoins sets
Recovery and then secondary