Relational databases have a long-standing position in most organizations, and for good reason.
Not only are they are supported by an extensive ecosystem of tools, but there is also a large pool of labor qualified to implement and maintain these systems.
But organizations are increasingly considering alternatives to legacy relational infrastructure.
This movement is driven by the challenges of building modern applications ranging from applications that create massive volumes of new, rapidly-changing data types to organizations scaling out their architectures using open source software.
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 IBM and other companies have done over the last 40 years to make relational databases what they are today.
Figure 1: MongoDB 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 and secondary indexes. Users should be able to access and manipulate their data in sophisticated ways to support both operational and analytical applications.
- — 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.
- — Enterprise management and integrations. Databases are just one piece of application infrastructure, and as such, they need to fit seamlessly into the enterprise IT stack.
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.
- — Scalability and Performance. NoSQL databases were all built with a focus on scalability, so they all include some form of sharding or partitioning.
- — 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.
With its Nexus Architecture, MongoDB is the only database that harnesses the innovations of NoSQL while maintaining the foundation of relational databases.
MongoDB Flexible Storage Architecture
Through the use of pluggable storage engines, 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.
Storage engines can be mixed on same replica set or sharded cluster. Users can also leverage the same MongoDB query language, data model, scaling, security, and operational tooling across different applications, each powered by different pluggable MongoDB storage engines.
Figure 2: MongoDB Flexible storage architecture
MongoDB 3.2 ships with four supported storage engines, all of which can coexist within a single MongoDB replica set. The supported storage engines include WiredTiger, Encrypted, In-Memory, and MMAPv1.
More detailed information can be found here on MongoDB storage engines.
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.
However, 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.
MongoDB Data Management (Auto Sharding)
MongoDB provides horizontal scale-out for databases on low cost, commodity hardware or cloud infrastructure 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 sharded cluster as the data grows or the size of the cluster increases or decreases. Unlike relational databases, sharding is automatic and built into the database, minimizing the burden for developers and operations teams.
Figure 3: MongoDB Horizontal sharding
MongoDB is ACID compliant 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 ensures complete isolation as a document is updated. Any errors cause the operation to roll back, and clients receive a consistent view of the document.
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 and can be used to scale read operations. Replica failover is fully automated, eliminating the need for administrators to intervene manually.
A replica set consists of multiple replicas. At any given time, one member acts as the primary replica set member and the other members act as secondary replica set members. MongoDB is strongly consistent by default.
Reads and writes are issued to a primary copy of the data. If the primary member fails for any reason (e.g., hardware failure, network partition), one of the secondary members is automatically elected to primary and begins to process all writes.
Figure 4: MongoDB Replication
Replica sets also provide operational flexibility by providing a way to upgrade hardware and software without requiring the database to go offline. This is an important feature, because these types of operations can account for as much as one third of all downtime in traditional systems.
MongoDB Enterprise Advanced features extensive capabilities to defend, detect, and control access to data through its native authentication, authorization, auditing, and encryption features.
Enterprises can use MongoDB Enterprise Advanced to comply with standards such as HIPPA, FERPA, PCI, SOX, GLBA, ISO 27001, and others.
To learn more, download the MongoDB Security Reference Architecture.
Managing MongoDB: Provisioning, Monitoring, and Disaster Recovery
Ops managers and cloud managers incorporate best practices to help keep managed databases healthy and optimized. They ensure operational continuity by converting complex manual tasks into reliable, automated procedures with the click of a button.
- Deployment. Any topology, at any scale.
- Upgrade. In minutes, with no downtime.
- Scale. Add capacity, without taking the application offline.
- Visualize. Graphically display query performance to identify and fix sluggish operations.
- Point-in-time, Scheduled Backups. Restore complete running clusters to any point in time with just a few clicks, because disasters aren't predictable.
- Performance Alerts. Monitor over 100 system metrics and get custom alerts before the system degrades.
MongoDB is the database for today's applications: innovative, fast time-to-market, globally scalable, reliable, and inexpensive to operate. In this blog, we have explored the fundamental concepts and assumptions that underlay the architecture of MongoDB.
More detailed information can be found here.