Exam DP-201 topic 1 question 22 discussion

Given there are 100 million orders in a 24 hour period, and there are only three catgegories, is Item/Id not a better solution, otherwise the category will cause significant hotspots?

2 paragraphs below the link given in microsoft docs, there is an interesting answer : Using item ID as the partition key If your container has a property that has a wide range of possible values, it is likely a great partition key choice. One possible example of such a property is the item ID. For small read-heavy containers or write-heavy containers of any size, the item ID is naturally a great choice for the partition key. The item ID is a great partition key choice for the following reasons: There are a wide range of possible values (one unique item ID per item). Because there is a unique item ID per item, the item ID does a great job at evenly balancing RU consumption and data storage. You can easily do efficient point reads since you'll always know an item's partition key if you know its item ID.

Answer should be "item/id". You can find almost similar example in below link. https://docs.microsoft.com/en-us/learn/modules/monitor-and-scale-cosmos-db/5-partition- lesson

D. Item/id is the answer

Given solution is right where we choose the item/category. It's explained in detail in the below link https://medium.com/walmartglobaltech/deep-dive-azure-cosmos-partitions-and-partitionkey-14e898f371cd this concept is of major focus as question may not be exactly asked in exam we need to need to know the concept of physical & logical partitions pre-requisites & Partition key as well.

If you use the Item/Category property as a partition key, then it has a small cardinality. Even if the documents are evenly distributed across the collection, for large collections, any category might outgrow a single partition. If the categories aren't evenly distributed across the documents in the collection, then the problem is even worse. The dominant category restricts the ability of Azure Cosmos DB to scale. Item/Category is not a good choice for the partition key. https://docs.microsoft.com/en-us/learn/modules/monitor-and-scale-cosmos-db/5-partition-lesson

From https://docs.microsoft.com/en-us/azure/cosmos-db/partitioning-overview#choose-partitionkey: "Have a high cardinality. In other words, the property should have a wide range of possible values." D is the answer

item/id for sure. see the section "Propose partition key values for the collection" at: https://docs.microsoft.com/en-us/learn/modules/monitor-and-scale-cosmos-db/5-partition-lesson

Candidates for partition keys might include properties that appear frequently as a filter in your queries. Queries can be efficiently routed by including the partition key in the filter predicate. Item ID will not appear as a filter most likely

Given the discussion here: https://docs.microsoft.com/en-us/learn/modules/monitor-and-scale-cosmos-db/5-partition-lesson, "Item/id" is the correct answer

I shall go with D. Item/Id Item/Category is out. It will only create 3 logical partitions, that also unevenly distributed. A logical distribution has a size cap of 20 GB. With 100 million orders per day, it won't be very hard to reach that limit quickly. OrderTime is out. 16:30 to 17:00 spike shall create a hotspot problem. Item/Currency is out. Only 1 value "USD" will result in everything cramming up one logical partition. Only Item/id is left. So this is the answer.

your partition key should: Be a property that has a value which does not change. If a property is your partition key, you can't update that property's value. Have a high cardinality. In other words, the property should have a wide range of possible values. Spread request unit (RU) consumption and data storage evenly across all logical partitions. This ensures even RU consumption and storage distribution across your physical partitions.

https://docs.microsoft.com/en-us/azure/cosmos-db/partition-data#logical-partitions https://docs.microsoft.com/en-us/azure/cosmos-db/partitioning-overview https://www.examtopics.com/exams/microsoft/dp-201/view/6/ D Item/ID Category doesn’t distribute RU evenly across partitions. Low cardinality.

Consider we have provisioned a throughput of 1200 request units and we know that throughput can be provisioned in cosmos db only at a container level or at a database level. In our case we consider our online retailer to be Walkart. Now walkart has an account in cosmosdb and they have a document db with coresql api. Now walkart has created a container named orders in their cosmos account and provisioned 1200ru's. Now consider the case of choosing a partition key. Considering they have 1200 customer id-s and if they use id as partition key they will have their throughput spread across partitions which makes their unused throughput in vain as customers come buy and go and it makes a hotspot. Now if we choose product category as partition we'll be having a balanced throughput and read-write.

these comments causing further confusing for new bees as it's not able to draw whats final correct answer.. I would go by Item/Category only... this combo may not give repeated values as item would be different in same category.. item/id might create super heavy number of partitions

In this case A is correct indeed. See the reference and be aware of the read/write balancing. The read is as important as the throuput. Partition keys for read-heavy containers For most containers, the above criteria is all you need to consider when picking a partition key. For large read-heavy containers, however, you might want to choose a partition key that appears frequently as a filter in your queries. Queries can be efficiently routed to only the relevant physical partitions by including the partition key in the filter predicate. If most of your workload's requests are queries and most of your queries have an equality filter on the same property, this property can be a good partition key choice. For example, if you frequently run a query that filters on UserID, then selecting UserID as the partition key would reduce the number of cross-partition queries

Choose a partition key that has a wide range of values,so the data is evenly spread across logical partitioning. Hence I suggest the answer is item/category