-
Type:
Improvement
-
Resolution: Done
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Aggregation Framework, Sharding
-
Fully Compatible
-
Query 13 (04/22/16), Query 2017-07-10, Query 2017-07-31, Query 2017-08-21
Suppose you have a pipeline consisting of a single $match stage which is delivered to mongos by the client. Also suppose that mongos will target multiple shards in order to find the matching data. Currently, the aggregation system will establish a shard as the merging node. Instead, mongos could perform the merging (it already knows how to do this for .find() operations).
This would improve the latency of the aggregation operation, since it would eliminate a network hop. Data currently has to travel from a targeted shard, to the merging shard, to mongos, and back to the client. If mongos were responsible for merging, data would only have to travel from a targeted shard, to mongos, to the client.
Mongos can also merge sorted streams coming from the shards for .find() operations, so this could also be extended to $match+$sort pipelines.
- depends on
-
SERVER-27937 pull apart the AsyncResultsMerger logic into (1) establishing the cursors (2) sending the getMore's
-
- Closed
-
- is depended on by
-
-
- Closed
-
- is related to
-
SERVER-18940 Optimise sharded aggregations that are targeted to a single shard
-
- Closed
-
-
SERVER-142 Read-only views over collection data.
-
- Closed
-
- related to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Backlog
-
-
-
- Closed
-
-
-
- Closed
-