A MongoDB White Paper

Performance Best Practices for

MongoDB
June 2018
Table of Contents
Introduction 1

MongoDB Pluggable Storage Engines 1

Hardware 2

Application Patterns 4

Multi-Document ACID Transactions 7

Schema Design & Indexes 7

Disk I/O 9

Considerations for Benchmarks 10

MongoDB Atlas: Database as a Service For MongoDB 11

MongoDB Stitch: Backend as a Service 12

We Can Help 13

Resources 13
Introduction

MongoDB is designed to meet the demands of modern services to work with you at every stage of your application
apps with a technology foundation that enables you lifecycle.
through:
This guide is aimed at users managing MongoDB
1. The document data model – presenting you the best themselves. A dedicated guide is provided for users of the
way to work with dat
dataa. MongoDB database as a service – MongoDB Atlas Best
Practices.
2. A distributed systems design – allowing you to
intelligently put dat
dataa wher
where
e you want it
it. For a discussion on the architecture of MongoDB and
3. A unified experience that gives you the fr
freedom
eedom to run some of its underlying assumptions, see the MongoDB
anywher
anywhere e – allowing you to future-proof your work and Architecture Guide. For a discussion on operating a
eliminate vendor lock-in. MongoDB system, see the MongoDB Operations Best
Practices.
This guide outlines considerations for achieving
performance at scale in a MongoDB system across a
number of key dimensions, including hardware, application MongoDB Pluggable Storage
patterns, including multi-document ACID transactions
released in MongoDB 4.0, schema design, and indexing,
Engines
disk I/O, Amazon EC2, and designing for benchmarks.
While this guide is broad in scope, it is not exhaustive. You MongoDB exposes the storage engine API, enabling the
should refer to MongoDB documentation and consider the integration of pluggable storage engines that extend
no cost, online training classes offered by MongoDB MongoDB with new capabilities, and enable optimal use of
University. MongoDB also offers a range of consulting specific hardware architectures to meet specific workload

1
requirements. MongoDB ships with multiple supported
Hardware
storage engines:

• The default WiriredT

edTiger
iger storage engine
engine. For most You can run MongoDB anywhere – from ARM (64 bit)
applications, WiredTiger's granular concurrency control processors through to commodity x86 CPUs, all the way
and native compression will provide the best all-around up to IBM POWER and zSeries platforms.
performance and storage efficiency for the broadest
range of applications. Most users scale out their systems by using many
commodity servers operating together as a cluster.
• The Encrypted storage engine
engine, protecting highly
MongoDB provides native replication to ensure availability;
sensitive data, without the performance or management
auto-sharding to uniformly distribute data across servers;
overhead of separate files system encryption. The
and in-memory computing to provide high performance
Encrypted storage is based upon WiredTiger and so
without resorting to a separate caching layer. The following
throughout this document, statements regarding
considerations will help you optimize the hardware of your
WiredTiger also apply to the Encrypted storage engine.
MongoDB system.
This engine is part of MongoDB Enterprise Advanced.

• The In-Memory storage engine

engine, delivering predictable Ensur
Ensuree your working set fits in RAM. As with most
latency coupled with real-time analytics for the most databases, MongoDB performs best when the working set
demanding, applications. This engine is part of (indexes and most frequently accessed data) fits in RAM.
MongoDB Enterprise Advanced. RAM size is the most important factor for hardware; other
optimizations may not significantly improve the
• The M MAP
MAPv1
v1 storage engine
engine, which is provided for
performance of the system if there is insufficient RAM. If
backwards compatibility only. This engine is deprecated
your working set exceeds the RAM of a single server,
with the MongoDB 4.0 release.
consider sharding your database across multiple servers.
Any of these storage engines can coexist within a single Use the db.serverStatus() command to view an
MongoDB replica set, making it easy to evaluate and estimate of the the current working set size.
migrate between them. WiredTiger is the default storage
Use SSSSDs for write-heavy applic
applications.
ations. Most disk
engine for MongoDB deployments; if another engine is
access patterns in MongoDB do not have sequential
preferred then start the mongod using the
properties, and as a result, customers may experience
--storageEngine option. If a 3.2 (or later) mongod
substantial performance gains by using SSDs. Good
process is started and one or more databases already exist
results and strong price to performance have been
then MongoDB will use whichever storage engine those
observed with SATA, PCIe, and NVMe SSDs. Commodity
databases were created with.
SATA spinning drives are comparable to higher cost
While each storage engine is optimized for different spinning drives due to the random access patterns of
workloads, users still leverage the same MongoDB query MongoDB: rather than spending more on expensive
language, data model, scaling, security, and operational spinning drives, that money may be more effectively spent
tooling independent of the engine they use. As a result, on more RAM or SSDs. Another benefit of using SSDs is
most best practices in this guide apply to all of the the performance benefit of flash over hard disk drives if the
supported storage engines. Any differences in working set no longer fits in memory.
recommendations between the storage engines are noted.
While data files benefit from SSDs, MongoDB's journal
files are good candidates for fast, conventional disks due
to their high sequential write profile.

Most MongoDB deployments should use RAID-10. RAID-5

and RAID-6 have limitations and may not provide sufficient
performance. RAID-0 provides good read and write

2
performance, but insufficient fault tolerance. MongoDB's compressed with zlib to attain maximum storage density
replica sets allow deployments to provide stronger with a lower cost-per-bit.
availability for data, and should be considered with RAID • As data ages, MongoDB automatically migrates it
and other factors to meet the desired availability SLA. between storage tiers, without administrators having to
Configur
Configuree compr
compression
ession for storage and II/O
/O-intensive
-intensive build tools or ETL processes to manage data
workloads. MongoDB natively supports compression movement.
when using the WiredTiger and encrypted storage engines. Alloc
Allocate
ate CP
CPUU har
hardwar
dware e budget for faster CP
CPUs.
Us.
Compression reduces storage footprint by as much as MongoDB will deliver better performance on faster CPUs,
80%, and enables higher IOPs as fewer bits are read from with the WiredTiger storage engine able to saturate
disk. As with any compression algorithm, administrators multi-core processor resources.
trade storage efficiency for CPU overhead, and so it is
important to test the impacts of compression in your own Dedic
Dedicate
ate eac
eachh server to a single rrole
ole in the system.
environment. For best performance, users should run one mongod
process per host. With appropriate sizing and resource
MongoDB offers administrators a range of compression
allocation using virtualization or container technologies,
options for both documents and indexes. The default
multiple MongoDB processes can run on a single server
Snappy compression algorithm provides a balance
without contending for resources. If using the WiredTiger
between high document and journal compression ratios
storage engine, administrators will need to calculate the
(typically around 70%, dependent on data types) with low
appropriate cache size for each instance by evaluating
CPU overhead, while the optional zlib library will achieve
what portion of total RAM each of them should use, and
higher compression, but incur additional CPU cycles as
splitting the default cache_size between each.
data is written to and read from disk. Indexes use prefix
compression by default, which serves to reduce the The size of the WiredTiger cache is tunable through the
in-memory footprint of index storage, freeing up more of storage.wiredTiger.engineConfig.cacheSizeGB
the RAM for frequently accessed documents. Testing has setting and should be large enough to hold your entire
shown a typical 50% compression ratio using the prefix working set. If the cache does not have enough space to
algorithm, though users are advised to test with their own load additional data, WiredTiger evicts pages from the
data sets. Administrators can modify the default cache to free up space. By default,
compression settings for all collections and indexes. storage.wiredTiger.engineConfig.cacheSizeGB is
Compression is also configurable on a per-collection and set to 60% of available RAM - 1 GB; caution should be
per-index basis during collection and index creation. taken if raising the value as it takes resources from the OS,
and WiredTiger performance can actually degrade as the
Combine multiple storage & compr compression
ession types.
filesystem cache becomes less effective.
MongoDB provides features to facilitate the management
of data lifecycles, including Time to Live indexes, and For availability, multiple members of the same replica set
capped collections. In addition, by using MongoDB Zones, should not be co-located on the same physical hardware or
administrators can build highly efficient tiered storage share any single point of failure such as a power supply.
models to support the data lifecycle. By assigning shards to
Zones, administrators can balance query latency with Use multiple query rrouters.
outers. Use multiple mongos
storage density and cost by assigning data sets based on a processes spread across multiple servers. A common
value such as a timestamp to specific storage devices: deployment is to co-locate the mongos process on
application servers, which allows for local communication
• Recent, frequently accessed data can be assigned to between the application and the mongos process. The
high performance SSDs with Snappy compression appropriate number of mongos processes will depend on
enabled.
the nature of the application and deployment.
• Older, less frequently accessed data is tagged to
lower-throughput hard disk drives where it is

3
Exploit multiple cor
cores.
es. The WiredTiger storage engine is
Application Patterns
multi-threaded and can take advantage of many CPU
cores. Specifically, the total number of active threads (i.e.
concurrent operations) relative to the number of CPUs can MongoDB is an extremely flexible database due to its
impact performance: dynamic schema and rich query model. The system
provides extensive secondary indexing capabilities to
• Throughput increases as the number of concurrent optimize query performance. Users should consider the
active operations increases up to and beyond the flexibility and sophistication of the system in order to make
number of CPUs. the right trade-offs for their application. The following
• Throughput eventually decreases as the number of considerations will help you optimize your application
concurrent active operations exceeds the number of patterns.
CPUs by some threshold amount.
Issue updates to only modify fields that have
The threshold amount depends on your application. You changed. Rather than retrieving the entire document in
can determine the optimum number of concurrent active your application, updating fields, then saving the document
operations for your application by experimenting and back to the database, instead issue the update to specific
measuring throughput and latency. fields. This has the advantage of less network usage and
reduced database overhead.
Disable N
NUUMA, Running MongoDB on a system with
Non-Uniform Access Memory (NUMA) can cause a Avoid negation in queries. Like most database systems,
number of operational problems, including slow MongoDB does not index the absence of values and
performance for periods of time and high system process negation conditions may require scanning all documents. If
usage. negation is the only condition and it is not selective (for
example, querying an orders table where 99% of the
When running MongoDB servers and clients on NUMA
orders are complete to identify those that have not been
hardware, you should configure a memory interleave policy
fulfilled), all records will need to be scanned.
so that the host behaves in a non-NUMA fashion.
Use cover
covereded queries when possible. Covered queries
Network Compr
Compression.
ession. As a distributed database,
return results from the indexes directly without accessing
MongoDB relies on efficient network transport during
documents and are therefore very efficient. For a query to
query routing and inter-node replication. MongoDB 3.4
be covered all the fields included in the query must be
introduced a new option to compress the wire protocol
present in an index, and all the fields returned by the query
used for intra-cluster communications, MongoDB 3.6
must also be present in that index. To determine whether a
extended this to cover compression of network traffic
query is a covered query, use the explain() method. If
between the client and the database. Based on the snappy
the explain() output displays true for the indexOnly
compression algorithm, network traffic can be compressed
field, the query is covered by an index, and MongoDB
by up to 70%, providing major performance benefits in
queries only that index to match the query and return the
bandwidth-constrained environments, and reducing
results.
networking costs.
Test every query in your applic
application
ation with explain().
Compression is off by default, but can be enabled by
MongoDB provides an explain plan capability that shows
setting networkMessageCompressors to snappy.
information about how a query will be, or was, resolved,
Compressing and decompressing network traffic requires including:
CPU resources – typically low single digit percentage
• The number of documents returned
overhead. Compression is ideal for those environments
where performance is bottlenecked by bandwidth, and • The number of documents read
sufficient CPU capacity is available. • Which indexes were used

4
 Figur
Figuree 1: MongoDB Compass visual query plan for performance optimization across distributed clusters

• Whether the query was covered, meaning no documents MongoDB Compass provides the ability to visualize explain
needed to be read to return results plans, presenting key information on how a query
performed – for example the number of documents
• Whether an in-memory sort was performed, which
returned, execution time, index usage, and more. Each
indicates an index would be beneficial
stage of the execution pipeline is represented as a node in
• The number of index entries scanned a tree, making it simple to view explain plans from queries
• How long the query took to resolve in milliseconds distributed across multiple nodes.
(when using the executionStats mode)
Update multiple array elements in a single operation.
• Which alternative query plans were rejected (when With fully expressive array updates, developers can perform
using the allPlansExecution mode) complex array manipulations against matching elements of
an array – including elements embedded in nested arrays –
The explain plan will show 0 milliseconds if the query was all in a single update operation. Using the arrayFilters
resolved in less than 1 ms, which is typical in well-tuned option, the update can specify which elements to modify in
systems. When the explain plan is called, prior cached the array field.
query plans are abandoned, and the process of testing
multiple indexes is repeated to ensure the best possible Avoid sc
scatter-gather
atter-gather queries. In sharded systems,
plan is used. The query plan can be calculated and queries that cannot be routed to a single shard must be
returned without first having to run the query. This enables broadcast to multiple shards for evaluation. Because these
DBAs to review which plan will be used to execute the queries involve multiple shards for each request they do
query, without having to wait for the query to run to not scale well as more shards are added.
completion.

5
Choose the apprappropriate
opriate write guarantees. MongoDB MongoDB supports a readConcern level of “Linearizable”.
allows administrators to specify the level of persistence The linearizable read concern ensures that a node is still
guarantee when issuing writes to the database, which is the primary member of the replica set at the time of the
called the write concern. The following options can be read, and that the data it returns will not be rolled back if
configured on a per connection, per database, per another node is subsequently elected as the new primary
collection, or even per operation basis. The options are as member. Configuring this read concern level can have a
follows: significant impact on latency, therefore a maxTimeMS
value should be supplied in order to timeout long running
• Write Acknowledged: This is the default write concern.
operations.
The mongod will confirm the execution of the write
operation, allowing the client to catch network, duplicate Use ccausal
ausal consistency wherwheree needed. Introduced in
key, Document Validation, and other exceptions. MongoDB 3.6, causal consistency guarantees that every
read operation within a client session will always see the
• Journal Acknowledged: The mongod will confirm the
previous write operation, regardless of which replica is
write operation only after it has flushed the operation to
serving the request. You can minimize any latency impact
the journal on the primary. This confirms that the write
by using causal consistency only where it is needed.
operation can survive a mongod crash and ensures that
the write operation is durable on disk. Use the most rrecent
ecent drivers fr
from
om MongoDB.
• Replica Acknowledged: It is also possible to wait for MongoDB supports drivers for nearly a dozen languages.
acknowledgment of writes to other replica set members. These drivers are engineered by the same team that
MongoDB supports writing to a specific number of maintains the database kernel. Drivers are updated more
replicas. This also ensures that the write is written to the frequently than the database, typically every two months.
journal on the secondaries. Because replicas can be Always use the most recent version of the drivers when
deployed across racks within data centers and across possible. Install native extensions if available for your
multiple data centers, ensuring writes propagate to language. Join the MongoDB community mailing list to
additional replicas can provide extremely robust keep track of updates.
durability.
Ensur
Ensure e uniform distribution of shar
shard
d keys. When shard
• Majority: This write concern waits for the write to be keys are not uniformly distributed for reads and writes,
applied to a majority of replica set members. This also operations may be limited by the capacity of a single shard.
ensures that the write is recorded in the journal on When shard keys are uniformly distributed, no single shard
these replicas – including on the primary. will limit the capacity of the system.
• Data Center Awareness: Using tag sets, sophisticated
Use hash-based shar sharding
ding when appr
appropriate.
opriate. For
policies can be created to ensure data is written to
applications that issue range-based queries, range-based
specific combinations of replicas prior to
sharding is beneficial because operations can be routed to
acknowledgment of success. For example, you can
the fewest shards necessary, usually a single shard.
create a policy that requires writes to be written to at
However, range-based sharding requires a good
least three data centers on two continents, or two
understanding of your data and queries, which in some
servers across two racks in a specific data center. For
cases may not be practical. Hash-based sharding ensures
more information see the MongoDB Documentation on
a uniform distribution of reads and writes, but it does not
Data Center Awareness.
provide efficient range-based operations.
Choose the right rread-concern.
ead-concern. To ensure isolation and
consistency, the readConcern can be set to majority to
indicate that data should only be returned to the
application if it has been replicated to a majority of the
nodes in the replica set, and so cannot be rolled back in
the event of a failure.

6
Multi-Document ACID 1. By default, MongoDB will automatically abort any
multi-document transaction that runs for more than 60
Transactions seconds. Note that if write volumes to the server are
low, you have the flexibility to tune your transactions for
a longer execution time. To address timeouts, the
Because documents can bring together related data that
transaction should be broken into smaller parts that
would otherwise be modelled across separate parent-child
allow execution within the configured time limit. You
tables in a tabular schema, MongoDB’s atomic
should also ensure your query patterns are properly
single-document operations provide transaction semantics
optimized with the appropriate index coverage to allow
that meet the data integrity needs of the majority of
fast data access within the transaction.
applications. One or more fields may be written in a single
operation, including updates to multiple sub-documents 2. There are no hard limits to the number of documents
and elements of an array. The guarantees provided by that can be read within a transaction. As a best practice,
MongoDB ensure complete isolation as a document is no more than 1,000 documents should be modified
updated; any errors cause the operation to roll back so that within a transaction. For operations that need to modify
clients receive a consistent view of the document. more than 1,000 documents, developers should break
MongoDB’s existing document atomicity guarantees will the transaction into separate parts that process
meet 80-90% of an application’s transactional needs. They documents in batches.
remain the recommended way of enforcing your app’s data 3. In MongoDB 4.0, a transaction is represented in a
integrity requirements single oplog entry, therefore must be within the 16MB
MongoDB 4.0 adds support for multi-document ACID document size limit. While an update operation only
transactions, making it even easier for developers to stores the deltas of the update (i.e., what has changed),
address more use cases with MongoDB. They feel just like an insert will store the entire document. As a result, the
the transactions developers are familiar with from relational combination of oplog descriptions for all statements in
databases – multi-statement, similar syntax, and easy to the transaction must be less than 16MB. If this limit is
add to any application. Through snapshot isolation, exceeded, the transaction will be aborted and fully rolled
transactions provide a consistent view of data, enforce back. The transaction should therefore be decomposed
all-or-nothing execution, and do not impact performance into a smaller set of operations that can be represented
for workloads that do not require them. For those in 16MB or less.
operations that do require multi-document transactions, 4. When a transaction aborts, an exception is returned to
there are several best practices that developers should the driver and the transaction is fully rolled back.
observe. Developers should add application logic that can catch
and retry a transaction that aborts due to temporary
Creating long running transactions, or attempting to
exceptions, such as a transient network failure or a
perform an excessive number of operations in a single
primary replica election. With retryable writes, the
ACID transaction can result in high pressure on
MongoDB drivers will automatically retry the commit
WiredTiger’s cache. This is because the cache must
statement of the transaction.
maintain state for all subsequent writes since the oldest
snapshot was created. As a transaction always uses the You can review all best practices in the MongoDB
same snapshot while it is running, new writes accumulate documentation for multi-document transactions.
in the cache throughout the duration of the transaction.
These writes cannot be flushed until transactions currently
running on old snapshots commit or abort, at which time Schema Design & Indexes
the transactions release their locks and WiredTiger can
evict the snapshot. To maintain predictable levels of
MongoDB uses a binary document data model based
database performance, developers should therefore
called BSON that is based on the JSON standard. Unlike
consider the following:
flat tables in a relational database, MongoDB's document

7
data model is closely aligned to the objects used in modern specify last name only. In this example an additional index
programming languages, and in most cases it removes the on last name only is unnecessary,
need for multi-document transactions or joins due to the
Use a compound index rather than index intersection.
advantages of having related data for an entity or object
For best performance when querying via multiple
contained within a single document, rather than spread
predicates, compound indexes will generally be a better
across multiple tables. There are best practices for
option.
modeling data as documents, and the right approach will
depend on the goals of your application. The following Use partial indexes. Reduce the size and performance of
considerations will help you make the right choices in indexes by only including documents that will be accessed
designing the schema and indexes for your application. through the index. e.g. Create a partial index on the
orderID field that only includes order documents with an
Avoid lar
large
ge documents. The maximum size for
orderStatus of "In progress", or only index the
documents in MongoDB is 16 MB. In practice, most
documents are a few kilobytes or less. Consider emailAddress field for documents where it exists.

documents more like rows in a table than the tables

Avoid rregular
egular expr
expressions
essions that ar
aree not left anc
anchor
hored
ed
themselves. Rather than maintaining lists of records in a
or rrooted.
ooted. Indexes are ordered by value. Leading wildcards
single document, instead make each record a document.
are inefficient and may result in full index scans. Trailing
For large media items, such as video or images, consider
wildcards can be efficient if there are sufficient
using GridFS, a convention implemented by all the drivers
case-sensitive leading characters in the expression.
that automatically stores the binary data across many
smaller documents. Use index optimizations available in the W
Wir
iredT
edTiger
iger
storage engine. As discussed earlier, the WiredTiger
Avoid unnecessarily long field names. Field names are
engine compresses indexes by default. In addition,
repeated across documents and consume space. By using
administrators have the flexibility to place indexes on their
smaller field names your data will consume less space,
own separate volume, allowing for faster disk paging and
which allows for a larger number of documents to fit in
lower contention.
RAM. Note that with WiredTiger's native compression, long
field names have less of an impact on the amount of disk Underst
Understand
and any existing document sc
schema
hema –
space used but the impact on RAM is the same. MongoDB Compass. If there is an existing MongoDB
database that needs to be understood and optimized then
Use ccaution
aution when considering indexes on
MongoDB Compass is an invaluable tool.
low-c
low-carardinality
dinality fields. Queries on fields with low
cardinality can return large result sets. Avoid returning The MongoDB Compass GUI allows users to understand
large result sets when possible. Compound indexes may the structure of existing data in the database and perform
include values with low cardinality, but the value of the ad hoc queries against it – all with zero knowledge of
combined fields should exhibit high cardinality. MongoDB's query language. By understanding what kind
of data is present, you're better placed to determine what
Eliminate unnecessary indexes. Indexes are
indexes might be appropriate.
resource-intensive: even with compression enabled they
consume RAM, and as fields are updated their associated Without Compass, users wishing to understand the shape
indexes must be maintained, incurring additional disk I/O of their data would have to connect to the MongoDB shell
overhead. and write queries to reverse engineer the document
structure, field names and data types.
Remove indexes that ar are
e pr
prefixes
efixes of other indexes.
Compound indexes can be used for queries on leading
fields within an index. For example, a compound index on
last name, first name can be also used to filter queries that

8
 the best storage configuration, including OS and file
system settings.

Readahead size should be set to 0 for W

Wir
iredT
edTiger
iger.. Use
the blockdev --setra <value> command to set the
readahead block size to 0 when using the WiredTiger
storage engine. A readahead value of 32 (16 kB) typically
works well when using MMAPv1.

If the readahead size is larger than the size of the data

requested, a larger block will be read from disk – this is
wasteful as most disk I/O in MongoDB is random. This has
two undesirable consequences which negatively effect
Figur
Figuree 2: Document structure and contents exposed by performance:
MongoDB Compass
1. The size of the read will consume RAM unnecessarily.
Ops Manager offers the Data Explorer to examine the 2. More time will be spent reading data than is necessary.
database’s schema by running queries to review document
structure, viewing collection metadata, and inspecting index Use XXFFS file systems; avoid E EXT3.
XT3. EXT3 is quite old
usage statistics. and is not optimal for most database workloads. With the
WiredTiger storage engine, use of XFS is strongly
Identify & rremove
emove obsolete indexes. To understand the recommended to avoid performance issues that have been
effectiveness of the existing indexes being used, an observed when using EXT4 with WiredTiger.
$indexStats aggregation stage can be used to
determine how frequently each index is used. MongoDB Disable access time settings. Most file systems will
Compass visualizes index coverage, enabling you to maintain metadata for the last time a file was accessed.
determine which specific fields are indexed, their type, size, While this may be useful for some applications, in a
and how often they are used. Ops Manager includes a database it means that the file system will issue a write
performance advisor which continuously highlights every time the database accesses a page, which will
slow-running queries and provides intelligent index negatively impact the performance and throughput of the
recommendations to improve performance. Using Ops system.
Manager automation, the administrator can then roll out the
Don't use Huge Pages. Do not use Huge Pages virtual
recommended indexes automatically, without incurring any
memory pages, MongoDB performs better with normal
application downtime.
virtual memory pages.

Use RAI
RAID1
D10.
0. Most MongoDB deployments should use
Disk I/O RAID-10. RAID-5 and RAID-6 have limitations and may
not provide sufficient performance. RAID-0 provides good
read and write performance, but insufficient fault tolerance.
While MongoDB performs all read and write operations
MongoDB's replica sets allow deployments to provide
through in-memory data structures, data is persisted to
stronger availability for data, and should be considered with
disk and queries on data not already in RAM trigger a read
RAID and other factors to meet the desired availability
from disk. As a result, the performance of the storage
SLA.
sub-system is a critical aspect of any system. Users should
take care to use high-performance storage and to avoid By using separate storage devices for the journal and data
networked storage when performance is a primary goal of files you can increase the overall throughput of the disk
the system. The following considerations will help you use subsystem. Because the disk I/O of the journal files tends
to be sequential, SSD may not provide a substantial

9
improvement and standard spinning disks may be more Without pre-splitting, data may be loaded into a shard then
cost effective. moved to a different shard as the load progresses. By
pre-splitting the data, documents will be loaded in parallel
Use multiple devices for differ
different
ent dat
databases
abases –
into the appropriate shards. If your benchmark does not
Wir
iredT
edTiger
iger.. Set directoryForIndexes so that indexes
include range queries, you can use hash-based sharding to
are stored in separate directories from collections and ensure a uniform distribution of writes.
directoryPerDB to use a different directory for each
database. The various directories can then be mapped to Disable the balancer for bulk loading. Prevent the
different storage devices, thus increasing overall balancer from rebalancing unnecessarily during bulk loads
throughput. to improve performance.

Note that using different storage devices will affect your Prime the system for several minutes. In a production
ability to create snapshot-style backups of your data, since MongoDB system the working set should fit in RAM, and
the files will be on different devices and volumes. all reads and writes will be executed against RAM.
MongoDB must first page the working set into RAM, so
• Implement multi-temperatur
multi-temperaturee storage & dat
dataa prime the system with representative queries for several
loc
locality
ality using MongoDB Zones. MongoDB Zones minutes before running the tests to get an accurate sense
allow precise control over where data is physically for how MongoDB will perform in production.
stored, accommodating a range of deployment
scenarios – for example by geography, by hardware Monitor everything to loc
locate
ate your bbottlenec
ottlenecks.
ks. It is
configuration, or by application. Administrators can important to understand the bottleneck for a benchmark.
continuously refine data placement rules by modifying Depending on many factors any component of the overall
shard key ranges, and MongoDB will automatically system could be the limiting factor. A variety of popular
migrate the data to its new Zone. tools can be used with MongoDB – many are listed in the
manual.

Considerations for Benchmarks The most comprehensive tool for monitoring MongoDB is
Ops Manager, available as a part of MongoDB Enterprise
Advanced. Featuring charts, custom dashboards, and
Generic benchmarks can be misleading and automated alerting, Ops Manager tracks 100+ key
misrepresentative of a technology and how well it will database and systems metrics including operations
perform for a given application. MongoDB instead counters, memory, and CPU utilization, replication status,
recommends that users model and benchmark their open connections, queues, and any node status. The
applications using data, queries, hardware, and other metrics are securely reported to Ops Manager where they
aspects of the system that are representative of their are processed, aggregated, alerted, and visualized in a
intended application. The following considerations will help browser, letting administrators easily determine the health
you develop benchmarks that are meaningful for your of MongoDB in real-time. The benefits of Ops Manager are
application. also available in the SaaS-based Cloud Manager, hosted by
MongoDB in the cloud. Organizations that run on
Model your benc
benchmark
hmark on your applic
application.
ation. The
MongoDB Enterprise Advanced can choose between Ops
queries, data, system configurations, and performance
Manager and Cloud Manager for their deployments.
goals you test in a benchmark exercise should reflect the
goals of your production system. Testing assumptions that
do not reflect your production system is likely to produce
misleading results.

Cr
Create
eate cchunks
hunks befor
beforee loading, or use hash-based
shar
sharding.
ding. If range queries are part of your benchmark use
range-based sharding and create chunks before loading.

10
 Figur
Figuree 4: Visual Query Profiling in MongoDB Ops & Cloud
Manager

Figur
Figuree 3: Ops Manager & Cloud Manager provides real
The Visual Query Profiler will analyze the data –
time visibility into MongoDB performance.
recommending additional indexes and optionally add them
through an automated, rolling index build.
In addition to monitoring, Ops Manager and Cloud Manager
provide automated deployment, upgrades, on-line index Ops Manager also offers the performance advisor which
builds, data exporation, and cross-shard on-line backups. continuously highlights slow-running queries and provides
intelligent index recommendations to improve performance.
Pr
Profiling.
ofiling. MongoDB provides a profiling capability called
Using Ops Manager automation, the administrator can then
Database Profiler, which logs fine-grained information
roll out the recommended indexes automatically, without
about database operations. The profiler can be enabled to
incurring any application downtime.
log information for all events or only those events whose
duration exceeds a configurable threshold (whose default MongoDB Compass visualizes index coverage, enabling
is 100 ms). Profiling data is stored in a capped collection you to determine which specific fields are indexed, their
where it can easily be searched for relevant events. It may type, size, and how often those indexes are used.
be easier to query this collection than parsing the log files.
MongoDB Ops Manager and Cloud Manager can be used Use mongoperf to ccharacterize
haracterize your storage system.
to visualize output from the profiler when identifying slow mongoperf is a free tool that allows users to simulate

queries. direct disk I/O as well as memory mapped I/O, with

configurable options for number of threads, size of
Ops Manager and Cloud Manager include a Visual Query documents, and other factors. This tool can help you to
Profiler that provides a quick and convenient way for understand what sort of throughput is possible with your
operations teams and DBAs to analyze specific queries or system, for disk-bound I/O as well as memory-mapped I/
query families. The Visual Query Profiler (as shown in O.
Figure 4) displays how query and write latency varies over
time – making it simple to identify slower queries with Follow configuration best practices. Review the
common access patterns and characteristics, as well as MongoDB production notes for the latest guidance on
identify any latency spikes. A single click in the Ops packages, hardware, networking, and operating system
Manager UI activates the profiler, which then consolidates tuning.
and displays metrics from every node in a single screen.

MongoDB Atlas: Database as a

Service For MongoDB

An increasing number of companies are moving to the

public cloud to not only reduce the operational overhead of

11
managing infrastructure, but also provide their teams with • Live migration to move your self-managed MongoDB
access to on-demand services that give them the agility clusters into the Atlas service or to move Atlas clusters
they need to meet faster application development cycles. between cloud providers.
This move from building IT to consuming IT as a service is • Widespread coverage on the major cloud platforms with
well aligned with parallel organizational shifts including availability in over 50 cloud regions across Amazon Web
agile and DevOps methodologies and microservices Services, Microsoft Azure, and Google Cloud Platform.
architectures. Collectively these seismic shifts in IT help MongoDB Atlas delivers a consistent experience across
companies prioritize developer agility, productivity and time each of the cloud platforms, ensuring developers can
to market. deploy wherever they need to, without compromising
MongoDB offers the fully managed, on-demand and elastic critical functionality or risking lock-in.
MongoDB Atlas service, in the public cloud. Atlas enables MongoDB Atlas can be used for everything from a quick
customers to deploy, operate, and scale MongoDB Proof of Concept, to dev/test/QA environments, to
databases on AWS, Azure, or GCP in just a few clicks or powering production applications. The user experience
programmatic API calls. MongoDB Atlas is available across MongoDB Atlas, Cloud Manager, and Ops Manager
through a pay-as-you-go model and billed on an hourly is consistent, ensuring that you easily move from
basis. It’s easy to get started – use a simple GUI to select on-premises to the public cloud, and between providers as
the public cloud provider, region, instance size, and features your needs evolve.
you need. MongoDB Atlas provides:
Built and run by the same team that engineers the
• Automated database and infrastructure provisioning so database, MongoDB Atlas is the best way to run MongoDB
teams can get the database resources they need, when in the cloud. Learn more or deploy a free cluster now.
they need them, and can elastically scale whenever they
need to. This paper is aimed at people managing their own
MongoDB instances, performance best practices for
• Security features to protect your data, with network
MongoDB Atlas are described in a dedicated paper –
isolation, fine-grained access control, auditing, and
MongoDB Atlas Best Practices.
end-to-end encryption, enabling you to comply with
industry regulations such as HIPAA.

• Built in replication both within and across regions for MongoDB Stitch
always-on availability.
The MongoDB Stitch serverless platform facilitates
• Global clusters allows you to deploy a fully managed, application development with simple, secure access to data
globally distributed database that provides low latency, and services from the client – getting your apps to market
responsive reads and writes to users anywhere, with faster while reducing operational costs.
strong data placement controls for regulatory
compliance. Stitch represents the next stage in the industry's migration
to a more streamlined, managed infrastructure. Virtual
• Fully managed, continuous and consistent backups with
Machines running in public clouds (notably AWS EC2) led
point in time recovery to protect against data corruption,
the way, followed by hosted containers, and serverless
and the ability to query backups in-place without full
offerings such as AWS Lambda and Google Cloud
restores.
Functions. These still required backend developers to
• Fine-grained monitoring and customizable alerts for implement and manage access controls and REST APIs to
comprehensive performance visibility. provide access to microservices, public cloud services, and
• Automated patching and single-click upgrades for new of course data. Frontend developers were held back by
major versions of the database, enabling you to take needing to work with APIs that weren't suited to rich data
advantage of the latest and greatest MongoDB queries.
features.

12
The Stitch serverless platform addresses these challenges hourly billing model. With the click of a button, you can
by providing four services: scale up and down when you need to, with no downtime,
full security, and high performance.
• Stitc
Stitchh QueryAnywher
QueryAnywhere e. Brings MongoDB's rich query
language safely to the edge. An intuitive SDK provides MongoDB Stitch is a serverless platform which accelerates
full access to your MongoDB database from mobile and application development with simple, secure access to data
IoT devices. Authentication and declarative or and services from the client – getting your apps to market
programmable access rules empower you to control faster while reducing operational costs and effort.
precisely what data your users and devices can access.
MongoDB Mobile (Beta) MongoDB Mobile lets you store
• Stitc
StitchhFFunctions
unctions. Stitch's HTTP service and webhooks data where you need it, from IoT, iOS, and Android mobile
let you create secure APIs or integrate with devices to your backend – using a single database and
microservices and server-side logic. The same SDK that query language.
accesses your database, also connects you with popular
cloud services, enriching your apps with a single method MongoDB Cloud Manager is a cloud-based tool that helps
call. Your custom, hosted JavaScript functions bring you manage MongoDB on your own infrastructure. With
everything together. automated provisioning, fine-grained monitoring, and
continuous backups, you get a full management suite that
• Stitc
StitchhT
Triggers
riggers. Real-time notifications let your
reduces operational overhead, while maintaining full control
application functions react in response to database
over your databases.
changes, as they happen, without the need for wasteful,
laggy polling. MongoDB Consulting packages get you to production
• Stitc
Stitchh Mobile Sync (coming soon). Automatically faster, help you tune performance in production, help you
synchronizes data between documents held locally in scale, and free you up to focus on your next release.
MongoDB Mobile and your backend database, helping MongoDB Training helps you become a MongoDB expert,
resolve any conflicts – even after the mobile device has from design to operating mission-critical systems at scale.
been offline. Whether you're a developer, DBA, or architect, we can
Whether building a mobile, IoT, or web app from scratch, make you better at MongoDB.
adding a new feature to an existing app, safely exposing
your data to new users, or adding service integrations,
Stitch can take the place of your application server and
Resources
save you writing thousands of lines of boilerplate code.
For more information, please visit mongodb.com or contact
us at [email protected].
We Can Help
Case Studies (mongodb.com/customers)
Presentations (mongodb.com/presentations)
We are the MongoDB experts. Over 6,600 organizations Free Online Training (university.mongodb.com)
rely on our commercial products. We offer software and Webinars and Events (mongodb.com/events)
services to make your life easier: Documentation (docs.mongodb.com)
MongoDB Enterprise Advanced is the best way to run MongoDB Enterprise Download (mongodb.com/download)
MongoDB in your data center. It's a finely-tuned package MongoDB Atlas database as a service for MongoDB
of advanced software, support, certifications, and other (mongodb.com/cloud)
services designed for the way you do business. MongoDB Stitch backend as a service (mongodb.com/
cloud/stitch)
MongoDB Atlas is a database as a service for MongoDB,
letting you focus on apps instead of ops. With MongoDB
Atlas, you only pay for what you use with a convenient

13
US 866-237-8815 • INTL +1-650-440-4474 • [email protected]
© 2018 MongoDB, Inc. All rights reserved.

14