On this page
- Are there any charges for enabling and using Atlas Search?
- Can I run partial string matching Atlas Search queries?
- Can I perform case-insensitive search with the
storedSourcesupport case-insensitive collation on fields?
- Can I use the shard key to run Atlas Search queries on specific shards?
- Do queries run on primary or secondary nodes?
- Can I duplicate an index?
- Does Atlas Search store my entire index in memory?
- Why is my search index disappearing?
- Can I restore Atlas Search indexes from Cloud Backup snapshots?
- Does Atlas Search work with CSFLE encrypting clients?
- Can I query CSFLE encrypted data?
- Can I use Queryable Encryption with Atlas Search?
- Can I use Atlas Search on time series collections?
No, there are no additional fees or charges when you enable Atlas Search on your Atlas cluster. However, you might observe an increase in resource utilization on the cluster depending on factors such as the size of the indexed collections or index definitions. To manage and control Atlas Search resource utilization, you can deploy dedicated search nodes, which is an additive cost per node. We recommend this for your production environment.
Yes. The following Atlas Search operators support partial string matching queries:
Yes. You can use the wildcard and regex operators with a custom analyzer to perform a case-insensitive search. You can define a custom analyzer with the following tokenizer and token filter to perform a wildcard case-insensitive search:
Yes. The Atlas Search storedSource option stores
original values. To perform case-insensitive operations after the
$search stage on the results returned using
returnStoredSource option, you
must set the default collation strength of your collection to
2 when you create it, and must not specify a different collation in
your queries and indexes.
No, you can't use the shard key to run Atlas Search queries on a specific shard or a subset of shards. In a sharded cluster environment, Atlas Search queries are scatter-gather queries that run on all the shards.
However, if you use zones to distribute
a sharded collection over a subset of the shards in the cluster,
Atlas Search routes the query to the zone that contains the shards for the
collection that you are querying and runs your
queries on just the shards where the collection is located.
Yes, you can duplicate your index by performing the following:
Create a new index with the Atlas Search JSON Editor. Paste the index you copied and click Create Search Index. You can make any edits you want directly in the Atlas Search JSON Editor or Atlas Search Visual Index Builder after you create the Atlas Search index.
Work in Progress
We are currently working on a solution for this that doesn't require the steps mentioned above. If you'd like to vote for this feature, or submit your feedback, see this feedback item.
No, Atlas Search uses memory for the JVM heap metrics, which stores the autocomplete and text tokens of your search index. Similar to other database engines, Atlas Search stores the majority of the index files on the disk, which benefits from the underlying OS page cache.
Verify that you entered the correct database and collection names. If you enter a non-existent database or collection name, the Atlas UI temporarily builds the index and deletes it shortly after.
If you use the
$outaggregation stage to overwrite your collection, you must delete and recreate your search index, as search indexes aren't copied to destination collections. To learn more, see $out Index Constraints.
M10+ dedicated clusters running MongoDB 4.2 or higher,
Atlas will restore Atlas Search indexes
from a Cloud Backup snapshot.
Yes, you can use CSFLE encrypting clients to run Atlas Search queries against data in MongoDB version 6.0 and later.
No, you can't query CSFLE encrypted data using Atlas Search.
No, Queryable Encryption is incompatible with Atlas Search.
No, you can't use Atlas Search on time series collections.