CODEWITHSUNDEEP
.netazure-cosmosdb
Jnormen
Jnormen

Reputation: 375

Is this a good strategy about partitions-key in Cosmos Db with tenancy?

I want to separate the data for easy GDPR management etc. So I was thinking to have one MongoDb with CosmosDb for each microservice. So 10 Microservices is 10 MongoDb databases.

Then I need multi-tenancy support. So I was thinking that each tenant can have its own collection inside the databases. (Sharing throughput).

So one service has one database and many collections. If 100 customers, it's 100 collections.

But then I want a way to store my documents. So I was thinking that each type can be my partition key. Like. "Gate", "Order", "User" etc...

Before I used one db for each customer but the cost was a problem.

I do not want to share tenants data together, that's why I'm thinking of this separation. And I can easily let devs be there own tenant in the system so they are not querying other tenants data by mistake.

Logical this will work, technical as well. But I'm not sure if it's a good practice to have so many collections. I can't find any limits of how many collections, but maybe there is one? 

GateServiceDb
   3343-414-1441-141441 (Tenant collection)
        Gate - Partion (Document type)
        Entrence - Partion (Document type)
        ...
   3252-532-252-141441 (Tenant collection)
        Gate - Partion (Document type)
        Entrence - Partion (Document type)
        ...
   123-445-1441-141441 (Tenant collection)
        Gate - Partion (Document type)
        Entrence - Partion  (Document type)
        ...
   ...

Upvotes: 0

Views: 704

Answers (1)

Mohit Verma
Mohit Verma

Reputation: 5294

At a high-level, depending on the scale of your tenants you could choose to partition by database or collection. In cases where tenant data is smaller and tenancy numbers are higher – we suggest that you store data for multiple tenants in the same collection to reduce the overall resources necessary for your application. You can identify your tenant by a property in your document and issue filter queries to retrieve tenant-specific data. You can also use DocumentDB’s users and permissions to isolate tenant data and restrict access at a resource-level via authorization keys.

In cases where tenants are larger, need dedicated resources, or require further isolation - you can allocate dedicated collections or databases for tenants. In either case, DocumentDB will handle a significant portion of the operational burden for you as you scale-out your application’s data store.

So coming back to your original question, one service has one database and many collections ,

Do you know if you application and data would be big enough that you want to separate one DB per Micro services, or it will work like one collection per Micro service?

You other question "I can't find any limits of how many collections" :

As you may already know, a collection is a container for your JSON documents. Collections are also DocumentDB’s unit of partition and boundary for the execution of queries and transactions. Each collection provides a reserved amount of throughput. You can scale out your application, in terms of both storage and throughput, by adding more collections, and distributing your documents across them.

What are the storage limits of Azure Cosmos DB?

There's no limit to the total amount of data that a container can store in Azure Cosmos DB.

What are the throughput limits of Azure Cosmos DB?

There's no limit to the total amount of throughput that a container can support in Azure Cosmos DB. The key idea is to distribute your workload roughly evenly among a sufficiently large number of partition keys.

Upvotes: 1

Related Questions