MongoDB is the database for today's applications, enabling you to:
With MongoDB, you can build applications that were never possible with traditional relational databases. Here's how.
Organizations are increasingly considering alternatives to legacy relational infrastructure, driven by challenges presented in building modern applications. Consider:
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.
Relational databases have reliably served applications for many years, and offer features that remain critical today as developers build the next generation of applications :
However, modern applications impose requirements not addressed by relational databases, and this has driven the development of NoSQL databases which offer:
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.
This section covers 2 topics: Data as Documents and Dynamic Schemas.
MongoDB stores data as documents in a binary representation called BSON (Binary JSON). Documents that share a similar structure are typically organized as collections. You can think of collections as being analogous to a table in a relational database: documents are similar to rows, and fields are similar to columns.
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.”
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.
In addition, MongoDB documents are more 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 can vary in structure. For example, all documents that describe users might contain the user id and the last date they logged into the system, but only some of these documents might contain the user's identity for one or more third-party applications.
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.”
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.
How does the MongoDB data model stack up to relational databases and key-value stores? Take a look at the chart below:
|Rich Data Model||Yes||No||No|
|Easy for Programmers||Yes||No||Not when modeling complex data structures|
This section covers 3 topics: Idiomatic Drivers, Query Types, and Indexing.
“With the intuitive document data model, dynamic schema and idiomatic drivers, you can build applications and get to market faster with MongoDB.”
MongoDB supports many types of queries for highly scalable operational and analytic applications. A query may return a document or a subset of specific fields within the document:
“Unlike NoSQL databases, MongoDB is not limited to simple key-value operations. You can build rich applications using complex queries and secondary indexes that unlock the value in structured, semi-structured, and unstructured data.
Native analytics, text search and geospatial features with tunable consistency and in-memory performance allow you to deliver a wide variety of real-time applications on one technology, reliably and securely.”
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:
How does the MongoDB query and indexing model stack up to relational databases and key-value stores? Take a look at the chart below:
|Text Search||Yes||Expensive Add-on||No|
To learn more about the differences in data models, download our Relational Database to MongoDB Migration Guide.
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.”
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 NoSQL databases, you have multiple sharding policies available – hash-based, range-based and location-based – that enable you to distribute your data across a cluster according to query patterns or data locality. As a result, you get much higher scalability across a diverse set of workloads:
How do the MongoDB scaling capabilities stack up to relational databases and key-value stores? Take a look at the chart below:
|Scale-out Commodity Hardware||Yes||No||Yes|
|Shard by Hash||Yes||Manual||Yes|
|Shard by Range||Yes||Manual||No|
|Shard by Location||Yes||Manual||No|
|Automatic Data Rebalancing||Yes||Manual||Limited|
MongoDB scales like crazy. Whether you are sharding to scale data volume, performance or cross-data center operations, you can do it with MongoDB.
MongoDB embraces two key trends in modern IT:
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.
MongoDB 3.0 ships with two supported storage engines: MMAPv1 (Memory Mapped Version 1) engine – an improved version of the engine used in prior MongoDB releases; and the new WiredTiger storage engine bringing higher concurrency and compression. Both engines can coexist within the same MongoDB replica set, making it simple to evaluate and migrate between them. an experimental in-memory storage engine is also available for evaluation. Other engines are under development by MongoDB and members of the MongoDB ecosystem.
MongoDB supports native compression when configured with the WiredTiger storage engine, 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. Administrators have the flexibility to configure specific compression algorithms for collections, indexes and the journal.
This section covers 4 topics: Transaction Model, Replica Sets, In-Memory Performance, and Security.
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.
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.
“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.”
MongoDB makes extensive use of RAM to speed up database operations. Reading data from memory is approximately 100,000 times faster than reading data from disk. In MongoDB, all data is read and manipulated through memory-mapped files. Data that is not accessed is not loaded into RAM. Because MongoDB provides in-memory performance, for most applications there is no need for a separate caching layer to scale your database.
To learn more, download our detailed Architecture Guide.
“Data security and privacy is a critical concern in today's connected world. Data analyzed from new sources such as social media, logs, mobile devices and sensor networks has become as sensitive as traditional transaction data generated by back-office systems.
MongoDB Enterprise Advanced features extensive capabilities to defend, detect and control access to data.”
To learn more, download our MongoDB Security Reference Architecture.
This section covers 6 topics: Ops Manager & Cloud Manager, Deployments and Upgrades, Monitoring, Disaster Recovery, Integration, and Cost Savings.
Ops Manager is the simplest way to run MongoDB, making it easy for operations teams to deploy, monitor, backup and scale MongoDB. Ops Manager was created by the engineers who develop the database and is available as part of MongoDB Enterprise Advanced. Many of the capabilities of Ops Manager are also available in MongoDB Cloud Manager, a service 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:
Each of these is explained in more detail below.
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.
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 or resizing the oplog can all be made with a few clicks and zero downtime.
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 capacity planning for further scale. Integration with existing monitoring tools is also straightforward via the Ops Manager API.
“Ops Manager provides real time & historic visibility into MongoDB with integration into operational tools”
“Alerts enable proactive management of MongoDB”
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 are the only backup solutions for MongoDB with 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.
How do the MongoDB operational capabilities stack up to relational databases and key-value stores? Take a look at the chart below:
|Self Healing Recovery with Automatic Failover||Yes||Often Requires Additional Clustering Software||No: Manual Failover Often Recommended|
|Separate Caching Layer Required||No||Often||No|
|Data Center Awareness||Yes||Expensive Add-on||No|
|Continuous Backup & Point in Time Recovery||Yes||Yes||No|
|API Integration with Systems Management Frameworks||Yes||Yes||No|
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.
MongoDB can be 1/10th the cost to build and run, compared to a relational database. The cost advantage is driven by:
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.