Fix broken links (3/5)

Author: seesharprun

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?
 

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)

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)

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)

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:**
 

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)

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/)

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)

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:
 

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