About sharding csubs collections

[sekiguchi-yohei]

Hi, We are trying to configure the MongoDB to which we are connecting with range-based sharding, as in the architecture in the following document.
https://www.mongodb.com/docs/v4.4/tutorial/sharding-segmenting-data-by-location/

Shard Key would like to use servicePath as an alternative to [country] in the ↑ document.
・entities: _id.servicePath
・csubs: servicePath
・registrations: servicePath

However, "PATCH /v2/subscriptions/{subscriptionId}" with Fiware-ServicePath header gave an InternalServerError.
Error Message

{"error":"Internal Server Error","description":"Database Error (collection: orion.csubs - findAndModify(): <{ "_id" : { "$oid" : "64927cff1f76bb0db558838b" } },{ "$set" : { "servicePath" : "/US", "reference" : "http://sample-consumer:8080/", "custom" : false, "timeout" : 0, "attrs" : [ "dateModified", "*" ], "metadata" : [  ], "maxFailsLimit" : -1, "blacklist" : false, "format" : "keyValues" }, "$unset" : { "topic" : 1, "qos" : 1, "user" : 1, "passwd" : 1, "payload" : 1 } }> - exception: Query for sharded findAndModify must contain the shard key)"}

Why is the servicePath not included in the query to the csubs collection? (Because it is always unique by _id?).
Also, do you plan to include servicePath in queries in the future?

Version
Orion: 3.7.0
MongoDB: 4.4

[fgalan]

Why is the servicePath not included in the query to the csubs collection? (Because it is always unique by _id?).

Exactly: MongoDB ensure sub _id are unique by construction, so we don't need to include servicePath in the query (keeping the query as simple as possible).

Also, do you plan to include servicePath in queries in the future?

No... until you have raised this issue :) It could make sense, but before confirming that I'd like to know if you have evaluated other alternative shard keys and why did you chose servicePath among these alternatives, please.

[fgalan]

Exactly: MongoDB ensure sub _id are unique by construction, so we don't need to include servicePath in the query (keeping the query as simple as possible).

I'm just remember query simplicity is not the only reason...

Different to entities, subscription doesn't belong to a given subservice (this is explained in more detail in https://github.com/telefonicaid/fiware-orion/blob/master/doc/manuals/orion-api.md#service-path-in-subscriptions-and-registrations).

Changing the behaviour to include service path in the query would involve a backward compatibility break in the following:

Fiware-ServicePath header is ignored in GET /v2/subscriptions/{id} and GET /v2/registrations/{id} operations, as the id fully qualifies the subscription or registration to retrieve.