Single or Multiple Entities Per Collection in DocumentDB

Question

Should there be one entity per collection in document DB?

Consider I have foreign key relationship in below diagram:

Answer 1

Many things have changed in Cosmos DB in the last 5 years and one of the most significant changes affecting data structure design is the possibility to create many containers and share the RU among all of them.

It is still fine to combine multiple entity types in the same container (new name for collection). However, in the year 2020, it is also fine to put each entity type in a separate container.

Of course it depends on the needs of your application and a very significant consideration is how you intend to read this information. However, here is a general data structure and approach that you can consider:

1. Keep each entity in their own container
2. Include a property with the name of the entity
3. Choose partition keys in a way so you will never have more than 10 GB data in one partition
4. Identify the reads for which you will require optimal performance because of high volume of calls
5. Here's the kicker: Replicate data to a container optimized for expected reads

For those reads you want to optimize, replicate the data to a new container dedicated to that purpose and make sure the partition key matches the main parameter that you query by. You can put many different entities in the same container.

You will find that the read operation is many times more efficient this way.

Cosmos DB performance is largely determined by the volume of the data and if you make sure your documents are easy to reach via partition key, you do not get any significant performance gains by putting a lot of data inside a single document as opposed to keeping them in separate documents.

Example

You have two containers:

• orders
• order-details

The orders are partitioned by productId and order details are partitioned by orderId. But for a new feature that shows the order history of a single user, it costs far too many RU, not only to get the orders by the userId property, but especially to make subsequent calls for every order to get the order details that are placed in separate partitions.

Instead, luckily, both documents contain a userId property. What you do is create a new container maybe called orders-by-user and configure the userId property to be partition key. Then replicate all documents from orders and order-details to this container.

You can now make incredibly efficient reads on this container by userId.

You can replicate using Data Factory, Azure Functions based on change feed and soon there will be a built-in feature for this purpose (look in the comments): https://stackoverflow.com/a/64355508/392362