[SERVER-43376] Operations on non-sharded views in sharded clusters extra round trip Created: 19/Sep/19  Updated: 27/Oct/23  Resolved: 23/Sep/19

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 4.0.12
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Alexander Komyagin Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Sharding
Participants:

 Description   

It looks like if I have a view on a non-sharded collection, then operations on it (e.g. find, explain) require an extra roundtrip because mongod bounces the first request with an exception that is used by mongos to find out that it's indeed a view:

2019-09-19T09:20:46.883-0500 D TRACKING [replSetDistLockPinger] Cmd: NotSet, TrackingId: 5d838ebe2a67f139ad45d445
2019-09-19T09:20:47.647-0500 D TRACKING [Uptime reporter] Cmd: NotSet, TrackingId: 5d838ebf2a67f139ad45d447
2019-09-19T09:20:48.476-0500 D -        [conn5] User Assertion: CommandOnShardedViewNotSupportedOnMongod{ resolvedView: { ns: "test.test", pipeline: [], collation: { locale: "simple" } } }: On sharded systems, resolved views must be executed by mongos src/mongo/db/query/cursor_response.h 165
2019-09-19T09:20:48.479-0500 D TRACKING [conn5] Cmd: find, TrackingId: 5d838ec02a67f139ad45d44c
2019-09-19T09:20:48.483-0500 I COMMAND  [conn5] command test.view appName: "MongoDB Shell" command: find { find: "view", filter: { x: 3.0 }, lsid: { id: UUID("a9e2ff0d-2a78-4a7a-b8d5-16f14ac83375") }, $clusterTime: { clusterTime: Timestamp(1568902782, 1), signature: { hash: BinData(0, 0000000000000000000000000000000000000000

I think this is not necessary for non-sharded collections.



 Comments   
Comment by Esha Maharishi (Inactive) [ 23/Sep/19 ]

alex.komyagin we are aware of this inefficiency but don't have immediate plans to improve it, so closing as Works as Designed.

Comment by Randolph Tan [ 19/Sep/19 ]

This was a compromise we made because OSS (OperationShardingState: the thing that keeps track of request's shard version) supported only 1 namespace. So when the request on view ns1 comes in and resolves to ns2, the shard version checking code could not perform the check the ns2. We may need to also enhance OSS to track more than one ns to enable this

Generated at Thu Feb 08 05:03:01 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.