Grokking MongoDB

0% completed

Introduction to MongoDB

On This Page

How MongoDB Organizes Data

History and Development

Core Features

Advantages

How Consistent MongoDB Is

Disadvantages

When to Use MongoDB

Tools for Working With MongoDB

Here is one MongoDB command, followed by the answer that the server returned:

db.users.findOne({ name: "John Doe" })

{
  _id: ObjectId('507f1f77bcf86cd799439011'),
  name: 'John Doe',
  age: 30,
  email: 'john.doe@example.com'
}

The answer is one record, and MongoDB calls this kind of record a document. It is a set of named fields, similar to a JSON object, and the database can read and search each field. The command asks the users group of records for one record whose name is John Doe, and the first thing to notice is the structure of the answer.

How MongoDB Organizes Data

MongoDB stores data at three levels. One server can contain several databases, each database contains collections, and each collection contains documents. The document above could be located like this:

Database: myDatabase
Collection: users, the group of documents that describe users
Document: the record for John Doe, with four fields

A collection corresponds to a table in a relational database, and a document corresponds to a row. The difference is that documents in one collection do not need the same fields. After adding a second user with no age field and a list of phone numbers, the same collection returned both of these documents, shown here without their _id fields:

[
  { name: 'John Doe', age: 30, email: 'john.doe@example.com' },
  {
    name: 'Ana Ruiz',
    email: 'ana.ruiz@example.com',
    phones: [ '555-0100', '555-0101' ]
  }
]

This flexibility is the default, and it is not the only option. When the structure of your data becomes stable, you can add schema validation, and MongoDB will then reject writes that break your rules. Although documents look like JSON when you read them, MongoDB stores them in BSON, a binary format that also includes types JSON lacks. Two of those types are dates and the ObjectId in the _id field above, an identifier that MongoDB can generate for each document.

History and Development

The company 10gen began building MongoDB in 2007 and first released it in 2009. The company renamed itself MongoDB Inc. in 2013. The goal was a database that was easier to change and to scale across machines than a traditional relational database.

The features grew considerably over time. Early versions added ways to keep copies of the data on several servers (replication), to divide a collection across servers (sharding), and to process documents in a series of steps (the aggregation framework). Multi-document ACID transactions came later. Version 4.0 added them for replica sets, the groups of servers that keep copies of the same data, and version 4.2 added them for sharded clusters, the groups that divide it.

The license also changed. Versions released after October 16, 2018 use the Server Side Public License (SSPL). The Community Edition is free to use and its source code is public, but the Open Source Initiative does not recognize the SSPL as an open-source license, so "source-available" is the accurate description.

Core Features

The picture below groups seven features by what they do, and the first two are already visible in John's document.

Seven core features of MongoDB, grouped by what they do.

Document-oriented storage means that related data can be stored together in one nested record. A flexible schema means that documents in a collection can differ, while validation rules remain optional.

The next three features help you find and process those documents. An index is a lookup structure that speeds up searches, such as a search for John by email. Several types exist, including compound indexes on more than one field, text indexes, and geospatial indexes. The aggregation framework passes documents through a series of steps that filter, group, and transform them. Geospatial queries find documents near a location, which suits location-based applications.

The last two features concern growth and failure. Sharding divides a collection across several servers, and this is how MongoDB performs horizontal scaling. Replication keeps copies of the data on several servers, so a failure of one server does not lose the data or stop the system for long.

Advantages

MongoDB can read and write quickly when your queries use suitable indexes and your documents match the way the application reads data. Reading John's document takes one lookup, even if it contains nested data that a relational design would store in several tables. A query with no suitable index, however, has to examine every document in the collection, so speed is a result of good design and is not automatic.

Changing your data is also simpler. A new field can appear in new documents without any change to existing ones. This helps while requirements are still changing, although your application must then handle both the old and the new form of the document.

Developers often find the API natural, because a document maps directly to an object in their programming language. MongoDB also has extensive documentation and a large community, so answers to common problems are easy to find. Sharding is built in as well, although choosing a good shard key, the field that decides how data is divided, requires careful thought.

How Consistent MongoDB Is

Before the real costs, one commonly claimed cost needs correcting. MongoDB is often described as eventually consistent, but this description is wrong for its default settings. In a replica set, one server called the primary accepts all writes, and the others, called secondaries, copy those writes from it. Applications read from the primary by default, so a read normally sees the latest write that the primary has accepted.

Old values appear when the application reads from a secondary. Suppose John's age changes from 30 to 31, and one secondary has not yet copied the change. A read sent to that secondary returns 30. Reading from a secondary is an option that you must turn on. It suits requests that can accept slightly old data. If you never set that option, your reads go to the primary.

Two further details matter. Since version 5.0, MongoDB by default confirms a write only after a majority of the servers that vote and store data have it, which protects the write if the primary fails. The exception is some sets containing arbiters, voting servers that store no data, where the default can be confirmation by the primary alone. A default read can also return a write that has not yet reached a majority, and such a write can be undone if the primary fails at that moment. An option called read concern lets a read ask for majority-confirmed data only.

Disadvantages

MongoDB has real costs, and they are different from the ones usually claimed.

Combining data takes more work than in SQL. A join combines matching records from two collections, and MongoDB does have joins, through the $lookup step of the aggregation framework. However, $lookup is a left outer join within one database. A customer who has no orders stays in the result, and a collection in another database cannot be reached. Complex reports written this way are often longer and harder to tune than the same SQL query. A design with many relationships between collections loses much of the benefit of the document model.

Transactions are available but cost more. MongoDB supports multi-document ACID transactions, and a change to a single document is always atomic. The official documentation states that a transaction across documents usually has a greater performance cost than a single-document write, and recommends modeling data so that most changes affect one document.

Documents have limits. A document can be at most 16 mebibytes (16,777,216 bytes), and the documentation sets a limit of 100 levels of nesting. A design that keeps adding to one array inside a document will eventually reach the size limit, and it will become slow before then.

Data can become inconsistent without rules. With no validation, nothing prevents one document from storing age as a number and another from storing it as a string. Your application discovers the problem only when it reads the data.

The query language is not standard. MongoDB queries use MongoDB's own syntax, not SQL. Knowledge and code from a relational system do not transfer directly, and moving away from MongoDB means rewriting those queries.

When to Use MongoDB

MongoDB is a good candidate when several of these conditions apply:

Changing or varied data: records differ from one another, or the structure changes often.
Data read together: the application usually needs a record with its related data, so one document can answer most requests.
Large data or heavy traffic: the workload may outgrow a single server and need to be divided across several.
Fast reads and writes of individual records: requests read or change a few documents through indexes, as in many real-time applications.
Location data: the application searches by geographic position.

Consider a relational database instead when most requests combine many kinds of records, when you depend on tools that expect SQL, or when your business logic needs multi-record transactions for most of its writes.

Tools for Working With MongoDB

You can work with MongoDB in three main ways:

MongoDB Shell (mongosh): the command-line interface used in this course. It replaced the older mongo shell, which was removed in version 6.0 and which you may still see in old tutorials.
MongoDB Compass: a graphical application for exploring and managing data.
Drivers: official libraries for programming languages, including Python, JavaScript, and Java, which let your application talk to MongoDB.

Mark as Completed

Reading Progress

Vote for new content

On This Page

How MongoDB Organizes Data

History and Development

Core Features

Advantages

How Consistent MongoDB Is

Disadvantages

When to Use MongoDB

Tools for Working With MongoDB