130 results found

1. Dedicated search nodes

   Currently, Atlas Search (mongot) is collocated with Atlas (mongod) on the same database deployment. Today, I have to size their workload based on both search and database requirements, which introduces the possibility of resource contention between their database and search deployment. I'd like to scale my search deployment independently of my database deployment.

   12 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   started  ·  AdminElle (Admin, MongoDB) responded

   We have a private preview available for this feature. Please enroll in our early access program here ( https://www.mongodb.com/dasal ) if interested or reply to this update.

2. Allow sort by boolean fields

   When creating indexes and sorting with "normal" queries, it is possible to index/sort on a boolean field. I was hoping to do this with Atlas Search Sort as well, but it only supports date, number and token (string).

   While workarounds are available (using custom scoring), these are not easily combined with multiple sort fields and make programmatically building a query vastly more complex.

   See: https://support.mongodb.com/case/01169728

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   2 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. knnBeta Limitations and Syntax

   I tested the new knnBeta operator today and it worked so far.
   Can we expect the current operator limitations to be gone by release?
   The current limitations make it virtually impossible to use the knn operator as a replacement for previous text operators (like text).
   I would prefer the filter parameter to be omitted and knn not have to be a top-level operator.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   3 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. Allow aggregate pipeline on input documents before Atlas Search indexing

   If Altas Search allowed us to apply an aggregate pipeline to input documents before they are sent to Atlas Search for indexing, it would open up a TON of new possibilities not currently supported. We could do data transformations, type conversions, synthetic fields, etc.. I've opened up a number of other suggestions for these things, but an input aggregate pipeline could solve all of them in one "easy" solution. Since aggregate pipelines already exist and are deeply embedded in MongoDB, I'm hoping it would be trivial to implement as well. Simply pick up one or more new documents to be indexed, run them through the pipeline and then send them to the Atlas Search engine for indexing.

   Here's what that might look like:

   {
     "mappings": {
       "dynamic": false,
       "aggregate": [
         { <stage> },
         ...,
         {
           "$addFields": {
             "my-synthetic-field": <expression>
           }
         }
       ],
       "fields": {
         "my-synthetic-field": {
           "type": "string"
         }
       }
     }
   }
   

   Here are some of the other suggestions I (or others) have made that could be solved with this approach:

   https://feedback.mongodb.com/forums/924868-atlas-search/suggestions/47049898-allow-indexing-of-synthetic-fields
   https://feedback.mongodb.com/forums/924868-atlas-search/suggestions/47049757-data-type-coercion-when-document-field-type-doesn
   https://feedback.mongodb.com/forums/924868-atlas-search/suggestions/47049775-allow-sort-by-boolean-fields
   https://feedback.mongodb.com/forums/924868-atlas-search/suggestions/47049775-allow-sort-by-boolean-fields
   https://feedback.mongodb.com/forums/924868-atlas-search/suggestions/40734700-support-decimal128

   If Altas Search allowed us to apply an aggregate pipeline to input documents before they are sent to Atlas Search for indexing, it would open up a TON of new possibilities not currently supported. We could do data transformations, type conversions, synthetic fields, etc.. I've opened up a number of other suggestions for these things, but an input aggregate pipeline could solve all of them in one "easy" solution. Since aggregate pipelines already exist and are deeply embedded in MongoDB, I'm hoping it would be trivial to implement as well. Simply pick up one or more new documents to be… more

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. Sort by a specific array index

   When creating indexes and sorting with "normal" queries, it is possible to index/sort on a specific array index (e.g. foo.0.bar). I do this because the search results grid in our UI only has room to show the first foo.bar result, so it doesn't make sense visually to sort by additional objects which the user can't see.

   Since the new Atlas Search Sort syntax looks the same, I was hoping to do that with it as well, but it doesn't seem possible.

   Example:

   [
     { "xyzzy": "xyzzy",
       "foo": [ { "bar": "A" } ] },
   
     { "xyzzy": "xyzzy",
       "foo": [ { "bar": "B" }, { "bar": "D" } ] },
   
     { "xyzzy": "xyzzy",
       "foo": [ { "bar": "C" } ] }
   ]
   

   {
     index: "myindex",
     returnStoredSource: true,
     phrase: { path: "xyzzy", query: "xyzzy" },
     sort: { "foo.0.bar": -1 }
   }
   

   See: https://support.mongodb.com/case/01169701

   When creating indexes and sorting with "normal" queries, it is possible to index/sort on a specific array index (e.g. foo.0.bar). I do this because the search results grid in our UI only has room to show the first foo.bar result, so it doesn't make sense visually to sort by additional objects which the user can't see.

   Since the new Atlas Search Sort syntax looks the same, I was hoping to do that with it as well, but it doesn't seem possible.

   Example:

   [
     { "xyzzy": "xyzzy",
       "foo": [ { "bar": "A" } ] },
   
     { "xyzzy": "xyzzy",
       "foo": [

   … more
   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

6. Data type coercion when document field type doesn't match index field type

   When a document field type doesn't match the index field type, it seems to be indexed as "blank" and won't match anything. Many data types are readily convertible between type representations. It would be great if Atlas Search could do that for us and would open up richer functionality by allowing us to use operators/analyzers/etc. on types that don't normally support them.

   My particular use case is to allow searching & sorting on numbers stored as strings. When creating indexes and sorting with "normal" queries, it is possible to sort numbers stored as strings by their numerical ordering rather than alphabetical by using { collation: { locale: "en_US", numericOrdering: true } } on the index definition and applying query.collation(Collation.of(Locale.US).numericOrdering(true)) to the query itself. I was hoping to do this with Atlas Search Sort as well, but it isn't possible.

   Examples:
   string "1000.00" = number 1000.00
   boolean true = number 1
   boolean true = string "true"
   etc.

   See: https://support.mongodb.com/case/01169737

   When a document field type doesn't match the index field type, it seems to be indexed as "blank" and won't match anything. Many data types are readily convertible between type representations. It would be great if Atlas Search could do that for us and would open up richer functionality by allowing us to use operators/analyzers/etc. on types that don't normally support them.

   My particular use case is to allow searching & sorting on numbers stored as strings. When creating indexes and sorting with "normal" queries, it is possible to sort numbers stored as strings by their numerical ordering rather than… more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   2 comments  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

7. Mutli-select faceting

   I want to build multi-select facet without having to run separate queries to calculate bucket counts for each active filter. Described in detail here: https://yonik.com/multi-select-faceting/

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

8. Allow indexing of synthetic fields

   In order to work around some of the inherent limitations of the Atlas Search capabilities, it would be very useful if we could define and index arbitrary synthetic fields using any normal MongoDB functions & operators. All other Atlas Search capabilities (query, sort, etc.) should support these synthetic fields the same as any other.

   This could possibly be implemented with a new field type and a custom analyzer that supports an aggregate pipeline on the input document and returning the field as its output. This is just an idea, there may be better ways to do it.

   {
     "mappings": {
       "dynamic": false,
       "fields": {
         "foobar": {
           "type": "synthetic",
           "analyzer": "my-aggregate-analyzer"
         }
       }
     },
     "analyzers": [
       {
         "name": "my-aggregate-analyzer",
         "aggregate": [
           { <stage> }, 
           ...
         ]
       }
     ]
   }
   

   In order to work around some of the inherent limitations of the Atlas Search capabilities, it would be very useful if we could define and index arbitrary synthetic fields using any normal MongoDB functions & operators. All other Atlas Search capabilities (query, sort, etc.) should support these synthetic fields the same as any other.

   This could possibly be implemented with a new field type and a custom analyzer that supports an aggregate pipeline on the input document and returning the field as its output. This is just an idea, there may be better ways to do it.

   {
     "mappings": {

   … more
   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

9. Additional function scores decay functions: exp & linear

   Atlas Search currently only supports gaussian decay function for function scores. In 4 out of 5 of our use cases exp would be a much more natural choice.

   https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-function-score-query.html#function-decay

   Hopefully that is just a small task!

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

10. Support sorting by the search relevance when custom sorting search results.

    Our search index is mostly data, so we get a lot of documents with identical search relevance. We would like to use the newly announced sort feature, but we need to retain the sort relevance (score) as the primary sort criterion. We want to additionally specify reverse chronological order as the secondary criterion. Adding the missing ability to also sort by the score would solve our need.

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

11. Allow comments in JSON code

    It would be great if we could keep comments in JSON generated items such as indexes (both MongoDB and Atlas Search)

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

12. Allow indexing of only part of a collection

    Would be great to be able to create an Atlas Search index that only indexes part of a collection (like partialFilterExpression for a regular index). This would be valuable in situations where a collection is quite large (which would create a lot of unnecessary overhead) but only a small fraction of it needs to be searchable.

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

13. Ruby on Rails support of Atlas Search index management

    Feedback from customer: "Currently we need to manage core DB indexes and atlas search indexes separately. We'd prefer to manage them all in the Rails model code but MongoID only supports core DB index configuration. We're having to use terraform for atlas search index management."

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

14. Token filter that removes duplicated entries

    Create a token filter or a tokenizer or even an option that removes duplicate words in fields  to avoid misleading scoring. 
    For example: if I insert a document with a property "Testing testing document", another with "Testing example" and a third with "Testing foo" and I search for "Testing foo", the first document receives a higher score.
    

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

15. Multiple Capture Groups in RegEx Tokenizer

    Currently the RegEx tokenizer only supports to either create a token from each match or for one capture group per match. This makes it impossible to reuse parts of the text for multiple tokens, for example when you want to tokenize "13.3" into "13" as well as "13.3" (our use case is searching products where we want to find a 13.3" device by searching for 13" as well as 13.3").

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

16. wildcard paths in index specifications

    It would make index specification easier in some cases if wildcards were possible in the paths. Yes we have dynamic indexing, but to keep the index size minimal and to be more flexible I want to index only the fields I really need. Consider the following example:

    Example document:

    {
    foo: {
    de: {
    field1: 'bar',
    field2: 'bar'
    },
    en: {
    field1: 'bar',
    field2: 'bar'
    },
    fr: {
    field1: 'bar',
    field2: 'bar'
    },
    }
    }

    Index specification:

    {
    "mappings": {
    "dynamic": false,
    "fields": {
    "foo": {
    "type": "document",
    "dynamic": false,
    "fields": {
    "$**": {
    "type": "document",
    "dynamic": false,
    "fields": {
    "field1": {
    "type": "string"
    }
    }
    }
    }
    }
    }
    }
    }

    This index would then index field1 in the object foo.*, where * stands for any field. So in this example foo.DE, foo.EN, foo.FR.

    This extension would help when you want to index nested objects where the field names of a layer are unknown or strongly dynamic, but dynamic: true would have too many unwanted side effects.

    It would make index specification easier in some cases if wildcards were possible in the paths. Yes we have dynamic indexing, but to keep the index size minimal and to be more flexible I want to index only the fields I really need. Consider the following example:

    Example document:

    {
    foo: {
    de: {
    field1: 'bar',
    field2: 'bar'
    },
    en: {
    field1: 'bar',
    field2: 'bar'
    },
    fr: {
    field1: 'bar',
    field2: 'bar'
    },
    }
    }

    Index specification:

    {
    "mappings": {
    "dynamic": false,
    "fields": {
    "foo": {
    "type": "document",
    "dynamic": false,
    "fields": {
    "$**": {
    "type": "document",
    "dynamic": false,
    "fields": {… more

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

17. Add storedSource parameter to atlas admin API search index create/update to use with terraform

    Right now it is impossible to create atlas search index via terraform with "storedSource" parameter. This brings a lot of inconvenience and configuration-related bugs.

    Related issue

    https://github.com/mongodb/terraform-provider-mongodbatlas/issues/871

    9 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

18. Ability to randomize score

    I would like to be able to add randomness to the search results' score.

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

19. Allow faceting on boolean fields

    Right now you can only facet on string, number, date fields.
    https://www.mongodb.com/docs/atlas/atlas-search/facet/#facet-definition

    I would like to also be able to facet on boolean fields.

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

20. Ability to return all documents in a collection

    I need to return all documents in a collection while boosting certain results which match my search criteria.

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close