Merge pull request #210593 from deborahc/dech-elasticity-docs-v2

Adding some guidance on how to identify merge candidate collections

Author: JamesJBarnett

articles/cosmos-db/media/merge/ru-per-physical-partition-metric.png

@@ -27,9 +27,42 @@ The Azure Cosmos DB team will review your request and contact you via email to c
 
 To check whether an Azure Cosmos DB account is eligible for the preview, you can use the built-in eligibility checker in the Azure portal. From your Azure Cosmos DB account overview page in the Azure portal, navigate to **Diagnose and solve problems** -> **Throughput and Scaling** ->  **Partition Merge**. Run the **Check eligibility for partition merge preview** diagnostic.
 
-:::image type="content" source="media/merge/throughput-and-scaling-category.png" alt-text="Throughput and Scaling topic in Diagnose and solve issues page":::
+:::image type="content" source="media/merge/throughput-and-scaling-category.png" alt-text="Screenshot of Throughput and Scaling topic in Diagnose and solve issues page.":::
 
-:::image type="content" source="media/merge/merge-eligibility-check.png" alt-text="Merge eligibility check with table of all preview eligibility criteria":::
+:::image type="content" source="media/merge/merge-eligibility-check.png" alt-text="Screenshot of merge eligibility check with table of all preview eligibility criteria.":::
+
+### How to identify containers to merge
+
+Containers that meet both of these conditions are likely to benefit from merging partitions:
+- Condition 1: The current RU/s per physical partition is <3000 RU/s
+- Condition 2: The current average storage in GB per physical partition is <20 GB
+
+Condition 1 often occurs when you have previously scaled up the RU/s (often for a data ingestion) and now want to scale down in steady state.
+Condition 2 often occurs when you delete/TTL a large volume of data, leaving unused partitions.
+
+#### Criteria 1
+
+To determine the current RU/s per physical partition, from your Cosmos account, navigate to **Metrics**. Select the metric **Physical Partition Throughput** and filter to your database and container. Apply splitting by **PhysicalPartitionId**. 
+
+For containers using autoscale, this will show the max RU/s currently provisioned on each physical partition. For containers using manual throughput, this will show the manual RU/s on each physical partition.
+
+In the below example, we have an autoscale container provisioned with 5000 RU/s (scales between 500 - 5000 RU/s). It has 5 physical partitions and each physical partition has 1000 RU/s.
+
+:::image type="content" source="media/merge/RU-per-physical-partition-metric.png" alt-text="Screenshot of Azure Monitor metric Physical Partition Throughput in Azure portal.":::
+
+#### Criteria 2
+
+To determine the current average storage per physical partition, first find the overall storage (data + index) of the container.
+
+Navigate to **Insights** > **Storage** > **Data & Index Usage**. The total storage is the sum of the data and index usage. In the below example, the container has a total of 74 GB of storage.
+
+:::image type="content" source="media/merge/storage-per-container.png" alt-text="Screenshot of Azure Monitor storage (data + index) metric for container in Azure portal.":::
+
+Next, find the total number of physical partitions. This is the distinct number of **PhysicalPartitionIds** in the **PhysicalPartitionThroughput** chart we saw in Criteria 1. In our example, we have 5 physical partitions.
+
+Finally, calculate: Total storage in GB / number of physical partitions. In our example, we have an average of (74 GB / 5 physical partitions) = 14.8 GB per physical partition. 
+
+Based on criteria 1 and 2, our container can potentially benefit from merging partitions.
 
 ### Merging physical partitions