MongoDB Operations for 
Developers 
Chad Tindel 
Senior Solution Architect, MongoDB Inc. 
@ctindel
Agenda 
• MongoDB Philosophy 
• Data Model 
• High Availability through Replication 
• Scalability through Sharding 
• Deployment Architectures & Operations 
2
MongoDB Philosophy
MongoDB and Enterprise IT Stack 
4 
Applications 
CRM, ERP, Collaboration, Mobile, BI 
Data Management 
Online Data Offline Data 
Hadoop EDW 
Management & Monitoring 
Security & Auditing 
RDBMS 
RDBMS 
Infrastructure 
OS & Virtualization, Compute, Storage, Network
Operational Database Landscape 
5
Data Model
Document Data Model 
Relational MongoDB 
7 
{ 
first_name: ‘Paul’, 
surname: ‘Miller’, 
city: ‘London’, 
location: 
[45.123,47.232], 
cars: [ 
{ model: ‘Bentley’, 
year: 1973, 
value: 100000, … }, 
{ model: ‘Rolls Royce’, 
year: 1965, 
value: 330000, … } 
} 
}
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
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
High Availability Through 
Replication
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
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
Replica Set – Creation
Replica Set – Initialize
Replica Set – Failure
Replica Set – Failover
Replica Set – Recovery
Replica Set – Recovered
Scalability Through Sharding
Working Set Exceeds Physical 
Memory 
20
MongoDB Architecture 
21
Deployment Architectures & 
Operations
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
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
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
Read Global/Write Local 
26 
Primary:NYC 
Primary:LON 
Secondary:NYC 
Primary:SYD 
Secondary:LON 
Secondary:NYC 
Secondary:SYD 
Secondary:LON 
Secondary:SYD
Global Data Distribution 
27 
Real-Time 
Real-Time Real-Time 
Real-Time 
Real-Time 
Real-Time 
Real-Time 
Primary 
Secondary 
Secondary 
Secondary 
Secondary 
Secondary 
Secondary 
Secondary
MongoDB Management Service
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
Security
Defense in Depth Security Architecture 
31
Enterprise-Grade Security 
32 
Business Needs Security Features 
Authentication 
In Database 
LDAP* 
Kerberos* 
x.509 Certificates* 
Authorization 
Built-in Roles 
User-Defined Roles 
Field-Level Redaction 
Auditing 
Admin Operations* 
Queries (via Partner Solutions) 
Encryption 
Network: SSL (with FIPS 140-2)* 
Disk: Partner Solutions 
*Included with MongoDB Enterprise
Resources for Ops
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
Ops Jumpstart: MongoDB Administration 101

Ops Jumpstart: MongoDB Administration 101

  • 1.
    MongoDB Operations for Developers Chad Tindel Senior Solution Architect, MongoDB Inc. @ctindel
  • 2.
    Agenda • MongoDBPhilosophy • Data Model • High Availability through Replication • Scalability through Sharding • Deployment Architectures & Operations 2
  • 3.
  • 4.
    MongoDB and EnterpriseIT Stack 4 Applications CRM, ERP, Collaboration, Mobile, BI Data Management Online Data Offline Data Hadoop EDW Management & Monitoring Security & Auditing RDBMS RDBMS Infrastructure OS & Virtualization, Compute, Storage, Network
  • 5.
  • 6.
  • 7.
    Document Data Model Relational MongoDB 7 { first_name: ‘Paul’, surname: ‘Miller’, city: ‘London’, location: [45.123,47.232], cars: [ { model: ‘Bentley’, year: 1973, value: 100000, … }, { model: ‘Rolls Royce’, year: 1965, value: 330000, … } } }
  • 8.
    Documents are RichData 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
  • 10.
  • 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
  • 13.
  • 14.
    Replica Set –Initialize
  • 15.
  • 16.
  • 17.
  • 18.
    Replica Set –Recovered
  • 19.
  • 20.
    Working Set ExceedsPhysical Memory 20
  • 21.
  • 22.
  • 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
  • 26.
    Read Global/Write Local 26 Primary:NYC Primary:LON Secondary:NYC Primary:SYD Secondary:LON Secondary:NYC Secondary:SYD Secondary:LON Secondary:SYD
  • 27.
    Global Data Distribution 27 Real-Time Real-Time Real-Time Real-Time Real-Time Real-Time Real-Time Primary Secondary Secondary Secondary Secondary Secondary Secondary Secondary
  • 28.
  • 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
  • 30.
  • 31.
    Defense in DepthSecurity Architecture 31
  • 32.
    Enterprise-Grade Security 32 Business Needs Security Features Authentication In Database LDAP* Kerberos* x.509 Certificates* Authorization Built-in Roles User-Defined Roles Field-Level Redaction Auditing Admin Operations* Queries (via Partner Solutions) Encryption Network: SSL (with FIPS 140-2)* Disk: Partner Solutions *Included with MongoDB Enterprise
  • 33.
  • 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

Editor's Notes

  • #5 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.)
  • #6 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
  • #8 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.
  • #13 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
  • #14 Basic explanation 2 or more nodes form the set Quorum
  • #15 Initialize -> Election Primary + data replication from primary to secondary
  • #16 Primary down/network failure Automatic election of new primary if majority exists
  • #17 New primary elected Replication established from new primary
  • #18 Down node comes up Rejoins sets Recovery and then secondary
  • #25 Replicas in DC East configured as secondary-only.