MMAPv1 is a storage engine used by MongoDB in the early days and has been replaced by WiredTiger, but it still works in some older deployments or specific scenarios. 1. It is based on the memory-mapped file mechanism, and relies on operating system cache rather than internal cache, which simplifies implementation but has weak control; 2. Adopt pre-allocation strategy to reduce fragmentation, but may lead to waste of space; 3. Use global write locks to limit concurrency performance, suitable for scenarios that read more and write less; 4. Support logs but are not as efficient as WiredTiger, which poses a certain risk of data loss; 5. Suitable for scenarios such as low memory, embedded systems or maintenance of old systems, but new deployments recommend using WiredTiger for better performance and functional support.

The MMAPv1 storage engine was MongoDB's original storage engine and is now considered legacy. It played a major role in MongoDB's early adoption due to its simplicity and compatibility with a wide range of environments. Though it's no longer the default (replaced by WiredTiger), understanding MMAPv1 can still be useful when dealing with older deployments or specific use cases that might benefit from its characteristics.

How MMAPv1 Works: Memory-Mapped Files

MMAPv1 relies on memory-mapped files to manage data. This means that the database files are directly mapped into the operating system's virtual memory space. As a result:

• Data reads and writes go through the filesystem cache managed by the OS.
• There's no internal caching mechanism within the storage engine itself — it depends entirely on the OS for caching.
• Performance can vary depending on how well the OS manages memory and which other processes are running.

This approach simplifies the implementation but gives less control over memory usage compared to newer engines like WiredTiger.

File Allocation and Preallocation Strategy

One notable behavior of MMAPv1 is how it handles disk space:

• It preallocates data files in advance to avoid fragmentation and performance issues during growth.
• Each new database starts with several preallocated files (typically around 3–5 files, each 64MB initially).
• Collections are stored in a single namespace file ( <dbname>.0</dbname> , <dbname>.1</dbname> , etc.), which can lead to wasted space if collections grow unevenly.

This can cause databases to take up more disk space than strictly needed, especially when starting out or after large deletions.

Concurrency and Locking Model

MMAPv1 uses a global write lock at the instance level, though it allows read operations to proceed concurrently with writes. This means:

• Only one write operation can happen at a time across the entire MongoDB instance.
• Read operations can block behind writes, leading to potential bottlenecks under heavy write loads.
• Performance may degrade significantly under high concurrency.

If your workload involves frequently writes or multiple collections being updated simultaneously, MMAPv1 may not be the best choice.

Journaling and Durability

MMAPv1 supports journaling to protect against crashes:

• Write operations are first written to the journal before being applied to the data files.
• The journal is flushed every 100–200 million seconds by default, meaning some data loss is possible in case of a crash.
• Journaling adds overhead but is essential for maintaining data integrity.

It's worth noting that journaling in MMAPv1 doesn't offer the same efficiency as in WiredTiger, partly due to the way data is structured and flushed.

Why Use MMAPv1 Today?

While MMAPv1 has been deprecated for most use cases, there are still a few scenarios where it might make sense:

• Running on systems with very limited RAM (since it offloads caching to the OS).
• Maintaining compatibility with old applications or backups that were built with MMAPv1.
• Embedded systems where simplicity and minimum dependencies matter more than advanced features.

That said, unless you have a clear reason, it's generally better to stick with WiredTiger for better performance, compression, and concurrency support.

So while MMAPv1 isn't recommended for new deployments, knowing how it works helps when maintaining legacy systems or troubleshooting older setups. It's straightforward, predictable in some ways, and closely tied to how the OS managements memory — which can be both a strength and a limitation.

The above is the detailed content of What is the role of the MMAPv1 storage engine (legacy) and its key characteristics?. For more information, please follow other related articles on the PHP Chinese website!