34 results found

1. Create operators that support Centrality Algorithms use cases

   Degree Centrality
   Closeness Centrality
   Harmonic Centrality
   Betweenness Centrality
   Eigenvector Centrality
   PageRank
   ArticleRank

   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  ·  Query and Aggregation Pipeline  ·  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

2. `$getField` to work with a dynamic `field`

   Currently $getField works only when field resolves at query-compile-time to a string. It would be nice if it worked also when field resolves to a string at runtime.

   See this Jira ticket - https://jira.mongodb.org/browse/SERVER-67030

   4 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  ·  Query and Aggregation Pipeline  ·  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. Add a $sample accumulator operator

   So that it's easier to sample a number of items from each group, instead of writing lengthy DSL like this:

   https://www.mongodb.com/community/forums/t/sample-x-number-of-documents-in-each-group-with-or-after-a-group-stage/170787

   Ideally it can be expressed like this:

   
{
$group: {
_id: '$year',
samples: { $sample: 100 },
}
}


   Hence making sampling 100 items from each group a snap to achieve!

   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  ·  Query and Aggregation Pipeline  ·  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

4. kNN Searches with MongoDB

   Dear MongoDB team,
   The possibility for kNN searches within a collection would be a real game changer. Not only in machine learning, but also in other areas you need this query method to find similar structures.
   Practically, it could go in the same direction as text searches. So that you have to create an index that you can also query similarly and then sort according to the score.

   I speak from my own suffering, as I had to switch from MongoDB to Open-/Elasticsearch for my current project, as they are also non-relational databases but support kNN searches. However, I like your product much more, which is why I would switch directly as soon as you also support this.

   I hope this idea finds a quick implementation - Have a good day (:
   Christopher K

   Dear MongoDB team,
   The possibility for kNN searches within a collection would be a real game changer. Not only in machine learning, but also in other areas you need this query method to find similar structures.
   Practically, it could go in the same direction as text searches. So that you have to create an index that you can also query similarly and then sort according to the score.

   I speak from my own suffering, as I had to switch from MongoDB to Open-/Elasticsearch for my current project, as they are also non-relational databases but support kNN searches. However, I like… 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  ·  Query and Aggregation Pipeline  ·  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

5. Support expressions in $densify range bounds

   The $densify aggregation pipeline stage seems unable to evaluate range bounds expressions, requiring the range bounds to be constant.

   See the following example (the collection testcoll contains a single documents with only the _id field):

   sometestdb> db.testcoll.aggregate([{$addFields: {a: 1}}, {$densify: {field: "a", range: {bounds: [0, 5], step: 1}}}])
   
   [
   
     { a: 0 },
   
     { _id: ObjectId("6284a16d64553eaf74b1e189"), a: 1 },
   
     { a: 2 },
   
     { a: 3 },
   
     { a: 4 }
   
   ]
   
   
   
   sometestdb> db.testcoll.aggregate([{$addFields: {a: 1}}, {$densify: {field: "a", range: {bounds: [{$toInt: "0"}, 5], step: 1}}}])
   
   MongoServerError: A bounding array must be an ascending array of either two dates or two numbers
   

   The first aggregate() call gives the correct result, and I'd expect the second one to evaluate the $toInt and yield the same result. Of course $toInt isn't a particularly useful use case but there are indeed useful computations which an user may want to do on the range bounds; for example, when using dates, one may want to truncate the start and end date to the hour or to the day before they are used for the densify operation.

   The $densify aggregation pipeline stage seems unable to evaluate range bounds expressions, requiring the range bounds to be constant.

   See the following example (the collection testcoll contains a single documents with only the _id field):

   sometestdb> db.testcoll.aggregate([{$addFields: {a: 1}}, {$densify: {field: "a", range: {bounds: [0, 5], step: 1}}}])
   
   [
   
     { a: 0 },
   
     { _id: ObjectId("6284a16d64553eaf74b1e189"), a: 1 },
   
     { a: 2 },
   
     { a: 3 },
   
     { a: 4 }
   
   ]
   
   
   
   sometestdb> db.testcoll.aggregate([{$addFields: {a: 1}}, {$densify: {field: "a", range: {bounds: [{$toInt: "0"}, 5], step: 1}}}])
   
   MongoServerError: A bounding array must be an ascending array of either two dates or

   … 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  ·  Query and Aggregation Pipeline  ·  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. Raise the limit of 16 MB JSON between aggregation stages

   When doing analytics, the 16 MB JSON limit between aggregation stages restricts the ability to process large amount of data. allowDiskUse does not help with all the various $operators and stages that we use. See ticket 00774514 for details.

   6 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  ·  Query and Aggregation Pipeline  ·  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. Add option to $dayOfWeek to choose between Monday and Sunday

   Hi!

   I was wondering if you could add an optional parameter to $dayOfWeek that allows you to choose on which day you want the functionality to start counting.

   Thanks!

   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  ·  Query and Aggregation Pipeline  ·  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. Add regex support in pipeline operator `replaceAll`

   It would be very nice to have something like this possible:

   { $replaceAll:
      { input: "$text", find: "/[;,.]/g", replacement: "." }
   }
   

   Many thanks !

   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  ·  Query and Aggregation Pipeline  ·  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. the profile output in association with the $comment query operator need to have consistency across operations.

   I have observed the different profile result with regard to $comment query operator in association with find and update operation respectively as follows;

   • find operation shows a comment on the command.filter.$comment and the command.comment field in the system.profile collection.

     op: 'query',
     ns: 'db101.Bets',
     command: {
     find: 'Bets',
     filter: {
     _id: ObjectId("61a9db4b3bd34e4f68fb9abc"),
     '$comment': 'test-dba'
     },
     comment: 'test-dba',
     lsid: { id: UUID("43ebee67-3184-4ede-9cee-ecca7457861a") },
     '$db': 'db101'
     },

   • update operation shows a comment only on the command.q.$comment field in the system.profile collection.

     op: 'update',
     ns: 'db101.Bets',
     command: {
     q: {
     _id: ObjectId("61a9db4b3bd34e4f68fb9abc"),
     '$comment': 'test-dba'
     },
     u: { '$set': { odds: 0.5 } },
     multi: false,
     upsert: false
     },

   I have observed the different profile result with regard to $comment query operator in association with find and update operation respectively as follows;

   • find operation shows a comment on the command.filter.$comment and the command.comment field in the system.profile collection.

     op: 'query',
     ns: 'db101.Bets',
     command: {
     find: 'Bets',
     filter: {
     _id: ObjectId("61a9db4b3bd34e4f68fb9abc"),
     '$comment': 'test-dba'
     },
     comment: 'test-dba',
     lsid: { id: UUID("43ebee67-3184-4ede-9cee-ecca7457861a") },
     '$db': 'db101'
     },

   • update operation shows a comment only on the command.q.$comment field in the system.profile collection.

     op: 'update',
     ns: 'db101.Bets',
     command: {
     q: {
     _id: ObjectId("61a9db4b3bd34e4f68fb9abc"),
     '$comment': 'test-dba'
     },
     u: { '$set': { odds: 0.5 } },
     multi:… 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  ·  Query and Aggregation Pipeline  ·  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. multiple centersphere as a geometry for geowithin

    im looking at one of my queries that a system regularly runs and some times we look for records that are within up to 250 different centerspheres, i wornder if we could enable, like geowithin has the ability to support multiple poligons, we could enable multiple centerspheres ,
    
    
$match: {{'location':{
"$geoWithin" : {
"$centerSphere" : [[ 14.4321, -9.4321], 2.5232135647961246e-05]
}
}}, {'location':{
"$geoWithin" : {
"$centerSphere" : [[ 14.4321, -9.4321], 2.5232135647961246e-05]
}
}}, ...}


    we could do :
    ```
    $match: {'location':{
    "$geoWithin" : {
    "$centerSpheres" : [
    [[ 14.4321, -9.4321], 2.5232135647961246e-05] ,
    [[ 14.4321, -9.4321], 2.5232135647961246e-05],
    ...
    ]

        } 
    }}
    

    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  ·  Query and Aggregation Pipeline  ·  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

11. $populate stage

    Please provide a $populate stage that allows to resolve single referenced documents.
    Internally it could use the combination of $lookup and $unwind:

    https://stackoverflow.com/questions/41482559/how-to-return-single-object-instead-of-array-in-lookup-of-mongodb

    Related:

    https://stackoverflow.com/questions/37793844/mongodb-how-to-resolve-dbref-on-client-side

    https://jira.mongodb.org/browse/SERVER-22497

    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  ·  Query and Aggregation Pipeline  ·  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

12. Provide straightforward syntax for 1-to-1 joins in aggregation

    The syntax for joins that bring back multiple documents from foreign collections is very straightforward and yields exactly what one would expect, but simple joins that are bread and butter in SQL require very convoluted and expensive to run syntax.

    Consider a product database that has products, categories and reviews collections. Each product has a unique category and may have multiple reviews. Getting all reviews in an aggregation is very straightforward (top stage), but getting categories, similar to SQL, is as convoluted as it gets (bottom stage).

    db.products.aggregate(
    [
        //
        // Document aggregates naturally aggregate foreign documents
        // into the primary document.
        //
        {$lookup: {
          from: "reviews",
          localField: "_id",
          foreignField: "product_id",
          as: "reviews"
        }},
    
        //
        // A simple join that is supposed to bring a couple of fields
        // into the primary document translates into this convoluted
        // syntax just to get those two fields.
        //
        {$lookup: {
          from: "categories",
          let: {category_id: "$category"},
          pipeline: [
            {$match: {
                $expr: {$eq: ["$_id", "$$category_id"]}
            }},
            {$project: {
                _id: 0,
                cat_name: "$category",
                cat_description: "$description"
            }}
          ],
          as: "category_details"
        }},
        {$replaceRoot: {
          newRoot: {
            $mergeObjects: [
              "$$ROOT", {$arrayElemAt: ["$category_details", 0]}
            ]
          }
        }},
        {$project: {
            category_details: 0
        }}
    ])
    

    Notice that keeping category.category and category.description in products, the noSQL-way, isn't an option because updating 10000's of products when category or description change is just not a good idea any way one looks at it. Denormalization is useful in many noSQL scenarios, but this isn't one of them.

    Having some simple join syntax that would identify the joined collection as a 1-to-1 join and would bring field names and values as if they existed in the primary document, possibly aliased via a projection-like syntax, would be extremely helpful in keeping aggregations readable, keeping data reasonably normalized, and would run much faster because it would be just multiple parallel BSON append calls when constructing aggregation results documents.

    Data for the query:

    products:
    
{"_id":{"$oid":"6140e6c6dfe7b9d6e597d07e"},"name":"Product A","category":1,"price":111}
{"_id":{"$oid":"6140e6c6dfe7b9d6e597d07f"},"name":"Product B","category":2,"price":222}
{"_id":{"$oid":"6140e6c6dfe7b9d6e597d080"},"name":"Product C","category":1,"price":333}

    categories:
    
{"_id":1,"category":"Clothing","description":"All kinds of clothing"}
{"_id":2,"category":"Electronics","description":"Cool gadgets"}

    reviews:
    
{"_id":{"$oid":"6140e7cadfe7b9d6e597d08a"},"product_id":{"$oid":"6140e6c6dfe7b9d6e597d07e"},"review":"Product A is great","rating":4}
{"_id":{"$oid":"6140e813dfe7b9d6e597d090"},"product_id":{"$oid":"6140e6c6dfe7b9d6e597d07f"},"review":"This product is horrible","rating":1}
{"_id":{"$oid":"6140e8eff4ff76778b48ba88"},"product_id":{"$oid":"6140e6c6dfe7b9d6e597d07f"},"review":"This product is not the best, but usable","rating":2}


    The syntax for joins that bring back multiple documents from foreign collections is very straightforward and yields exactly what one would expect, but simple joins that are bread and butter in SQL require very convoluted and expensive to run syntax.

    Consider a product database that has products, categories and reviews collections. Each product has a unique category and may have multiple reviews. Getting all reviews in an aggregation is very straightforward (top stage), but getting categories, similar to SQL, is as convoluted as it gets (bottom stage).

    db.products.aggregate(
    [
        //
        // Document aggregates naturally aggregate foreign documents
        // into

    … 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

    3 comments  ·  Query and Aggregation Pipeline  ·  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. support $lookup for update aggregation

    We frequently denormalise either full documents or subsets to different documents in order to speed up reading, create indexes or paginate/sort on fields.

    Consider a user collection and a task collection, if a task can be assigned to the user, it makes sense to just put the user document on the task they are assigned. But an update to a user now requires you to update the user both in the user collection and all tasks with that user in the tasks collection.

    This can be achieved but does introduce some complexity, however the introduction of updates using aggregation pipelines could eliminate this problem if they supported the $lookup operator.

    So we could achieve the desired result using two simple operations

    db.collection('users').updateOne({id: '1234'}, {$set: ...})
    db.collection('tasks').updateMany({"user.id": '1234'}, [
    {
    $lookup: {
    from: 'users',
    localField: 'user.id',
    foreignField: 'id',
    as: 'user'
    }
    }
    ]);

    This would make it really simple to synchronise data between documents in different collections

    We frequently denormalise either full documents or subsets to different documents in order to speed up reading, create indexes or paginate/sort on fields.

    Consider a user collection and a task collection, if a task can be assigned to the user, it makes sense to just put the user document on the task they are assigned. But an update to a user now requires you to update the user both in the user collection and all tasks with that user in the tasks collection.

    This can be achieved but does introduce some complexity, however the introduction of updates using aggregation pipelines… 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

    2 comments  ·  Query and Aggregation Pipeline  ·  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. Allow configuration of 100mb memory limit per aggregation pipeline stage

    In this old thread from 2016 (https://groups.google.com/forum/#!topic/mongodb-user/LCeFZZRz5EY) it was asked whether there was a way to increase the 100mb in memory limit of each stage of an aggregation pipeline. The responses centered around two points:

    1. If too much memory is used per aggregation pipeline stage then it will reduce performance for the overall MongoDB database, impacting other queries negatively.
    2. You can set allowDiskUse: true and revert to performing these pipeline stages on disk when they exceed 100mb.

    I believe this subject needs to be revisited for the following reasons:

    1. “Too much memory” is very subjective, and the 100mb number is arbitrary. The hardware for a typical MongoDB database setup in 2016 is not the same as in 2020. And what is the MongoDB use case for one company isn’t the use case for another company. Company A might have top of the line hardware they are running MongoDB on and only have a few concurrent users, and need large in memory aggregation queries to run fast so want to set a limit of 200mb or even higher. Company B might have lesser hardware and many concurrent users, and want to set the limit to 50mb or less.
    2. The allowDiskUse: true option is nice to have, but it obviously comes at a huge performance hit once your aggregation pipeline stages exceed the 100mb limit, even on high performance SSD drives.

    This really comes down to who knows best what the limit should be, the company’s developers and database / server ops teams or the MongoDB developers? The MongoDB developers obviously have much more knowledge on the inner workings of Mongo, but that advice can still be taken into account by having a default limit of 100mb. I believe very strongly that today in 2020 this limit should be configurable so that we can customize the behavior for our own specific situation. The documentation can of course provide a warning that changing the setting can impact performance (although everyone already knows that.)

    If you want to get into the details of why my company needs to increase this limit, and why it has been holding us back from switching from SQL Server to MongoDB for the last year (despite spending 6 months developing a working Mongo solution) then we can get into specifics. But really that will distract away from the central issue, which is that different customers have different scenarios, and a “one size fits all” solution isn’t appropriate and needs to be customizable.

    In this old thread from 2016 (https://groups.google.com/forum/#!topic/mongodb-user/LCeFZZRz5EY) it was asked whether there was a way to increase the 100mb in memory limit of each stage of an aggregation pipeline. The responses centered around two points:

    1. If too much memory is used per aggregation pipeline stage then it will reduce performance for the overall MongoDB database, impacting other queries negatively.
    2. You can set allowDiskUse: true and revert to performing these pipeline stages on disk when they exceed 100mb.

    I believe this subject needs to be revisited for the following reasons:

    1. “Too much memory” is very subjective, and the 100mb… more
    24 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  ·  Query and Aggregation Pipeline  ·  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