Performance Considerations¶
On this page
- Atlas Search Upgrade
- Index Size and Configuration
- Creating and Updating an Atlas Search Index
- Scaling Up Indexing Performance
- Eventual Consistency and Indexing Latency
- Document Mapping Explosions
- Query Operators and Query Complexity
- Performance Monitoring
$match
Aggregation Stage Usage$sort
Aggregation Stage Usage
Atlas Search runs a new process, called mongot
, alongside
the mongod
process on each host in your
Atlas cluster. mongot
maintains all
Atlas Search indexes on collections in your Atlas databases.
The amount of CPU, memory, and disk resources mongot
consumes
depends on several factors, including your index configuration
and the complexity of your queries. Atlas Search alerts measure the amount of CPU and memory
used by Atlas Search processes.
Atlas Search Upgrade¶
Atlas Search is deployed on your Atlas cluster. When a new version of Atlas Search is deployed, your Atlas cluster might experience brief network failures in returning query results. To mitigate issues during deployment and minimize impact to your application, consider the following:
- Implement retry logic in your application.
- Configure Atlas maintenance windows.
To learn more about the changes in each release, see Atlas Search Changelog.
Index Size and Configuration¶
If you create an Atlas Search index for a collection that has or will soon have more than two billion documents, you must shard your cluster.
When you create an Atlas Search index, the default configuration sets field mapping to dynamic, which means that all the data in your collection is actively added to your Atlas Search index. Other options such as enabling highlights can also result in your index taking up more disk space. You can reduce the size and performance footprint of your Atlas Search index by:
- Specifying a custom index definition to narrow the amount and type of data that is indexed.
- Setting the
store
option tofalse
when specifying a string type in an index definition.
Some limitations apply to Atlas Search on M0
, M2
, and M5
clusters only. To learn more, see
Atlas Search Free and Shared Tier Limitations.
Considerations¶
Some index configuration options can lead to indexes that take up a significant proportion of your disk space. In some cases, your index could be many times larger than the size of your data. Although this is expected behavior, it's important to be aware of the following indexing-intensive features:
Autocomplete¶
The autocomplete Atlas Search field type can cause large indexes, especially in the following cases:
- Using
nGram
tokenization. - Setting a wide
minGrams
tomaxGrams
range. - Setting a
minGram
value of1
on a collection with millions of documents.
multi
Analyzers¶
Using a multi
analyzer to analyze the same field multiple
different ways can cause large indexes, especially when analyzing
fields with very long values.
Synonym Collections¶
A large synonyms source collection can cause large indexes.
Creating and Updating an Atlas Search Index¶
Creating an Atlas Search index is resource-intensive. The performance of your Atlas cluster may be impacted while the index builds.
Atlas replicates all writes on the collection. This means that for each collection with Atlas Search indexes, the writes are amplified to the amount of Atlas Search indexes defined for that collection.
In some instances, your Atlas Search index must be rebuilt. Rebuilding the Atlas Search index also consumes resources and may affect database performance. Atlas Search automatically rebuilds the index only in the event of:
- Changes to the index definition
- Atlas Search version updates that include breaking changes
- Hardware-related problems such as index corruption
Atlas Search supports no-downtime indexing, which means you can continue to read and write to your cluster while your index is being rebuilt. Atlas Search keeps your old index up-to-date while the new index is being built. Once Atlas Search rebuilds the index, the old index is automatically replaced without any further action from your side.
Scaling Up Indexing Performance¶
You can scale up your initial sync and steady state indexing for an Atlas Search index by upgrading your cluster to a higher tier with more cores. Atlas Search uses a percentage of all available cores to run both initial sync and steady state indexing and performance improves as new cores are made available by upgrading your cluster.
Eventual Consistency and Indexing Latency¶
Atlas Search supports eventual consistency and does not provide any stronger
consistency guarantees. This means that data inserted into a MongoDB
collection and indexed by Atlas Search will not be available immediately for
$search
queries.
Atlas Search reads data from MongoDB change streams and indexes that data in an asynchronous process. This process is typically very fast, but may sometimes be impacted by replication latency, system resource availability, and index definition complexity.
Document Mapping Explosions¶
Mapping explosions
occur when Atlas Search indexes a document with arbitrary
keys and you have a dynamic mapping. The
mongot
process might consume increasing amounts of memory and could
crash. If you add too many fields to an index, mapping explosions can
occur. To address this issue, you can upgrade your cluster or use a
static mapping that does not index all
fields in your data.
Query Operators and Query Complexity¶
The complexity level of Atlas Search queries and the type of operators used can affect database performance. Highly complex queries with multiple clauses are resource-intensive, as are queries which use the regex (regular expression) operator.
Atlas Search queries are ranked by score. Queries that return a large number of results are more computationally intensive because they must keep track of all the scores for the result set.
Performance Monitoring¶
You can monitor your Atlas cluster and view charts with performance statistics on the Atlas Metrics tab. These metrics can help you see how Atlas Search queries and index building affect your cluster's performance.
If your cluster's resources are stretched or near the limits of acceptable performance, consider upgrading to a larger cluster tier before implementing Atlas Search functionality.
$match
Aggregation Stage Usage¶
Using a $match
aggregation pipeline stage after a $search
stage can drastically slow down query results. If possible, design
your $search
query so that all necessary filtering occurs in the
$search
stage to remove the need for a $match
stage. The
$compound Atlas Search operator is helpful for queries
that require multiple filtering operations.
$sort
Aggregation Stage Usage¶
Using a $sort
aggregation pipeline stage after a $search
stage can drastically slow down query results. If possible, design
your $search
query so that all necessary sorting occurs in the
$search
stage to remove the need for a $sort
stage. In
general, the Atlas Search $compound operator is helpful
for queries that require multiple sorting operations. To sort
documents based on a numeric, date, or geo field, consider using
the Atlas Search $near operator.