Atlas Search
-
Allow the ability to test Atlas Search locally
We need text search to "somehow" work locally and ci.
We've a multiregional team and development has to continue if there are internet problems in one of our offices.
Our workflow consists of :
unitTest using in-memory-mongodb
local testing, using the developers local mongo instance
test env testing with a QA team (using atlas, but <30m)
production launch
With the current feature set, the first time we can test a feature is on production. Even if low-tier availability was there the other two issues are blockers as we won't just ditch TDD for textSearch.
165 votes -
Allow $count and $sort inside $search
Make $count and $sort directly with mongot, and dont lose time between mongot and mongodb.
96 votesHi all,
We’ve started to implement a lightning fast count operator inside of the $search stage and it will come soon. Sort will come a bit later than that, but optimizations around the communication between mongot and mongod should also speed sort up quite a bit. I’ll update the group as both are released to help you stay informed. If you have any questions or want to join me to discuss the syntax let me know.
-
Allow $search to be a later stage in the aggregation pipeline
Currently $search is required to be the first stage in the aggregation pipeline. It would be more intuitive if we could use after other operators, such as $match.
45 votes -
Allow autocomplete search on multiple fields using a wildcard path or by specifying multiple fields in the path
Currently, (unlike the text operator) the autocomplete operator does not accept a path which is an array of field names. Also, a wildcard path ("path": {"wildcard": "*"}) cannot be specified for an autocomplete query. Therefore, the only way to perform an autocomplete search on multiple fields is by using the compound operator.
This is a feature request to allow autocomplete search on multiple fields by using a wildcard path or by accepting an array of multiple fields in the path.
43 votesWe’ve heard your feedback loud and clear. We are starting this work now.
Thanks for the feedback. We will update you when it is released very soon. Let us know if you have any questions. :-)
-
Perform a search over multiple collections
Right now you can only search over one collection. I'd like to be able to search over several collections at the same time.
42 votesWe are looking to get feedback from our customers about this feature to understand your use cases and your needs. If you would like to chat with the product managers for Atlas Search about your cross-collection use case, please let us know.
We have planned the first version of this feature for next quarter. More details coming soon. :)
-
Faster Faceting
Current faceting solution is not fast enough for search use cases for larger datasets.
32 votesAtlas Search facet and count are in preview. The features and the corresponding documentation may change at any time in the preview stage.
The Atlas Search $searchMeta stage is not available on shared clusters. $searchMeta is available only on dedicated clusters.
facet is only available on Atlas clusters running one of the following versions:
- MongoDB 4.4.11 or later
- MongoDB 5.0.4 or later
You can't run facet queries with Explain.
This ticket will be marked as complete when Facet is available on Sharded clusters.
-
Be able to create Search indexes from Mongo shell
Right now it seems like I can query indexes from the mongo shell but not create them, unless I am missing something in the docs?
27 votes -
Support for nested datatype search
It appears that Atlas Search does not yet support nested datatype like ElasticSearch does:
https://www.elastic.co/guide/en/elasticsearch/reference/current/nested.html
We need this for our application
26 votesWe have started this work. Please stay tuned for an announcement about its completion.
-
Faster Pagination
I would like be able to paginate through search results faster.
21 votes -
Allow managing Atlas Search index via drivers
Currently I need to manage my indexes via the Atlas Search API but I would like to manage them using drivers in the same way that I manage all of my other MongoDB indexes.
20 votes -
I need to be able to search for dates and numbers in arrays
I have sets of results which contain dates and I need to be able to search from within them. For example:
{ experience: [ { name: "Abc", startDate: ISODate("2019-01-01T00:00:00.000Z"), startDate: ISODate("2020-01-01T00:00:00.000Z") }, { name: "Xyz", startDate: ISODate("2018-01-01T00:00:00.000Z"), startDate: ISODate("2019-01-01T00:00:00.000Z") } ] }So I need to be able to do a
nearsearch acrossexperience.startDatevalues, for example.The Date mapping documentation (https://docs.atlas.mongodb.com/reference/atlas-search/index-definitions/#date) says:
A date cannot be indexed if it is part of an array.
And while the number documentation doesn't mention the same restriction by experimentation I have found it has the same resriction (strings dont…
20 votesWe are working on this feature. Stay tuned for its release.
-
Support Partial Indexing
We have a large collection but would only like to index the most recent entries, which would reduce the amount of space and resources it would take to index and query.
18 votes -
The equals operator should support numeric datatypes
Currently, for querying on "number" datatypes, we can only use "range" or "near" operators. The "equals" operator supports querying only "boolean" and "objectId" values, and not numeric values.
If we want to do equality based matching for number datatypes, then we can leverage "range" using "gt" and "lt" to find it. However this might be sub-optimal in some cases (such as when performing equality match on decimals).
Therefore, this is a feature request for having equals operator support numeric datatypes (in addition to boolean and objectId).
17 votes -
Target $search queries to specific shards
Currently, sharded $search queries are scatter-gather queries and they cannot be targeted to specific shards. This is an enhancement request to target $search queries to specific shards, and thereby make them more efficient/performant.
16 votes -
Allow Atlas Search indexes to be restored across clusters
Currently, when an Atlas backup snapshot from one environment is restored to another environment, it does not transfer or replicate the Atlas Search indexes from the source cluster to the destination cluster. As a result, after the snapshot is restored, the Atlas Search indexes have to be manually created on the collections in the destination cluster.
This is a request for a functionality that will allow a snapshot-restore from one cluster to another to also replicate the Atlas Search indexes from the source cluster to the destination cluster.
13 votes -
Allow indexing and querying for null datatype in Atlas Search
The null datatype is not amongst the datatypes that Atlas Search supports at this time. As a result, if the use-case is to perform a text search on some fields and perform an equality/inequality check on other field(s) to see if it is/isn't null, then we need to have a $match stage following the $search stage, which is detrimental to the query performance as documented here. This is an enhancement request to allow indexing and querying for null datatype in Atlas Search, to avoid the above scenario.
12 votes -
Metric for Displaying Search Index Consistency Lag
I would like a metric that shows me what the latency is between the state of the MongoDB collection and the Search index in Atlas.
The difference between the optime of the collection and the optime of the Search index would be the latency. Please consider exposing this metric.
12 votesWe heard you loud and clear! This work has been started, though it is not so simple. I will update the group when it is complete and share a bit of instructions on how to interpret the metrics in case anything is unclear. Thank you all for being so vocal about the future of your product.
Please don’t hesitate with any questions. Keep in mind, the search index should be largely up to date with the database as we are really close by. :-)
-
Allow autocomplete to work with email addresses.
At the moment, an autocomplete index does not tokenize the "@" in email addresses. So when using an autocomplete search on an email address field, the search breaks as soon as the "@" is entered.
I started a thread in the community about this very issue.
https://developer.mongodb.com/community/forums/t/mongo-search-autocomplete-type/10561/5
11 votesThis work has started and I will inform the team when this feature is released. It’s coming soon.
-
Support highlighting with autocomplete operator
Currently, highlighting is supported only with search, term, compound, and span operators, and this is documented in the highlighting documentation. Therefore, if highlighting is used with the autocomplete operator, then it results in an error like this:
"Highlights can not be generated. Path: "####" is not stored statically or dynamically indexed."
This is a feature request to add support for highlighting with the autocomplete operator.
10 votes -
Add support for UUID datatypes in Atlas Search
Currently, UUID is not one of the supported datatypes for Atlas Search. This is a feature request to add support for UUID datatypes in Atlas Search.
9 votes
- Don't see your idea?