Atlas Search
149 results found
-
geoWithin metadata reporting searchDistance
Using geoWithin in the $search aggregation pipeline lets me use the search indexes, but it doesn't let me see the distance. I'd love to have a distanceField or perhaps a $meta that reports searchDistance similar to the one we have for searchScore
18 votes -
Support Chinese Language Analyzer : Pinyin
PinYin IKAnalyzer Support
For most Chinese Speaking Customer,
https://github.com/medcl/elasticsearch-analysis-pinyin
Is also a popular analyzer that many of our customer is using it
2 votes -
Extending Range operator support to ObjectId values
If the Range operator supports ObjectId, it'll be really useful for the application that sorts or paginates data using _id, since _id is sorted by default.
2 votes -
Support min-max computation for number and date fields, within Atlas Search
Currently, the
$min
and$max
aggregation operators can be used in a number of aggregation pipeline stages, in order to find min/max values for fields. It would be great if either these operators were supported within$search
, or if there was a way to compute the min-max values for number and date fields within Atlas Search itself. There are certain use-cases where such a functionality can prove useful.For instance, we can leverage the
$near
operator to get sorted results, and determine the sort order of the results based on theorigin
. However, many times, the min-max values…6 votes -
Allow faceting on decimal fields
I'd like to create a facet on a Price field stored as a decimal in my MongoDB documents. However, this doesn't give me the results I expect. I'm required to set the "boundaries" property on the facet to an array of integer or double values. However, when the facets are returned, they are all thrown into the "default" bucket.
For example, if I were to declare the facet like this:
facets: { price: { type: "number", path: "ProductPrice", // using plain integer boundaries 0,10,20,30 also fails boundaries: [ 0, 5.00, 10.00, 15.00, 20.00, 25.00, 30.00 ], default: "other", }, },
…
7 votes -
nested facets
in elastic we can do complex nested facet groups such as
"aggs": {
"resellers": {
"nested": {
"path": "resellers"
},
"aggs": {
"min_price": {
"min": {
"field": "resellers.price"
}
}
}
}
}It would be nice to see the same functionality in atlas search
2 votes -
Pre-Compiled Synonyms Collections
There are many instances where the synonym-related needs of users are similar. For instance, in the case of names, Robert, Rob, and Bob are considered synonymous for some use cases.
2 votes -
atlas search null
A string or number data type that has the value 'null' is returned and is not excluded even with filtering with query: 'null' entry. The $exists and $compound operators may benefit from excluding fields that have a value of 'null' but not exactly non-existent in a document.
2 votes -
Allow scoring with real word frequency (instead of word frequency per shard)
We are migrating from ES and there is an option when having a few documents to do a first query to return the term frequencies for all shards and then do the normal query using these frequencies to calculate the score.
The option is called "?searchtype=dfsquerythenfetch" and it's documented here: https://www.elastic.co/guide/en/elasticsearch/guide/current/relevance-is-broken.html.
It would be great to have a similar option in Atlas Search! Thank you
2 votes -
Support for fuzzy search and synonyms
it is just possible to either, use synonms, or fuzzy search. Would be great to have both options in one search query
4 votes -
enable $and operator for multiple words in a search term (not only $or)
It seems a commonly needed ability to decrease the amount of results from a multi-word search query instead of expanding it, since the default operator for every word is $or. If there could be a built-in $and option it will be great. Thank you.
3 votes -
Use case driven search operators and index types
Examples: phone numbers, addresses, websites, emails
If this would be helpful for you, please comment the data type you are looking for
6 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.
27 votes -
Index Templates
I'd like the ability to apply index templates or field level mappings for my indexes
5 votes -
Introduce the ability to "forecast the Atlas Search index-size" in advance, before starting the index build
Currently, prior to building an Atlas Search index, there is no way for users to know how large that index can get. Knowing the projected-index-size in advance can especially be helpful for users who might need to build index on a large collection, and where building such an index can push the disk-utilization to the max.
Therefore, this is a feature request to implement a way to "forecast the Atlas Search index-size" in advance, before starting the index build.
5 votes -
Configure Alert "Insufficient disk space to support rebuilding search indexes" via API
Currently, it's not possible to configure the alert "Insufficient disk space to support rebuilding search indexes" via API (and therefor also not by terraform).
When setting the respective eventTypeName "HOSTDISKSPACEINSUFFICIENTFORSEARCHINDEX_REBUILD"
I get the following response:
400
request "INVALIDENUMVALUE"
An invalid enumeration value HOSTDISKSPACEINSUFFICIENTFORSEARCHINDEX_REBUILD was specified.The API should support this (and any other alerts configurable by the UI).
2 votes -
Ability to set a "minimum should match" in a query
I can specify a percent of terms I want to match, for instance 100% means require all terms, 66% means, only return documents that matched at least 60% of the terms. (the default is 1 term)
Ex for 100%
search "foo bar"
"foo bar" "bar foo" "bar hello foo" would all return
"foo hello" would not
4 votes -
Display indexID in the UI
Just like the project ID is displayed on the Project Settings page, please display the index ID somewhere in the UI, so that we know what indexID to put when using the Atlas Search API endpoints (they require indexIDs but the UI displays only index names). That would make management and maintenance much simpler.
Unless I'm mistaken, the only way to know the indexID of an index I see in my UI is to make programmatic calls to some other API endpoints.
1 vote -
Allow $match syntax in $search queries
Currently, I am re-writing my queries that were previously using $match + $text queries using $search + compound. Firstly, this is a fair bit of work depending on the number of match clauses etc. Secondly, not all the operators that $match supports are supported inside $search/compound clauses causing product differences.
Anything that would speed up migrating $match queries to use $search while maintaining query results would help take advantage of the $search capabilities without having to rework the entire query logic.
As a side note, I'm aware that $match can follow a $search stage, but unfortunately this is really not…
7 votes -
Provide a button to cancel in-progress index builds
Currently, the only option for cancelling an in-progress index build is to delete the index using the "Delete Index" menu-item in the Search Tab, or by using the Delete an Atlas Search Index API. This however is not easily evident, if users want to cancel an index build for any reason.
Therefore, this is a feature request to provide a button to "cancel" in-progress index builds from the Atlas UI.
4 votes
- Don't see your idea?