Choosing correct approach to build a muti-tenant architecture with Azure Cosmos DB (MongoDB)
Asked Answered
H

1

7

I am little confused in choosing the suitable approach of creating database/collections for a multi-tenant system in MongoDB in CosmosDB API. I would have 500 tenants for my application, where each tenant's data may grow up to 3-5GB and initially each tenant may need minimum RUs (400 RU/s).

For this use case i would have few options to go with: 1. PartitionKey (per tenant) 2. Container w/ shared throughput (per tenant) 3. Container w/ dedicated throughput (per tenant) 4. Database Account (per tanant)

Considering the Performance Isolation, Cost, Availability and Security, may i know which option would be suitable for the mentioned use case ?. Please let me know your inputs as i have less exposure to NoSQL and Cosmos track.

Hackle answered 15/4, 2020 at 6:11 Comment(0)
P
13

There are multiple options and it depends on your specific tenant use cases.

Tenant/Partition is the least expensive with a marginal cost per tenant of zero. This is a great option for providing a "free-tier" in your app but you can scale this up to a paid tier for your customers too. Max storage size is 20GB. With this scheme you will need to implement your own resource governance to ensure customers are not "running hot" and consuming throughput that is drastically out of line from other users. If you're building a multi-tenant app, resource governance is something you should already be doing.

Tenant/Container is more expensive with minimum RU of 400 RU/s for standard. Autoscale can go as low as 100 RU/s. This is ideal when you have tenants that are very large and require isolation from others in the previous tier. Autoscale can also be really helpful to ensure lowest possible cost.

Tenant/Account is same marginal cost as Tenant/Container. This is useful if you have customers that have GDPR requirements that prevent or require replication into specific Azure regions. There are also lots of other features that are at the account level such as backup/restore that also make this a good option for some tenants.

Note that I DO NOT recommend Tenant/Container using shared Database throughput. The reason is because with this scheme, all containers share the same throughput which is what you get with Tenant/Partition but performance is not predictable with shared Database throughput and you are limited to 25 containers per database making it a poor choice.

Also worth mentioning, there is also a new MongoDB vCore service which is single instance. This provides basically the same experience as native MongoDB so might be right choice for you.

Finally, for your app you will need to implement a mechanism to migrate customers from one tier to another. You will also of course require some sort of auth-n/auth-z mechanism. Cosmos DB has support for Azure AD but you may decide to isolate Cosmos from AAD if your tenants have their own AAD tenants.

PS: if you are building a new service on Cosmos DB I recommend using our Core (NoSQL) API rather than MongoDB. This is our native service and you will get the best performance and features. Our MongoDB API is the best choice for customers who are looking to migrate and want a fully managed MongoDB experience.

Hope this is helpful.

Philippopolis answered 15/4, 2020 at 15:13 Comment(1)
A safe link to "Deep dive: Mission-critical multi-tenant apps with Cosmos DB multi-master" azure.microsoft.com/en-us/resources/videos/…Reek

© 2022 - 2024 — McMap. All rights reserved.