Database
-
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:
- If too much memory is used per aggregation pipeline stage then it will reduce performance for the overall MongoDB database, impacting other queries negatively.
- 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:
- “Too much memory” is very subjective, and the 100mb…
13 votes -
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.
2 votes -
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…
2 votes -
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 -
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 -
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:…
1 vote -
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 -
$populate stage
Please provide a $populate stage that allows to resolve single referenced documents.
Internally it could use the combination of $lookup and $unwind:Related:
https://stackoverflow.com/questions/37793844/mongodb-how-to-resolve-dbref-on-client-side
1 vote -
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
andreviews
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
1 vote
- Don't see your idea?