Merge pull request #4285 from seesharprun/cosmos-db-fix-broken-links-3

prmerger-automator[bot] · web-flow · commit 3956bdf33ef6 · 2026-02-02T18:07:31.000Z
Cosmos DB | Fix broken links (3/5)
diff --git a/articles/cosmos-db/how-to-setup-customer-managed-keys.md b/articles/cosmos-db/how-to-setup-customer-managed-keys.md
@@ -673,7 +673,7 @@ All the data stored in your Azure Cosmos DB account is encrypted with the custom
 
 - The property paths declared in your [indexing policies](./index-policy.md)
 
-- The values of your containers' [partition keys](./partitioning-overview.md)
+- The values of your containers' [partition keys](./partitioning.md)
 
 ### Are customer-managed keys supported for existing Azure Cosmos DB accounts?
 
diff --git a/articles/cosmos-db/large-partition-keys.md b/articles/cosmos-db/large-partition-keys.md
@@ -80,7 +80,7 @@ Currently, you cannot use containers with large partition key within in Power BI
 
 ## Next steps
 
-* [Partitioning in Azure Cosmos DB](partitioning-overview.md)
+* [Partitioning in Azure Cosmos DB](partitioning.md)
 * [Request Units in Azure Cosmos DB](request-units.md)
 * [Provision throughput on containers and databases](set-throughput.md)
 * [Work with Azure Cosmos DB account](./resource-model.md)
diff --git a/articles/cosmos-db/merge.md b/articles/cosmos-db/merge.md
@@ -314,4 +314,4 @@ If you enroll in the preview, the following connectors fail.
 
 - Learn more about [using Azure CLI with Azure Cosmos DB.](/cli/azure/azure-cli-reference-for-cosmos-db)
 - Learn more about [using Azure PowerShell with Azure Cosmos DB.](/powershell/module/az.cosmosdb/)
-- Learn more about [partitioning in Azure Cosmos DB.](partitioning-overview.md)
+- Learn more about [partitioning in Azure Cosmos DB.](partitioning.md)
diff --git a/articles/cosmos-db/migrate-containers-partitioned-to-nonpartitioned.md b/articles/cosmos-db/migrate-containers-partitioned-to-nonpartitioned.md
@@ -39,7 +39,7 @@ To support the migration, Azure Cosmos DB provides a system defined partition ke
 
 After the container is migrated, you can create documents by populating the `_partitionKey` property along with the other properties of the document. The `_partitionKey` property represents the partition key of your documents.
 
-Choosing the right partition key is important to utilize the provisioned throughput optimally. For more information, see [how to choose a partition key](partitioning-overview.md) article.
+Choosing the right partition key is important to utilize the provisioned throughput optimally. For more information, see [how to choose a partition key](partitioning.md) article.
 
 > [!NOTE]
 > You can take advantage of system defined partition key only if you are using the latest/V3 version of SDKs in all the languages.
@@ -179,7 +179,7 @@ If new items are inserted with different values for the partition key, querying
 
 ## Next steps
 
-* [Partitioning in Azure Cosmos DB](partitioning-overview.md)
+* [Partitioning in Azure Cosmos DB](partitioning.md)
 * [Request Units in Azure Cosmos DB](request-units.md)
 * [Provision throughput on containers and databases](set-throughput.md)
 * [Work with Azure Cosmos DB account](resource-model.md)
diff --git a/articles/cosmos-db/migrate-hbase.md b/articles/cosmos-db/migrate-hbase.md
@@ -54,7 +54,7 @@ The key differences between the data structure of Azure Cosmos DB and HBase are
 
 * In HBase, data is stored by [RowKey](https://hbase.apache.org/book.html#rowkey.design) and horizontally partitioned into regions by the range of RowKey specified during the table creation.
 
-* Azure Cosmos DB on the other side distributes data into partitions based on the hash value of a specified [Partition key](partitioning-overview.md).
+* Azure Cosmos DB on the other side distributes data into partitions based on the hash value of a specified [Partition key](partitioning.md).
 
 **Column family**
 
@@ -129,7 +129,7 @@ You can also use [autoscaling provisioning throughput](provision-throughput-auto
 HBase sorts data according to RowKey. The data is then partitioned into regions and stored in RegionServers. The automatic partitioning divides regions horizontally according to the partitioning policy. This is controlled by the value assigned to HBase parameter `hbase.hregion.max.filesize` (default value is 10 GB). A row in HBase with a given RowKey always belongs to one region. In addition, the data is separated on disk for each column family. This enables filtering at the time of reading and isolation of I/O on HFile.
 
 **Azure Cosmos DB**
-Azure Cosmos DB uses [partitioning](partitioning-overview.md) to scale individual containers. For comprehensive details about logical partitions, physical partitions, and partition key selection, see the [partitioning overview](partitioning-overview.md).
+Azure Cosmos DB uses [partitioning](partitioning.md) to scale individual containers. For comprehensive details about logical partitions, physical partitions, and partition key selection, see the [partitioning overview](partitioning.md).
 
 **Key differences for migration:**
 
diff --git a/articles/cosmos-db/model-partition-example.md b/articles/cosmos-db/model-partition-example.md
@@ -15,7 +15,7 @@ appliesto:
 
 # How to model and partition data using a real-world example
 
-This article builds on several Azure Cosmos DB concepts like [data modeling](modeling-data.md), [partitioning](partitioning-overview.md), and [provisioned throughput](request-units.md) to demonstrate how to tackle a real-world data design exercise.
+This article builds on several Azure Cosmos DB concepts like [data modeling](modeling-data.md), [partitioning](partitioning.md), and [provisioned throughput](request-units.md) to demonstrate how to tackle a real-world data design exercise.
 
 If you usually work with relational databases, you've probably developed habits for designing data models. Because of the specific constraints, but also the unique strengths of Azure Cosmos DB, most of these best practices don't translate well and might drag you into suboptimal solutions. The goal of this article is to guide you through the complete process of modeling a real-world use case on Azure Cosmos DB, from item modeling to entity colocation and container partitioning.
 
@@ -595,5 +595,5 @@ The change feed that we use to distribute updates to other containers store all
 After this introduction to practical data modeling and partitioning, you might want to check the following articles to review the concepts:
 
 - [Databases, containers, and items in Azure Cosmos DB](resource-model.md)
-- [Partitioning and horizontal scaling in Azure Cosmos DB](partitioning-overview.md)
+- [Partitioning and horizontal scaling in Azure Cosmos DB](partitioning.md)
 - [Change feed in Azure Cosmos DB](change-feed.md)
diff --git a/articles/cosmos-db/modeling-data.md b/articles/cosmos-db/modeling-data.md
@@ -403,7 +403,7 @@ The ability to have a model with precalculated fields is made possible because A
 
 ## Distinguish between different item types
 
-In some scenarios, you might want to mix different item types in the same collection; this design choice is usually the case when you want multiple, related documents to sit in the same [partition](partitioning-overview.md). For example, you could put both books and book reviews in the same collection and partition it by `bookId`. In such a situation, you usually want to add a field to your documents that identifies their type to differentiate them.
+In some scenarios, you might want to mix different item types in the same collection; this design choice is usually the case when you want multiple, related documents to sit in the same [partition](partitioning.md). For example, you could put both books and book reviews in the same collection and partition it by `bookId`. In such a situation, you usually want to add a field to your documents that identifies their type to differentiate them.
 
 ```json
 Book documents:
@@ -536,6 +536,6 @@ Just as there's no single way to represent a piece of data on a screen, there's
 
 ## Related content
 
-- [Partitioning data in Azure Cosmos DB](partitioning-overview.md)
+- [Partitioning data in Azure Cosmos DB](partitioning.md)
 - [Data modeling and partitioning - a real-world example](model-partition-example.md)
 - [Model and partition your data in Azure Cosmos DB](/training/modules/model-partition-data-azure-cosmos-db/)
diff --git a/articles/cosmos-db/multi-region-writes.md b/articles/cosmos-db/multi-region-writes.md
@@ -44,5 +44,5 @@ A multi-region-write account uses two server timestamp values for each entity. T
 - [Multi-region writes in your applications that use Azure Cosmos DB](how-to-multi-master.md)
 - [Consistency levels in Azure Cosmos DB](consistency-levels.md)
 - [Request Units in Azure Cosmos DB](request-units.md)
-- [Global data distribution with Azure Cosmos DB - under the hood](global-dist-under-the-hood.md)
+- [Global data distribution with Azure Cosmos DB - under the hood](global-distribution.md)
 - [Availability of Azure Cosmos DB software development kits (SDKs) in multiregional environments](troubleshoot-sdk-availability.md)
diff --git a/articles/cosmos-db/optimize-cost-throughput.md b/articles/cosmos-db/optimize-cost-throughput.md
@@ -28,7 +28,7 @@ You can provision throughput on databases or containers and each strategy can he
 
 * If you provision throughput on a database, all the containers, for example collections/tables/graphs within that database can share the throughput based on the load. Throughput reserved at the database level is shared unevenly, depending on the workload on a specific set of containers.
 
-* If you provision throughput on a container, the throughput is guaranteed for that container, backed by the SLA. The choice of a logical partition key is crucial for even distribution of load across all the logical partitions of a container. See [Partitioning](partitioning-overview.md) and [horizontal scaling](partitioning-overview.md) articles for more details.
+* If you provision throughput on a container, the throughput is guaranteed for that container, backed by the SLA. The choice of a logical partition key is crucial for even distribution of load across all the logical partitions of a container. See [Partitioning](partitioning.md) and [horizontal scaling](partitioning.md) articles for more details.
 
 The following are some guidelines to decide on a provisioned throughput strategy:
 
diff --git a/articles/cosmos-db/partitioning.md b/articles/cosmos-db/partitioning.md
@@ -67,19 +67,19 @@ If you assign a throughput of 18,000 request units per second (RU/s), each of th
 
 ## Managing logical partitions
 
-Azure Cosmos DB automatically manages the placement of logical partitions on physical partitions to meet the scalability and performance needs of the container. When the throughput and storage requirements of an application increase, Azure Cosmos DB moves logical partitions to spread the load across more physical partitions. Learn more about [physical partitions](partitioning-overview.md#physical-partitions).
+Azure Cosmos DB automatically manages the placement of logical partitions on physical partitions to meet the scalability and performance needs of the container. When the throughput and storage requirements of an application increase, Azure Cosmos DB moves logical partitions to spread the load across more physical partitions. Learn more about [physical partitions](partitioning.md#physical-partitions).
 
 Azure Cosmos DB uses hash-based partitioning to distribute logical partitions across physical partitions. Azure Cosmos DB hashes the partition key value of an item. The hashed result determines the logical partition. Then, Azure Cosmos DB allocates the key space of partition key hashes evenly across the physical partitions.
 
 Transactions in stored procedures or triggers are allowed only for items in a single logical partition.
 
 ## Replica sets
 
-Each physical partition consists of a set of replicas, also called a [*replica set*](global-dist-under-the-hood.md). Each replica hosts an instance of the database engine. A replica set makes the data store within the physical partition durable, highly available, and consistent. Each replica in the physical partition inherits the partition's storage quota. All replicas of a physical partition collectively support the throughput allocated to that physical partition. Azure Cosmos DB automatically manages replica sets.
+Each physical partition consists of a set of replicas, also called a [*replica set*](global-distribution.md). Each replica hosts an instance of the database engine. A replica set makes the data store within the physical partition durable, highly available, and consistent. Each replica in the physical partition inherits the partition's storage quota. All replicas of a physical partition collectively support the throughput allocated to that physical partition. Azure Cosmos DB automatically manages replica sets.
 
 Smaller containers usually require a single physical partition, but they still have at least four replicas.
 
-This image shows how logical partitions map to physical partitions distributed globally. [Partition set](global-dist-under-the-hood.md#partition-sets) in the image refers to a group of physical partitions that manage the same logical partition keys across multiple regions:
+This image shows how logical partitions map to physical partitions distributed globally. [Partition set](global-distribution.md#partition-sets) in the image refers to a group of physical partitions that manage the same logical partition keys across multiple regions:
 
 :::image type="content" source="./media/partitioning-overview/logical-partitions.png" alt-text="Diagram that shows Azure Cosmos DB partitioning." border="false":::
 
@@ -165,7 +165,7 @@ The *item ID* is a great partition key choice for the following reasons:
 Consider the following caveats when selecting the *item ID* as the partition key:
 
 * If the *item ID* is the partition key, it becomes a unique identifier for your entire container. You can't create items with duplicate *identifiers*.
-* If you have a read-heavy container with many [physical partitions](partitioning-overview.md#physical-partitions), queries are more efficient if they have an equality filter with the *item ID*.
+* If you have a read-heavy container with many [physical partitions](partitioning.md#physical-partitions), queries are more efficient if they have an equality filter with the *item ID*.
 * Stored procedures or triggers can't target multiple logical partitions.
 
 ## Related content
diff --git a/articles/cosmos-db/performance-levels.md b/articles/cosmos-db/performance-levels.md
@@ -129,6 +129,6 @@ EA customers will be price protected until the end of their current contract.
 ## Next steps
 To learn more about pricing and managing data with Azure Cosmos DB, explore these resources:
 
-1.	[Partitioning data in Azure Cosmos DB](partitioning-overview.md). Understand the difference between single partition container and partitioned containers, as well as tips on implementing a partitioning strategy to scale seamlessly.
+1.	[Partitioning data in Azure Cosmos DB](partitioning.md). Understand the difference between single partition container and partitioned containers, as well as tips on implementing a partitioning strategy to scale seamlessly.
 2.	[Azure Cosmos DB pricing](https://azure.microsoft.com/pricing/details/cosmos-db/). Learn about the cost of provisioning throughput and consuming storage.
 3.	[Request units](request-units.md). Understand the consumption of throughput for different operation types, for example Read, Write, Query.
diff --git a/articles/cosmos-db/performance-tips-async-java.md b/articles/cosmos-db/performance-tips-async-java.md
@@ -313,4 +313,4 @@ So if you're asking "How can I improve my database performance?" consider the fo
 
 ## Next steps
 
-To learn more about designing your application for scale and high performance, see [Partitioning and scaling in Azure Cosmos DB](partitioning-overview.md).
+To learn more about designing your application for scale and high performance, see [Partitioning and scaling in Azure Cosmos DB](partitioning.md).
diff --git a/articles/cosmos-db/performance-tips-dotnet-sdk-v3.md b/articles/cosmos-db/performance-tips-dotnet-sdk-v3.md
@@ -482,4 +482,4 @@ The request charge (that is, the request-processing cost) of a specified operati
 ## Next steps
 
 - [Measure Azure Cosmos DB for NoSQL performance with a benchmarking framework](benchmarking-framework.md)
-- [Partitioning and horizontal scaling in Azure Cosmos DB](partitioning-overview.md)
+- [Partitioning and horizontal scaling in Azure Cosmos DB](partitioning.md)
diff --git a/articles/cosmos-db/performance-tips-java-sdk-v4.md b/articles/cosmos-db/performance-tips-java-sdk-v4.md
@@ -528,7 +528,7 @@ The request charge (the request processing cost) of a given operation is directl
 
 ## Next steps
 
-To learn more about designing your application for scale and high performance, see [Partitioning and scaling in Azure Cosmos DB](partitioning-overview.md).
+To learn more about designing your application for scale and high performance, see [Partitioning and scaling in Azure Cosmos DB](partitioning.md).
 
 Trying to do capacity planning for a migration to Azure Cosmos DB? You can use information about your existing database cluster for capacity planning.
 * If all you know is the number of vCores and servers in your existing database cluster, read about [estimating request units using vCores or vCPUs](convert-vcore-to-request-unit.md) 
diff --git a/articles/cosmos-db/performance-tips-java.md b/articles/cosmos-db/performance-tips-java.md
@@ -194,4 +194,4 @@ So if you're asking "How can I improve my database performance?" consider the fo
     The request charge (the request processing cost) of a given operation is directly correlated to the size of the document. Operations on large documents cost more than operations for small documents.
 
 ## Next steps
-To learn more about designing your application for scale and high performance, see [Partitioning and scaling in Azure Cosmos DB](partitioning-overview.md).
+To learn more about designing your application for scale and high performance, see [Partitioning and scaling in Azure Cosmos DB](partitioning.md).
diff --git a/articles/cosmos-db/performance-tips-python-sdk.md b/articles/cosmos-db/performance-tips-python-sdk.md
@@ -300,7 +300,7 @@ The request charge (the request processing cost) of a given operation is directl
 
 ## Next steps
 
-To learn more about designing your application for scale and high performance, see [Partitioning and scaling in Azure Cosmos DB](partitioning-overview.md).
+To learn more about designing your application for scale and high performance, see [Partitioning and scaling in Azure Cosmos DB](partitioning.md).
 
 Trying to do capacity planning for a migration to Azure Cosmos DB? You can use information about your existing database cluster for capacity planning.
 * If all you know is the number of vCores and servers in your existing database cluster, read about [estimating request units using vCores or vCPUs](convert-vcore-to-request-unit.md) 
diff --git a/articles/cosmos-db/performance-tips-query-sdk.md b/articles/cosmos-db/performance-tips-query-sdk.md
@@ -51,7 +51,7 @@ Here are a few examples of simple single partition queries that can benefit from
 - SELECT * FROM r WHERE r.id > 5 OFFSET 5 LIMIT 3 
 ```
 
-There can be cases where single partition queries might still require distribution if the number of data items increases over time and your Azure Cosmos DB database [splits the partition](partitioning-overview.md#physical-partitions). Examples of queries where this could occur include:
+There can be cases where single partition queries might still require distribution if the number of data items increases over time and your Azure Cosmos DB database [splits the partition](partitioning.md#physical-partitions). Examples of queries where this could occur include:
 
 ```
 - SELECT Count(r.id) AS count_a FROM r
@@ -143,7 +143,7 @@ IDocumentQuery<dynamic> query = client.CreateDocumentQuery(
 ---
 
 > [!NOTE]
-> Cross-partition queries require the SDK to visit all existing partitions to check for results. The more [physical partitions](partitioning-overview.md#physical-partitions) the container has, the slower they can potentially be.
+> Cross-partition queries require the SDK to visit all existing partitions to check for results. The more [physical partitions](partitioning.md#physical-partitions) the container has, the slower they can potentially be.
 
 ### Avoid recreating the iterator unnecessarily
 
@@ -344,7 +344,7 @@ CosmosPagedFlux<MyItem> filteredItems =
 ```
 
 > [!NOTE]
-> Cross-partition queries require the SDK to visit all existing partitions to check for results. The more [physical partitions](partitioning-overview.md#physical-partitions) the container has, the slowed they can potentially be.
+> Cross-partition queries require the SDK to visit all existing partitions to check for results. The more [physical partitions](partitioning.md#physical-partitions) the container has, the slowed they can potentially be.
 
 ## Tune the degree of parallelism
 
diff --git a/articles/cosmos-db/performance-tips.md b/articles/cosmos-db/performance-tips.md
@@ -277,4 +277,4 @@ The request charge (that is, the request-processing cost) of a given operation c
 
 For a sample application that's used to evaluate Azure Cosmos DB for high-performance scenarios on a few client machines, see [Performance and scale testing with Azure Cosmos DB](performance-testing.md).
 
-To learn more about designing your application for scale and high performance, see [Partitioning and scaling in Azure Cosmos DB](partitioning-overview.md).
+To learn more about designing your application for scale and high performance, see [Partitioning and scaling in Azure Cosmos DB](partitioning.md).
