Docs Menu
Docs Home
/
MongoDB Atlas
/ /

Atlas Search Query Performance

On this page

  • Consider Query Operators and Query Complexity
  • Use $search Instead of $text or $regex
  • Use $limit Before $facet
  • Avoid $match After $search
  • Avoid $group After $search
  • Avoid $count After $search
  • Avoid $sort After $search
  • Limit Use of $skip and $limit After $search
  • Monitor Performance
  • Continue Learning

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) or the wildcard operator.

If your query includes multiple nested compound statements, ensure that these are not redundant. If the clauses are added programmatically, consider implementing the logic in the application to avoid inclusion of redundant clauses in the queries. Every score calculation per field that mongot performs, such as for the must and should clauses, increases execution time.

You can use the Atlas Search facet collector to extract metadata and avoid running multiple queries for search results and metadata. For an example, see the Metadata and Search Results example.

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.

For applications that rely heavily on MongoDB $text and $regex queries, use the following recommendations to determine whether to refactor your applications or migrate your applications to Atlas Search $search. The $search aggregation pipeline stage provides features that are either not available through the MongoDB operators or are available through the MongoDB operators but not as performant as Atlas Search $search.

The following table shows how MongoDB $regex, $text, and Atlas Search $search address your application's requirements.

If your application requires...
Use...
Because...

Datastore to respect write concerns

For transactions with heavy reads after writes, we recommend $regex. For $search, reads after writes should be rare.

Cluster optimized for write performance

Atlas Search indexes don't degrade cluster write performance.

Searching through large data sets

Atlas Search uses an inverted index, which enables fast document retrieval at very large scales.

Language awareness

Atlas Search supports many language analyzers that can tokenize (create searchable terms) languages, remove stopwords, and interpret diacritics for improved search relevance. To learn more, see How to Run Multilingual Atlas Search Queries.

Case-insensitive text search

$search offers more capabilities than $regex.

Highlighting result text

Atlas Search highlighting allows you to contextualize the documents in the results, which is essential for natural language queries.

Geospatial-aware search queries

MongoDB $regex and Atlas Search $search treat geospatial parameters differently. In MongoDB, lines between coordinates are spherical, which is well-suited for coordinates for long distance such as air flight. Atlas Search uses Lucene, which draws a straight line between coordinates and is well-suited for short distance. To learn more, see How to Run an Atlas Search Compound Geo JSON Query.

On-premises or local deployment

Atlas Search is unavailable for on-premise or local deployment. Atlas Search is only available for data on the Atlas cluster.

Autocompletion of search queries

For autocomplete of characters (nGrams), Atlas Search includes edgeGrams for left-to-right autocomplete, nGrams for autocomplete of languages that don't have whitespace, and rightEdgeGram for autocomplete of languages that you write and read right-to-left.

For autocomplete of words (wordGrams), Atlas Search includes shingle token filter, which supports word-based autocomplete by concatenating adjacent words to create a single token.

To learn more, see the How to Use Autocomplete with Atlas Search tutorial.

Fuzzy matching on text input

Atlas Search text and autocomplete operators support fuzzy matching to filter on input text and address misspelled words (typos).

Filtering based on multiple strings

Atlas Search compound supports filtering based on multiple strings.

Relevance score sorted search

Atlas Search uses the BM25 algorithm for determining the search relevance score of documents. It supports advanced configuration through boost expressions like multiply and gaussian decay, as well as analyzers, search operators, and synonyms. To learn more, see How to Run Atlas Search Compound Queries with Weighted Fields.

Partial indexes

Atlas Search doesn't support partial indexing.

Patial match

Atlas Search wildcard and autocomplete operators support partial match queries. To learn more, see How to Run Partial Match Atlas Search Queries.

Single compound index on arrays

Atlas Search term indexes are intersected in a single Atlas Search index and eliminate the need for compound indexes for filtering on arrays.

Synonyms search

Atlas Search supports synonyms defined in a separate collection, which you can reference in your search index for use. To learn more, see the How to Use Synonyms with Atlas Search tutorial.

Faceting for counts

Atlas Search provides fast counts of documents based on text criteria, and also supports faceted search for numbers and dates. To learn more, see How to Use Facets with Atlas Search.

Extract metadata

Atlas Search facet collector returns metadata and doesn't require you to run multiple queries for retrieving metadata. To learn more, see the How to Use Facets with Atlas Search tutorial.

Custom analyzers

Atlas Search supports custom analyzers to suit your specific indexing requirements. For example, you can index and search email addresses and HTTP or HTTPS URLs using custom analyzers. To learn more, see How to Define a Custom Analyzer and Run an Atlas Search Diacritic-Insensitive Query.

Searching phrases or multiple words

Atlas Search phrase operator supports searching for a sequence of terms.

Searching with regular expression

Atlas Search provides improved performance when you use the Atlas Search autocomplete operator instead.

Tip

See also:

Using a $limit aggregation pipeline stage after a $facet aggregation pipeline stage might negatively impact query performance. To avoid performance bottlenecks, use $limit before $facet.

Example

{
{
"$search": {...}
},
{ "$limit": 20 },
{
"$facet": {
"results": [],
"totalCount": $$SEARCH_META
}
}
}

For a demonstration, see the following examples:

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 Atlas Search compound operator helps with queries that require multiple filtering operations. If you must use the $match stage in your aggregation pipeline, consider using the storedSource option to store only the fields that your $match condition needs. You can then use the returnStoredSource option to retrieve stored fields.

Using a $group aggregation pipeline stage after a $search stage can slow down query results. If you use $group to get basic counts for field aggregations, we recommend that you use facet inside the $searchMeta stage instead.

Using a $count aggregation pipeline stage after a $search stage can slow down query results. If you use $count to get a count of the number of documents, we recommend that you use count inside the $search or $searchMeta stage instead.

Using a $sort aggregation pipeline stage after a $search stage can drastically slow down query results.

Using $skip and $limit to retrieve results non-sequentially might be slow if the results for your query are large. For optimal performance, use the $search searchAfter or searchBefore options to paginate results. To learn more, see Paginate the Results.

To return non-sequential results, such as jumping from page 2 to page 5, you can use the following pipeline stages:

  • $search searchAfter the last result on Page 2

  • $skip documents on Pages 3 and 4

  • $limit results for Page 5

Here, your query is optimized to skip only 2 pages of results, instead of skipping 4 pages if you didn't use searchAfter. For a demonstration of this, see How to Paginate the Query Results.

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. To learn more, see Review Atlas Search Metrics.

Atlas might trigger some Atlas alerts when:

  • Atlas Search queries your clusters, which can impact Atlas performance metrics, such as the query targeting metrics.

    The change streams cursors that the Atlas Search process (mongot) uses to keep Atlas Search indexes updated can contribute to the query targeting ratio and trigger query targeting alerts if the ratio is high.

  • Atlas Search replicates data from MongoDB, which contributes to the metrics measured in Atlas, such as the number of getmore operations.

Note

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.

Follow along with this video to learn how to understand, iterate, and improve your Atlas Search results using explain and $search score details.

Duration: 5 Minutes

Back

Indexes