MongoDB Architecture

What is MongoDB?

MongoDB is the database for today's applications, enabling you to:

  • Leverage data and technology to maximize competitive advantage

  • Reduce risk for mission-critical deployments

  • Accelerate time-to-value

  • Dramatically lower total cost of ownership

With MongoDB, you can build applications that were never possible with traditional relational databases. Here's how.

  • Fast, Iterative Development. Scope creep and changing business requirements no longer stand between you and successful project delivery. A flexible data model coupled with dynamic schema, and idiomatic drivers, with powerful GUI and command line tools make it fast for developers to build and evolve applications. Automated provisioning and management enable continuous integration and delivery for highly productive operations. Contrast this against static relational schemas and complex operations that have hindered you in the past.

  • Flexible Data Model. MongoDB stores data in flexible, JSON-like documents, making it easy for you to persist and combine data of any structure. The document model maps to the objects in your application code, making data easy to work with, without giving up schema governance controls, data access, complex aggregations, and rich indexing functionality. You can dynamically modify the schema without downtime. You spend less time prepping your data for the database, and more time putting your data to work.

  • Distributed Data Platform. MongoDB can be run within and across geographically distributed data centers and cloud regions, providing new levels of availability and scalability. As your deployments grow in terms of data volume and throughput, MongoDB scales elastically with no downtime, and without changing your application. And as your performance and availability goals evolve, MongoDB lets you adapt flexibly, across data centers, with tunable consistency.

  • Integrated Feature Set. Analytics and data visualization, text and geospatial search, graph processing, event-driven streaming data pipelines, in-memory performance and global replication allow you to deliver a wide variety of real-time applications on one technology, reliably and securely. RDBMS systems require additional, complex technologies demanding separate integration overhead and expense to do this well.

  • Lower TCO. Application development teams are 2x and more productive when they use MongoDB. The fully managed Atlas cloud service means operations team are as well. MongoDB runs on commodity hardware, dramatically lowering costs. MongoDB offers on-demand, pay-as-you-go pricing and affordable annual subscriptions, including 24x7x365 global support. Your applications can be one tenth the cost to deliver compared to using a relational database.

  • Long-Term Commitment. MongoDB Inc and the MongoDB ecosystem stand behind the world's fastest-growing database. 30M+ downloads, 4,300+ customers including more than 50% of the Fortune 100 and over 1,000 partners. You can be sure your investment is protected.

The Nexus Architecture

MongoDB’s design philosophy is focused on combining the critical capabilities of relational databases with the innovations of NoSQL technologies. Our vision is to leverage the work that Oracle and others have done over the last 40 years to make relational databases what they are today. Rather than discard decades of proven database maturity, MongoDB is picking up where they left off by combining key relational database capabilities with the work that Internet pioneers have done to address the requirements of modern applications.

Nexus Architecture

Relational databases have reliably served applications for many years, and offer features that remain critical today as developers build the next generation of applications:

  • Expressive query language & secondary Indexes. Users should be able to access and manipulate their data in sophisticated ways to support both operational and analytical applications. Indexes play a critical role in providing efficient access to data, supported natively by the database rather than maintained in application code.

  • Strong consistency. Applications should be able to immediately read what has been written to the database. It is much more complex to build applications around an eventually consistent model, imposing significant work on the developer, even for the most sophisticated engineering teams.

  • Enterprise Management and Integrations. Databases are just one piece of application infrastructure, and need to fit seamlessly into the enterprise IT stack. Organizations need a database that can be secured, monitored, automated, and integrated with their existing technology infrastructure, processes, and staff, including operations teams, DBAs, and data analysts.

However, modern applications impose requirements not addressed by relational databases, and this has driven the development of NoSQL databases which offer:

  • Flexible Data Model. NoSQL databases emerged to address the requirements for the data we see dominating modern applications. Whether document, graph, key-value, or wide-column, all of them offer a flexible data model, making it easy to store and combine data of any structure and allow dynamic modification of the schema without downtime or performance impact.

  • Scalability and Performance. NoSQL databases were all built with a focus on scalability, so they all include some form of sharding or partitioning. This allows the database to scale out on commodity hardware deployed on-premises or in the cloud, enabling almost unlimited growth with higher throughput and lower latency than relational databases.

  • Always-On Global Deployments. NoSQL databases are designed for highly available systems that provide a consistent, high quality experience for users all over the world. They are designed to run across many nodes, including replication to automatically synchronize data across servers, racks, and data centers.

While offering these innovations, NoSQL systems have sacrificed the critical capabilities that people have come to expect and rely upon from relational databases. MongoDB offers a different approach. With its Nexus Architecture, MongoDB is the only database that harnesses the innovations of NoSQL while maintaining the foundation of relational databases.

MongoDB Data Model

Back to Table of Contents

This section covers 3 topics: Multimodel Architecture, Data as Documents, Dynamic Schemas with Data Governance

MongoDB Multimodel Architecture

MongoDB uniquely allows users to mix and match multiple storage engines within a single deployment. This flexibility provides a more simple and reliable approach to meeting diverse application needs for data. Traditionally, multiple database technologies would need to be managed to meet these needs, with complex, custom integration code to move data between the technologies, and to ensure consistent, secure access. With MongoDB’s flexible storage architecture, the database automatically manages the movement of data between storage engine technologies using native replication.

  • MongoDB’s flexible document data model presents a superset of other database models. It allows data to be represented as simple key-value pairs and flat, table-like structures, through to rich documents and objects with deeply nested arrays and sub-documents.

  • With an expressive query language, documents can be queried in many ways – from simple lookups to creating sophisticated processing pipelines for data analytics and transformations, through to faceted search, JOINs and graph traversals.

  • With a flexible storage architecture, application owners can deploy storage engines optimized for different workload and operational requirements.

MongoDB’s multimodel design significantly reduces developer and operational complexity when compared to running multiple distinct database technologies to meet different applications needs. Users can leverage the same MongoDB query language, data model, scaling, security, and operational tooling across different parts of their application, with each powered by the optimal storage engine.

Data as Documents

MongoDB stores data in a binary representation called BSON (Binary JSON). The BSON encoding extends the popular JSON (JavaScript Object Notation) representation to include additional types such as int, long, date, floating point, and decimal128. BSON documents contain one or more fields, and each field contains a value of a specific data type, including arrays, binary data and sub-documents. MongoDB BSON documents are closely aligned to the structure of objects in the programming language. This makes it simpler and faster for developers to model how data in the application will map to data stored in the database.

MongoDB documents tend to have all data for a given record in a single document, whereas in a relational database information for a given record is usually spread across many tables.

For example, consider the data model for a blogging application. In a relational database, the data model would comprise multiple tables such as Categories, Tags, Users, Comments and Articles. In MongoDB the data could be modeled as two collections, one for users, and the other for articles. In each blog document there might be multiple comments, multiple tags, and multiple categories, each expressed as an embedded array.

Data as documents: simpler for developers, faster for users.

Single Document Example

As a result of the document model, data in MongoDB is more localized, which dramatically reduces the need to JOIN separate tables. The result is dramatically higher performance and scalability across commodity hardware as a single read to the database can retrieve the entire document.

Unlike many NoSQL databases, users don’t need to give up JOINs entirely. For additional flexibility, MongoDB provides the ability to perform equi and non-equi JOINs that combine data from multiple collections, typically when executing analytical queries against live, operational data.

MongoDB Dynamic Schema with Data Governance Control

MongoDB documents can vary in structure. For example, all documents that describe customers might contain the customer id and the last date they purchased products or services from us, but only some of these documents might contain the user’s social media handle, or location data from our mobile app.

Fields can vary from document to document; there is no need to declare the structure of documents to the system – documents are self-describing. If a new field needs to be added to a document then the field can be created without affecting all other documents in the system, without updating a central system catalog, and without taking the system offline.

MongoDB enables developers to design and evolve the schema through an iterative and agile approach, while enforcing data governance.

Developers can start writing code and persist the objects as they are created. And when developers add more features, MongoDB continues to store the updated objects without the need for performing costly ALTER_TABLE operations, or worse - having to re-design the schema from scratch.

While MongoDB’s flexible schema is a powerful feature for many users, there are situations where strict guarantees on the schema’s data structure and content are required. Unlike NoSQL databases that push enforcement of these controls back into application code, MongoDB provides schema validation within the database via syntax derived from the IETF JSON Schema standard.

Using schema validation, DevOps and DBA teams can define a prescribed document structure for each collection, which can reject any documents that do not conform to it. Administrators have the flexibility to tune schema validation according to use case – for example, if a document fails to comply with the defined structure, it can be either be rejected, or still written to the collection while logging a warning message. Structure can be imposed on just a subset of fields – for example requiring a valid customer a name and address, while others fields can be freeform, such as social media handle and cellphone number. And of course, validation can be turned off entirely, allowing complete schema flexibility, which is especially useful during the development phase of the application.

Using schema validation, DBAs can apply data governance standards to their schema, while developers maintain the benefits of a flexible document model.

How does the MongoDB data model stack up to relational databases and key-value stores? Take a look at the chart below:

 MongoDBRelationalKey-value
Rich Data Model YesNoNo
Dynamic Schema YesNoYes
Schema Validation YesYesNo
Typed Data YesYesNo
Data Locality YesNoYes
Field Updates YesYesNo
Easy for Programmers YesNoNot when modeling complex data structures
MongoDB Compass Query Builder

MongoDB Query Model and Data Visualization

Back to Table of Contents

This section covers 6 topics: Idiomatic Drivers, Tools, Query Types, Data Visualization, Indexing, and Change Streams

Idiomatic Drivers

MongoDB provides native drivers for all popular programming languages and frameworks to make development natural. Supported drivers include Java, Javascript, .NET, Python, Perl, PHP, Scala and others, in addition to 30+ community-developed drivers. MongoDB drivers are designed to be idiomatic for the given language.

With the intuitive document data model, dynamic schema and idiomatic drivers, you can build applications and get to market faster with MongoDB.

Tools to Interact with the Database

MongoDB offers developers and administrators a range of tools for interacting with the database, independent of the drivers.

The mongo shell is a rich, interactive JavaScript shell that is included with all MongoDB distributions. Additionally MongoDB Compass is a sophisticated and intuitive GUI for MongoDB. Offering rich schema exploration and management, Compass allows DBAs to modify documents, create data validation rules, and efficiently optimize query performance by visualizing explain plans and index usage. Sophisticated queries can be built and executed by simply selecting document elements from the user interface, with the results viewed both as a set of JSON documents or in a table view. All of these tasks can be accomplished from a point and click interface, and all with zero knowledge of MongoDB's query language.

Query Types

Unlike NoSQL databases, MongoDB is not limited to simple Key-Value operations. Developers can build rich applications using complex queries, aggregations and secondary indexes that unlock the value in multi-structured, polymorphic data.

A key element of this flexibility is MongoDB's support for many types of queries. A query may return a document, a subset of specific fields within the document or complex aggregations and transformation of many documents:

  • Key-value queries return results based on any field in the document, often the primary key.

  • Range queries return results based on values defined as inequalities (e.g. greater than, less than or equal to, between).

  • Geospatial queries return results based on proximity criteria, intersection and inclusion as specified by a point, line, circle or polygon.

  • Search queries return results in relevance order and in faceted groups, based on text arguments using Boolean operators (e.g., `AND`, `OR`, `NOT`), and through bucketing, grouping and counting of query results. With support for collations, data comparison and sorting order can be defined for over 100 different languages and locales.

  • Aggregation Pipeline queries return aggregations and transformations of documents and values returned by the query (e.g., count, min, max, average, standard deviation, similar to a SQL GROUP BY statement).

  • JOINs and graph traversals. Through the $lookup stage of the aggregation pipeline, documents from separate collections can be combined through JOIN operations.$graphLookup brings native graph processing within MongoDB, enabling efficient traversals across trees, graphs and hierarchical data to uncover patterns and surface previously unidentified connections.

Additionally the MongoDB Connector for Apache Spark exposes Spark’s Scala, Java, Python, and R libraries. MongoDB data is materialized as DataFrames and Datasets for analysis through machine learning, graph, streaming, and SQL APIs.

Data Visualization

Using the MongoDB Connector for BI, included with MongoDB Enterprise Advanced, modern application data can be easily analyzed with industry-standard SQL-based BI and analytics platforms. Business analysts and data scientists can seamlessly analyze semi and unstructured data managed in MongoDB, alongside traditional data in their SQL databases using the same BI tools deployed within millions of enterprises.

MongoDB Connector for BI

Indexing

Indexes are a crucial mechanism for optimizing system performance and scalability while providing flexible access to your data. MongoDB includes support for many types of secondary indexes that can be declared on any field in the document, including fields within arrays:

  • You can define compound, unique, array, partial, TTL, geospatial, sparse, hash and text indexes to optimize for multiple query patterns, multi-structured data types and constraints.

  • Index intersection enables MongoDB to use more than one index to optimize an ad-hoc query at run-time.

Creating Reactive Data Pipelines with Change Streams

Change streams enable developers to build reactive, real-time, web, mobile, and IoT apps that can view, filter, and act on data changes as they occur in the database. Change streams enable seamless data movement across distributed database and application estates, making it simple to stream data changes and trigger actions wherever they are needed, using a fully reactive programming style. Use cases enabled by MongoDB change streams include:

  • Powering trading applications that need to be updated in real time as stock prices rise and fall.

  • Refreshing scoreboards in multiplayer games.

  • Updating dashboards, analytics systems, and search engines as operational data changes.

  • Creating powerful IoT data pipelines that can react whenever the state of physical objects change.

  • Synchronizing updates across serverless and microservices architectures by triggering an API call when a document is inserted or modified.

Change streams offer a number of key properties:

  • Flexible- users can register to receive just the individual deltas from changes to a document, or receive a copy of the full document.

  • Consistent- change streams ensure a total ordering of notifications across shards, guaranteeing the order of changes will be preserved.

  • Secure- users are able to create change streams only on collections to which they have been granted read access.

  • Reliable- notifications are only sent on majority committed write operations and are durable when nodes or the network fails.

  • Resumable– when nodes recover after a failure, change streams can be automatically resumed.

  • Familiar– the API syntax takes advantage of the established MongoDB drivers and query language.

  • Highly concurrent – up to 1,000 change streams can be opened against each MongoDB instance with minimal performance degradation.

How does the MongoDB query and indexing model stack up to relational databases and key-value stores? Take a look at the chart below:

 MongoDBRelationalKey-value
Key-value Queries YesYesYes
Secondary Indexes YesYesNo
Index Intersection YesYesNo
Range Queries YesYesNo
Geospatial YesExpensive Add-onNo
Faceted Search YesNoNo
Aggregation and Transformation YesYesNo
Idiomatic Drivers YesNoNo
Equi and Nonequi JOINs ($Lookup) YesYesNo
Graph Processing ($graphLookup) YesNoNo
Change Streams YesRarelyRarely

To learn more about the differences in data models, download our Relational Database to MongoDB Migration Guide.

MongoDB Data Management

Back to Table of Contents

Auto-sharding for linear scalability

MongoDB provides horizontal scale-out for databases on low cost, commodity hardware using a technique called sharding, which is transparent to applications. Sharding distributes data across multiple physical partitions called shards. Sharding allows MongoDB deployments to address the hardware limitations of a single server, such as bottlenecks in RAM or disk I/O, without adding complexity to the application. MongoDB automatically balances the data in the cluster as the data grows or the size of the cluster increases or decreases.

Sharding is transparent to applications; whether there is one or one hundred shards, the application code for querying MongoDB is the same.

Horizontal Scalability Illustration

Unlike relational databases, sharding is automatic and built into the database. Developers don't face the complexity of building sharding logic into their application code, which then needs to be updated as shards are migrated. Operations teams don't need to deploy additional clustering software to manage process and data distribution.

Unlike other distributed databases, multiple sharding policies are available that enable developers and administrators to distribute data across a cluster according to query patterns or data locality. As a result, MongoDB delivers much higher scalability across a diverse set of workloads:

  • Range Sharding. Documents are partitioned across shards according to the shard key value. Documents with shard key values close to one another are likely to be co-located on the same shard. This approach is well suited for applications that need to optimize range based queries.

  • Hash Sharding. Documents are distributed according to an MD5 hash of the shard key value. This approach guarantees a uniform distribution of writes across shards, but is less optimal for range-based queries.

  • Zone Sharding. Provides the ability for DBAs and operations teams to define specific rules governing data placement in a sharded cluster. Zones accommodate a range of deployment scenarios – for example locating data by geographic region, by hardware configuration for tiered storage architectures, or by application feature. Administrators can continuously refine data placement rules by modifying shard key ranges, and MongoDB will automatically migrate the data to its new zone.

How do the MongoDB scaling capabilities stack up to relational databases and key-value stores? Take a look at the chart below:

 MongoDBRelationalKey-value
Scale-out Commodity Hardware YesNoYes
Automatic Sharding YesNoYes
Shard by Hash YesManualYes
Shard by Range YesManualNo
Shard by Zone YesManualNo
Automatic Data Rebalancing YesManualLimited

MongoDB scales like crazy. Whether you are sharding to scale data volume, performance or cross-data center operations, you can do it with MongoDB.

Pluggable storage architecture for application flexibility

With MongoDB, organizations can address diverse application needs, hardware resources, and deployment designs with a single database technology. Through the use of a pluggable storage architecture, MongoDB can be extended with new capabilities, and configured for optimal use of specific hardware architectures. This approach significantly reduces developer and operational complexity compared to running multiple databases to power applications with unique requirements. Users can leverage the same MongoDB query language, data model, scaling, security and operational tooling across different applications, each powered by different pluggable MongoDB storage engines.

Application Architecture Illustration

MongoDB ships with four supported storage engines, all of which can coexist within a single MongoDB replica set. This makes it easy to evaluate and migrate between them, and to optimize for specific application requirements – for example combining the in-memory engine for ultra-low latency operations with a disk-based engine for persistence. The supported storage engines include:

  • The default WiredTiger storage engine. For many applications, WiredTiger's granular concurrency control and native compression will provide the best all round performance and storage efficiency for the broadest range of applications.

  • The Encrypted storage engine protecting highly sensitive data, without the performance or management overhead of separate filesystem encryption. (Requires MongoDB Enterprise Advanced)

  • The In-Memory storage engine delivering the extreme performance coupled with real time analytics for the most demanding, latency-sensitive applications. (Requires MongoDB Enterprise Advanced)

  • The MMAPv1 engine, an improved version of the original storage engine used in pre-3.x MongoDB releases.

End-to-End Compression

The WiredTiger and Encrypted storage engines support native compression, reducing physical storage footprint by as much as 80%. In addition to reduced storage space, compression enables much higher storage I/O scalability as fewer bits are read from disk.

As a distributed database, MongoDB relies on efficient network transport during query routing and inter-node replication. In addition to storage, MongoDB also offers compression of the wire protocol from clients to the database, and of intra-cluster traffic. Network traffic can be compressed by up to 80%, bringing major performance gains to busy network environments and reducing connectivity costs, especially in public cloud environments, or when connecting remote assets such as IoT devices and gateways.

MongoDB Consistency & Availability

Back to Table of Contents

This section covers 4 topics: Transaction Model, Replica Sets, In-Memory Performance, and Security.

Transaction model

MongoDB provides ACID properties at the document level. One or more fields may be written in a single operation, including updates to multiple sub-documents and elements of an array. The ACID guarantees provided by MongoDB ensure complete isolation as a document is updated; any errors cause the operation to roll back so that clients receive a consistent view of the document.

Developers can use MongoDB's Write Concerns to configure operations to commit to the application only after they have been flushed to the journal file on disk. This is the same model used by many traditional relational databases to provide durability guarantees. As a distributed system, MongoDB presents additional flexibility that helps users to achieve their desired availability SLAs. Each query can specify the appropriate write concern, such as writing to at least two replicas in one data center and one replica in a second data center.

For always-on write availability, MongoDB drivers automatically retry write operations in the event of transient network failures or a primary election, while the MongoDB server enforces exactly-once processing semantics. Retryable writes reduces the need for developers to implement custom, client-side code, instead having the database handle common exceptions for them.

Replica sets

MongoDB maintains multiple copies of data called replica sets using native replication. A replica set is a fully self-healing shard that helps prevent database downtime. Replica failover is fully automated, eliminating the need for administrators to intervene manually.

The number of replicas in a MongoDB replica set is configurable: a larger number of replicas provide increased data availability and protection against database downtime (e.g., in case of multiple machine failures, rack failures, data center failures, or network partitions). Optionally, operations can be configured to write to multiple replicas before returning to the application, thereby providing functionality that is similar to synchronous replication.

Replica Sets Illustration

MongoDB replica sets deliver fault tolerance and disaster recovery. Multi-data center awareness enables global data distribution and separation between operational and analytical workloads. Replica sets also provide operational flexibility by providing a way to upgrade hardware and software without requiring the database to go offline.

In-memory performance with on-disk capacity

With the In-Memory storage engine, MongoDB users can realize the performance advantages of in-memory computing for operational and real-time analytics workloads. The In-Memory storage engine delivers the extreme throughput and predictable latency demanded by the most performance-intensive applications in AdTech, finance, telecoms, IoT, eCommerce and more, eliminating the need for separate caching layers.

MongoDB replica sets allow for hybrid in-memory and on-disk database deployments. Data managed by the In-Memory engine can be processed and analyzed in real time, before being automatically replicated to MongoDB instances configured with one of the persistent disk-based storage engines. Lengthy ETL cycles typical when moving data between different databases are avoided, and users no longer have to trade away the scalable capacity or durability guarantees offered by disk storage.

To learn more, download our detailed Architecture Guide.

Security

The frequency and severity of data breaches continues to escalate. Industry analysts predict cybercrime will cost the global economy $6 trillion annually by 2021. Organizations face an onslaught of new threat classes and threat actors with phishing, ransomware and intellectual property theft growing more than 50% year on year, and key infrastructure subject to increased disruption. With databases storing an organization’s most important information assets, securing them is top of mind for administrators.

MongoDB Enterprise Advanced features extensive capabilities to defend, detect and control access to data.

  • Authentication. Simplifying access control to the database, MongoDB offers integration with external security mechanisms including LDAP, Windows Active Directory, Kerberos and x.509 PKI certificates.

  • Authorization. User-defined roles enable administrators to configure granular permissions for a user or an application based on the privileges they need to do their job. These can be defined in MongoDB, or centrally within an LDAP server. Additionally, administrators can define views that expose only a subset of data from an underlying collection, i.e. a view that filters or masks specific fields, such as Personally Identifiable Information (PII) from customer data or health records.

  • Auditing. For regulatory compliance, security administrators can use MongoDB's native audit log to track access and operations performed against the database.

  • Encryption. MongoDB data can be encrypted on the network, on disk and in backups. With the Encrypted storage engine, protection of data at-rest is an integral feature within the database. By natively encrypting database files on disk, administrators eliminate both the management and performance overhead of external encryption mechanisms. Only those staff who have the appropriate database authorization credentials can access the encrypted data, providing additional levels of defence.

To learn more, download our MongoDB Security Reference Architecture.

Running MongoDB

Back to Table of Contents

Organizations want the flexibility to run applications anywhere. MongoDB provides complete platform independence: on-premises, hybrid deployments, or as a fully managed service in the cloud, with the freedom to move between each platform as business requirements change.

MongoDB Atlas: Database as a Service For MongoDB

Back to Table of Contents

MongoDB Atlas is a cloud database service that makes it easy to deploy, operate, and scale MongoDB in the cloud by automating time-consuming administration tasks such as database setup, security implementation, scaling, patching, and more.

MongoDB Atlas is available on-demand through a pay-as-you-go model and billed on an hourly basis.

It’s easy to get started – use a simple GUI to select the public cloud provider, region, instance size, and features you need. MongoDB Atlas provides:

  • Security features to protect your data, with fine-grained access control and end-to-end encryption

  • Built in replication for always-on availability. Cross-region replication within a public cloud can be enabled to help tolerate the failure of an entire cloud region

  • Fully managed, continuous and consistent backups with point in time recovery to protect against data corruption, and the ability to query backups in-place without full restores

  • Fine-grained monitoring and customizable alerts for comprehensive performance visibility

  • One-click scale up, out, or down on demand. MongoDB Atlas can provision additional storage capacity as needed without manual intervention

  • Automated patching and single-click upgrades for new major versions of the database, enabling you to take advantage of the latest and greatest MongoDB features

  • Live migration to move your self-managed MongoDB clusters into the Atlas service with minimal downtime

MongoDB Atlas can be used for everything from a quick Proof of Concept, to test/QA environments, to powering production applications. The user experience across MongoDB Atlas, Cloud Manager, and Ops Manager is consistent, ensuring that disruption is minimal if you decide to manage MongoDB yourself and migrate to your own infrastructure.

Built and run by the same team that engineers the database, MongoDB Atlas is the best way to run MongoDB in the cloud. Learn more or deploy a free cluster now.

Managing MongoDB On Your Own Infrastructure

Ops Manager is the simplest way to run MongoDB on your own infrastructure, making it easy for operations teams to deploy, monitor, backup and scale MongoDB. Many of the capabilities of Ops Manager are also available in MongoDB Cloud Manager, a tool hosted by MongoDB in the cloud. Ops Manager and Cloud Manager provides an integrated suite of applications that manage the complete lifecycle of the database:

  • Automated deployment and management with a single click and zero-downtime upgrades

  • Proactive monitoring providing visibility into the performance of MongoDB, history, and automated alerting on 100+ system metrics

  • Disaster recovery with continuous, incremental backup and point-in-time recovery, including the restoration of complete running clusters from your backup files.

Each of these is explained in more detail below.

Deployment and upgrades

Ops Manager helps operations teams deploy MongoDB through a powerful self-service portal or by invoking the Ops Manager RESTful API from existing enterprise tools. The deployment can be anything from a single instance to a replica set or a sharded cluster, running in the public cloud or in your private data center. Ops Manager enables fast deployment on any hosting topology.

Ops Manager Deployment Illustration

In addition to initial deployment, Ops Manager enables capacity to be dynamically scaled by adding shards and replica set members to running systems. Other maintenance tasks such upgrades, building indexes across replica sets or resizing the oplog can all be made with a few clicks and zero downtime.

Monitoring

Ops Manager gives developers, administrators and operations teams visibility into the MongoDB service. Featuring charts, custom dashboards, and automated alerting, Ops Manager tracks 100+ key database and systems health metrics including operations counters, memory and CPU utilization, replication status, open connections, queues and any node status.

The metrics are securely reported to Ops Manager where they are processed, aggregated, alerted and visualized in a browser, letting administrators easily determine the health of MongoDB in real-time. Historic performance can be reviewed in order to create operational baselines and to support capacity planning. The Performance Advisor continuously highlights slow-running queries and provides intelligent index recommendations to improve performance. The Data Explorer allows operations teams to examine the database’s schema by running queries to review document structure, viewing collection metadata, and inspecting index usage statistics, directly within the Ops Manager UI.

Integration with existing monitoring tools is also straightforward via the Ops Manager and Cloud Manager RESTful API, and with packaged integrations to leading Application Performance Management (APM) platforms such as New Relic. This integration allows MongoDB status to be consolidated and monitored alongside the rest of your application infrastructure, all from a single pane of glass.

Ops Manager provides real time & historic visibility into MongoDB with integration into operational tools

Ops Manager Monitoring Illustration

Alerts enable proactive management of MongoDB

Disaster recovery

A backup and recovery strategy is necessary to protect your mission critical data against catastrophic failure, such as a fire or flood in your data center, or human error, such as unintentional corruption due to mistakes in application code, or accidental deletion of data. With a backup and recovery strategy in place, administrators can restore business operations with minimal data loss and the organization can meet regulatory and compliance requirements.

Ops Manager and Cloud Manager provide continuous incremental backup, point-in-time recovery of replica sets, and consistent snapshots of sharded clusters. Ops Manager creates snapshots of MongoDB data and retains multiple copies based on a user-defined retention policy. You can restore to precisely the moment you need, quickly and safely. Automation-driven restores allows fully a configured cluster to be re-deployed directly from the database snapshots in a just few clicks.

Queryable Backups allow partial restores of selected data, and the ability to query a backup file in-place, without having to restore it. Now users can query the historical state of the database to track data and schema modifications – often a demand of regulatory reporting. Directly querying backups also enables administrators to identify the best point in time to restore a system by comparing data from multiple snapshots, thereby improving both RTO and RPO.

How do the MongoDB operational capabilities stack up to relational databases and key-value stores? Take a look at the chart below:

 MongoDBRelationalKey-value
Self Healing Recovery with Automatic Failover YesOften Requires Additional Clustering SoftwareNo: Manual Failover Often Recommended
Separate Caching Layer Required NoOftenOften
Data Center Awareness YesExpensive Add-onNo
Automatic Provisioning YesYesNo
Continuous Backup & Point in Time Recovery YesYesNo
Advanced Security YesYesNo
API Integration with Systems Management Frameworks YesYesNo

Integrating MongoDB with external monitoring solutions

The Ops Manager API provides programmatic access to key monitoring data and access to Ops Manager features by external management tools.

In addition to Ops Manager, MongoDB Enterprise can report system information to SNMP traps, supporting centralized data collection and aggregation via external monitoring solutions.

To learn more about operational best practices, download our Operations Guide.

Cost savings

Back to Table of Contents

MongoDB can be 1/10th the cost to build and run, compared to a relational database. The cost advantage is driven by:

  • MongoDB's increased ease of use and developer flexibility, which reduces the cost of developing and evolving an application over its lifecycle

  • MongoDB's ability to scale on commodity server hardware and storage, and in the cloud

  • MongoDB's substantially lower prices for on-demand cloud services and commercial subscription packages with 24x7 support

Furthermore, MongoDB's technical and cost-related benefits translate to topline advantages as well, such as faster time-to-market and time-to-scale.

To learn more, download our TCO comparison of Oracle and MongoDB

Want to go deeper into MongoDB's technology? Then download our detailed Architecture Guide.

Learn More

A Total Cost of Ownership Comparison of MongoDB & Oracle

Read a White Paper

Download the detailed MongoDB Architecture guide.