Cosmosdb with multiple partition key

Raja 81 Reputation points
2022-01-24T10:03:58.217+00:00

Hello Team,
I have cosmosdb setup for one of my requirements. The cosmosdb is accessed using its REST API functionality.
The cosmosdb is partitioned one key called let's cid. So overall the REST call looks like ,

https://{{DocumentDBHost}}/dbs/mydb/colls/mycol/docs/123

This works perfectly fine.
In the JSON document we also have few more fields/attributes like oid and sid.
Now we have an additional requirement that we want to query on multiple such ids. Suppose we have one attribute as oid (value 222) and one attribute as sid(333). If user uses any of these ids, the cosmosdb should return the JSON.

So essentially if user passes any of these
https://{{DocumentDBHost}}/dbs/mydb/colls/mycol/docs/123 //For cid
https://{{DocumentDBHost}}/dbs/mydb/colls/mycol/docs/222 //For oid
https://{{DocumentDBHost}}/dbs/mydb/colls/mycol/docs/333 //For sid

User wants this to get resolved internally. So if he passes any number as id, cosmosdb should search across these 3 type of ids ( attributes of JSON) and should be able to resolve it or find the correct document.

What's the best way to achieve it? Is there any way to have multiple partition keys at the same time which can resolve it?

Thanks,
Raja

Azure Cosmos DB
Azure Cosmos DB
An Azure NoSQL database service for app development.
1,434 questions
{count} votes

1 answer

Sort by: Most helpful
  1. Chengjie Xu 1 Reputation point Microsoft Employee
    2022-02-02T03:47:49.673+00:00

    As your description mentioned, you have a partition key called cid. This cid is the only partition key CosmosDB can have and once it was decided at the initialization it cannot be changed anymore.

    Since you have oid and sid, they probably can be properties for indexing purposes and you need to design them in this way instead of the partition key. which means you could wrap the basic REST API with your own method including something like sql query as mentioned above and expose the new API to the end-users.

    0 comments No comments