Merge pull request #4286 from seesharprun/cosmos-db-fix-broken-links-2

prmerger-automator[bot] · web-flow · commit 186e50920b41 · 2026-02-02T18:06:44.000Z
Cosmos DB | Fix broken links (2/5)
diff --git a/articles/cosmos-db/change-feed-pull-model.md b/articles/cosmos-db/change-feed-pull-model.md
@@ -149,7 +149,7 @@ Here's an example that shows how to get a list of ranges for your container:
 IReadOnlyList<FeedRange> ranges = await container.GetFeedRangesAsync();
 ```
 
-When you get a list of `FeedRange` values for your container, you get one `FeedRange` per [physical partition](partitioning-overview.md#physical-partitions).
+When you get a list of `FeedRange` values for your container, you get one `FeedRange` per [physical partition](partitioning.md#physical-partitions).
 
 By using a `FeedRange`, you can create a `FeedIterator` to parallelize the processing of the change feed across multiple machines or threads. Unlike the previous example that showed how to obtain a `FeedIterator` for the entire container or a single partition key, you can use FeedRanges to obtain multiple FeedIterators, which can process the change feed in parallel.
 
@@ -280,7 +280,7 @@ Here's an example that uses latest version mode showing how to obtain a list of
 
 [!code-java[](~/azure-cosmos-java-sql-api-samples/src/main/java/com/azure/cosmos/examples/changefeedpull/SampleChangeFeedPullModel.java?name=GetFeedRanges)]
 
-When you obtain of list of FeedRanges for your container, you get one `FeedRange` per [physical partition](partitioning-overview.md#physical-partitions).
+When you obtain of list of FeedRanges for your container, you get one `FeedRange` per [physical partition](partitioning.md#physical-partitions).
 
 By using a `FeedRange`, you can parallelize the processing the change feed across multiple machines or threads. Unlike the previous example that showed how to process changes for the entire container or a single partition key, you can use FeedRanges to process the change feed in parallel.
 
@@ -367,7 +367,7 @@ rangesIterator = container.read_feed_ranges(force_refresh=False)
 ranges = list(rangesIterator)
 ```
 
-When you get a list of `feed_range` values for your container, you get one `feed_range` per [physical partition](partitioning-overview.md#physical-partitions).
+When you get a list of `feed_range` values for your container, you get one `feed_range` per [physical partition](partitioning.md#physical-partitions).
 
 By using a `feed_range`, you can create iterator to parallelize the processing of the change feed across multiple machines or threads.
 Unlike the previous example that showed how to obtain a `responseIterator` for the entire container or a single partition key, you can use `feed_range` to obtain multiple iterators, which can process the change feed in parallel.
@@ -506,7 +506,7 @@ Here's an example that shows how to get a list of ranges for your container:
 const ranges = await container.getFeedRanges();
 ```
 
-When you get a list of `FeedRange` values for your container, you get one `FeedRange` per [physical partition](partitioning-overview.md#physical-partitions).
+When you get a list of `FeedRange` values for your container, you get one `FeedRange` per [physical partition](partitioning.md#physical-partitions).
 
 By using a `FeedRange`, you can create iterator to parallelize the processing of the change feed across multiple machines or threads. Unlike the previous example that showed how to obtain a change feed iterator for the entire container or a single partition key, you can use FeedRanges to obtain multiple iterators, which can process the change feed in parallel.
 
diff --git a/articles/cosmos-db/concepts-limits.md b/articles/cosmos-db/concepts-limits.md
@@ -330,4 +330,4 @@ In addition to the previous table, the [per-account limits](#per-account-limits)
 ## Related content
 
 * [Global distribution](distribute-data-globally.md)
-* [Partitioning](partitioning-overview.md) and [provisioned throughput](request-units.md)
+* [Partitioning](partitioning.md) and [provisioned throughput](request-units.md)
diff --git a/articles/cosmos-db/conceptual-resilient-sdk-applications.md b/articles/cosmos-db/conceptual-resilient-sdk-applications.md
@@ -24,7 +24,7 @@ For a video overview of the concepts discussed in this article, see:
 
 Azure Cosmos DB SDKs can connect to the service in two [connectivity modes](sdk-connection-modes.md). The .NET and Java SDKs can connect to the service in either *Gateway* or *Direct* mode, while the others can only connect in Gateway mode. Gateway mode uses the HTTP protocol, and Direct mode typically uses the TCP protocol.
 
-Gateway mode is always used to fetch metadata such as the account, container, and routing information regardless of which mode SDK is configured for use. This information is cached in memory and is used to connect to the [service replicas](partitioning-overview.md#replica-sets).
+Gateway mode is always used to fetch metadata such as the account, container, and routing information regardless of which mode SDK is configured for use. This information is cached in memory and is used to connect to the [service replicas](partitioning.md#replica-sets).
 
 In summary, for SDKs in Gateway mode, you can expect HTTP traffic, while for SDKs in Direct mode, you can expect a combination of HTTP and TCP traffic under different circumstances, such as initialization, fetching metadata, or routing information.
 
diff --git a/articles/cosmos-db/container-copy.md b/articles/cosmos-db/container-copy.md
@@ -20,7 +20,7 @@ You might need to copy data from your Azure Cosmos DB account if you want to ach
 
 * Copy all items from one container to another.
 * Change the [granularity at which throughput is provisioned, from database to container](set-throughput.md) and vice versa.
-* Change the [partition key](partitioning-overview.md#choose-a-partition-key) of a container.
+* Change the [partition key](partitioning.md#choose-a-partition-key) of a container.
 * Update the [unique keys](unique-keys.md) for a container.
 * Rename a container or database.
 * Change capacity mode of an account from serverless to provisioned or vice-versa.
diff --git a/articles/cosmos-db/continuous-backup-restore-introduction.md b/articles/cosmos-db/continuous-backup-restore-introduction.md
@@ -192,4 +192,4 @@ Currently the point-in-time restore functionality has the following limitations:
 * [Resource model for the Azure Cosmos DB point-in-time restore](continuous-backup-restore-resource-model.md)
 * [Understanding multi-region writes in Azure Cosmos DB](multi-region-writes.md)
 * [Understanding timestamps in Cosmos DB](multi-region-writes.md#understanding-timestamps)
-* [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)
diff --git a/articles/cosmos-db/convert-vcore-to-request-unit.md b/articles/cosmos-db/convert-vcore-to-request-unit.md
@@ -14,7 +14,7 @@ appliesto:
 
 # Convert the number of vCores or vCPUs in your nonrelational database to Azure Cosmos DB RU/s
 
-This article explains how to estimate Azure Cosmos DB request units (RU/s) when you are considering data migration but all you know is the total vCore or vCPU count in your existing database replica set(s). When you migrate one or more replica sets to Azure Cosmos DB, each collection held in those replica sets will be stored as an Azure Cosmos DB collection consisting of a sharded cluster with a 4x replication factor. You can read more about our architecture in this [partitioning and scaling guide](partitioning-overview.md). Request units are how throughput capacity is provisioned on a collection; you can [read the request units guide](request-units.md) and the RU/s [provisioning guide](set-throughput.md) to learn more. When you migrate a collection, Azure Cosmos DB provisions enough shards to serve your provisioned request units and store your data. Therefore estimating RU/s for collections is an important step in scoping out the scale of your planned Azure Cosmos DB data estate prior to migration. Based on our experience with thousands of customers, we have found this formula helps us arrive at a rough starting-point RU/s estimate from vCores or vCPUs: 
+This article explains how to estimate Azure Cosmos DB request units (RU/s) when you are considering data migration but all you know is the total vCore or vCPU count in your existing database replica set(s). When you migrate one or more replica sets to Azure Cosmos DB, each collection held in those replica sets will be stored as an Azure Cosmos DB collection consisting of a sharded cluster with a 4x replication factor. You can read more about our architecture in this [partitioning and scaling guide](partitioning.md). Request units are how throughput capacity is provisioned on a collection; you can [read the request units guide](request-units.md) and the RU/s [provisioning guide](set-throughput.md) to learn more. When you migrate a collection, Azure Cosmos DB provisions enough shards to serve your provisioned request units and store your data. Therefore estimating RU/s for collections is an important step in scoping out the scale of your planned Azure Cosmos DB data estate prior to migration. Based on our experience with thousands of customers, we have found this formula helps us arrive at a rough starting-point RU/s estimate from vCores or vCPUs: 
 
 `
 Provisioned RU/s = C*T/R
diff --git a/articles/cosmos-db/couchbase-cosmos-migration.md b/articles/cosmos-db/couchbase-cosmos-migration.md
@@ -33,7 +33,7 @@ The following are the key features that work differently in Azure Cosmos DB when
 
 * Azure Cosmos DB has an "ID" field within the document whereas Couchbase has the ID as a part of bucket. The "ID" field is unique across the partition.
 
-* Azure Cosmos DB scales by using the partitioning or sharding technique. Which means it splits the data into multiple shards/partitions. These partitions/shards are created based on the partition key property that you provide. You can select the partition key to optimize read as well write operations or read/write optimized too. To learn more, see the [partitioning](partitioning-overview.md) article.
+* Azure Cosmos DB scales by using the partitioning or sharding technique. Which means it splits the data into multiple shards/partitions. These partitions/shards are created based on the partition key property that you provide. You can select the partition key to optimize read as well write operations or read/write optimized too. To learn more, see the [partitioning](partitioning.md) article.
 
 * In Azure Cosmos DB, it isn't required for the top-level hierarchy to denote the collection because the collection name already exists. This feature makes the JSON structure simpler. The following is an example that shows differences in the data model between Couchbase and Azure Cosmos DB:
 
diff --git a/articles/cosmos-db/database-transactions-optimistic-concurrency.md b/articles/cosmos-db/database-transactions-optimistic-concurrency.md
@@ -17,7 +17,7 @@ Database transactions provide a safe and predictable programming model to deal w
 
 With traditional relational databases, you're required to deal with two different programming languages: a nontransactional application programming language, such as JavaScript, Python, C#, or Java; and a transactional programming language, such as T-SQL, that's natively executed by the database.
 
-The database engine in Azure Cosmos DB supports full ACID (atomicity, consistency, isolation, durability) compliant transactions with snapshot isolation. All the database operations within the scope of a container's [logical partition](partitioning-overview.md) are transactionally executed within the database engine that's hosted by the replica of the partition. These operations include both write (updating one or more items within the logical partition) and read operations.
+The database engine in Azure Cosmos DB supports full ACID (atomicity, consistency, isolation, durability) compliant transactions with snapshot isolation. All the database operations within the scope of a container's [logical partition](partitioning.md) are transactionally executed within the database engine that's hosted by the replica of the partition. These operations include both write (updating one or more items within the logical partition) and read operations.
 
 The following table lists different operations and transaction types:
 
diff --git a/articles/cosmos-db/design-partitioning-iot.md b/articles/cosmos-db/design-partitioning-iot.md
@@ -128,4 +128,4 @@ By using DeviceId +Time-based-key (Date + Hour + Minute) as a hierarchical parti
 > - We recommend  adding ID as the last level of your hierarchical partition key to ensure you never reach the 20-GB limit for a logical partition key.
 -   Optimize our most common query patterns that frequently filter by DeviceId and Date/Hour/Minute, minimizing cross-partition queries and reducing RU costs.
 
-For more information on how partitioning works in Azure Cosmos DB, you can learn more [here](partitioning-overview.md).
+For more information on how partitioning works in Azure Cosmos DB, you can learn more [here](partitioning.md).
diff --git a/articles/cosmos-db/distribute-data-globally.md b/articles/cosmos-db/distribute-data-globally.md
@@ -62,7 +62,7 @@ With Azure Cosmos DB, you can add or remove the regions associated with your acc
 
 ## <a id="Next Steps"></a>Next steps
 
-* [Global distribution - under the hood](global-dist-under-the-hood.md)
+* [Global distribution - under the hood](global-distribution.md)
 * [How to configure multi-region writes in your applications](how-to-multi-master.md)
 * [Configure multiple write-regions](how-to-manage-database-account.yml#configure-multiple-write-regions)
 * [Add or remove regions from your Azure Cosmos DB account](how-to-manage-database-account.yml#add-remove-regions-from-your-database-account)
diff --git a/articles/cosmos-db/fleet-pools.md b/articles/cosmos-db/fleet-pools.md
@@ -112,7 +112,7 @@ You can also monitor pooled RU/s consumption at the account level in Azure porta
 
 ## Default limitations
 
-With the pooling feature, the total RU/s available for consumption to each physical partition is still subject to standard [physical partition limits](partitioning-overview.md#physical-partitions). Each **physical partition** has limits on how much extra RU/s it can draw from the pool. 
+With the pooling feature, the total RU/s available for consumption to each physical partition is still subject to standard [physical partition limits](partitioning.md#physical-partitions). Each **physical partition** has limits on how much extra RU/s it can draw from the pool. 
 
 In the preview:
 
diff --git a/articles/cosmos-db/global-distribution.md b/articles/cosmos-db/global-distribution.md
@@ -19,7 +19,7 @@ appliesto:
 
 Azure Cosmos DB is a foundational service in Azure, so it's deployed across all Azure regions worldwide including the public, sovereign, Department of Defense (DoD) and government clouds.
 
-At a high level, Azure Cosmos DB container data is [horizontally partitioned](partitioning-overview.md) into many replica-sets, which replicate writes, in each region. Replica-sets durably commit writes using a majority quorum.
+At a high level, Azure Cosmos DB container data is [horizontally partitioned](partitioning.md) into many replica-sets, which replicate writes, in each region. Replica-sets durably commit writes using a majority quorum.
 
 Each region contains all the data partitions of an Azure Cosmos DB container and can serve reads as well as serve writes when multi-region writes is enabled. If your Azure Cosmos DB account is distributed across *N* Azure regions, there will be at least *N* x 4 copies of all your data.
 
@@ -57,7 +57,7 @@ A physical partition is materialized as a self-managed and dynamically load-bala
 
 - Secondly, as far as possible, the read quorum for a given consistency level is composed exclusively of the follower replicas. We avoid contacting the leader for serving reads unless  required. We employ a number of ideas from the research done on the relationship of [load and capacity](https://www.cs.utexas.edu/~lorenzo/corsi/cs395t/04S/notes/naor98load.pdf) in the quorum-based systems for the [five consistency models](consistency-levels.md) that Azure Cosmos DB supports.  
 
-For more information about replica sets and how they relate to physical partitions, see [partition replica sets](partitioning-overview.md#replica-sets).
+For more information about replica sets and how they relate to physical partitions, see [partition replica sets](partitioning.md#replica-sets).
 
 ## Partition-sets
 
diff --git a/articles/cosmos-db/hierarchical-partition-keys.md b/articles/cosmos-db/hierarchical-partition-keys.md
@@ -39,7 +39,7 @@ When you choose each level of your hierarchical partition key, it's important to
 
 - **Read-heavy workloads:** We recommend that you choose hierarchical partition keys that appear frequently in your queries. 
 
-  - For example, a workload that frequently runs queries to filter out specific user sessions in a multitenant application can benefit from hierarchical partition keys of `TenantId`, `UserId`, and `SessionId`, in that order. Queries can be efficiently routed to only the relevant physical partitions by including the partition key in the filter predicate. For more information about choosing partition keys for read-heavy workloads, see the [partitioning overview](partitioning-overview.md).
+  - For example, a workload that frequently runs queries to filter out specific user sessions in a multitenant application can benefit from hierarchical partition keys of `TenantId`, `UserId`, and `SessionId`, in that order. Queries can be efficiently routed to only the relevant physical partitions by including the partition key in the filter predicate. For more information about choosing partition keys for read-heavy workloads, see the [partitioning overview](partitioning.md).
 
 - **Write-heavy workloads:** We recommend using a high cardinal value for the **first level** of your hierarchical partition key. High cardinality means that the first-level key (and subsequent levels as well) has at least thousands of unique values and more unique values than the number of your physical partitions.
 
@@ -67,7 +67,7 @@ When using hierarchical partition keys, you can add the item ID as the last leve
 
 For example, in a multitenant workload partitioned by `TenantId` and `UserId`, if a single combination of these values might exceed 20 GB, add a third-level key with high cardinality. A GUID is a good choice because the combination of `TenantId`, `UserId`, and a GUID is unlikely to exceed 20 GB, allowing the `TenantId` and `UserId` combination to effectively scale beyond 20 GB.
 
-For comprehensive guidance on why item ID is an effective partition key choice (high cardinality, even distribution, and efficient point reads), see [Use item ID as the partition key](partitioning-overview.md#use-item-id-as-the-partition-key) in the partitioning overview.
+For comprehensive guidance on why item ID is an effective partition key choice (high cardinality, even distribution, and efficient point reads), see [Use item ID as the partition key](partitioning.md#use-item-id-as-the-partition-key) in the partitioning overview.
 
 ## Get started
 
@@ -808,5 +808,5 @@ for pager.More() {
 ## Next steps
 
 - [Frequently asked questions on hierarchical partition keys in Azure Cosmos DB](hierarchical-partition-keys-faq.yml)
-- [Partitioning and horizontal scaling in Azure Cosmos DB](partitioning-overview.md)
+- [Partitioning and horizontal scaling in Azure Cosmos DB](partitioning.md)
 - [Azure Resource Manager templates with Microsoft.DocumentDB databaseAccounts](/azure/templates/microsoft.documentdb/databaseaccounts?pivots=deployment-language-arm-template)
diff --git a/articles/cosmos-db/how-to-create-container.md b/articles/cosmos-db/how-to-create-container.md
@@ -78,7 +78,7 @@ Container container = await database.CreateContainerIfNotExistsAsync(containerPr
 
 ## 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/how-to-define-unique-keys.md b/articles/cosmos-db/how-to-define-unique-keys.md
@@ -177,5 +177,5 @@ _, err = db.CreateContainer(context.Background(), azcosmos.ContainerProperties{
 
 ## Next steps
 
-- Learn more about [partitioning](partitioning-overview.md)
+- Learn more about [partitioning](partitioning.md)
 - Explore [how indexing works](index-overview.md)
diff --git a/articles/cosmos-db/how-to-manage-conflicts.md b/articles/cosmos-db/how-to-manage-conflicts.md
@@ -532,10 +532,10 @@ while conflict:
 
 Learn about the following Azure Cosmos DB concepts:
 
-- [Global distribution - under the hood](global-dist-under-the-hood.md)
+- [Global distribution - under the hood](global-distribution.md)
 - [How to configure multi-region writes in your applications](how-to-multi-master.md)
 - [Configure clients for multihoming](how-to-manage-database-account.yml#configure-multiple-write-regions)
 - [Add or remove regions from your Azure Cosmos DB account](how-to-manage-database-account.yml#add-remove-regions-from-your-database-account)
 - [How to configuremulti-region writes in your applications](how-to-multi-master.md).
-- [Partitioning and data distribution](partitioning-overview.md)
+- [Partitioning and data distribution](partitioning.md)
 - [Indexing in Azure Cosmos DB](index-policy.md)
diff --git a/articles/cosmos-db/how-to-manage-consistency.md b/articles/cosmos-db/how-to-manage-consistency.md
diff --git a/articles/cosmos-db/how-to-query-container.md b/articles/cosmos-db/how-to-query-container.md

Original file line number	Diff line number	Diff line change
`@@ -14,7 +14,7 @@ appliesto:`
`14`	`14`
`15`	`15`	`# Convert the number of vCores or vCPUs in your nonrelational database to Azure Cosmos DB RU/s`
`16`	`16`
`17`		-This article explains how to estimate Azure Cosmos DB request units (RU/s) when you are considering data migration but all you know is the total vCore or vCPU count in your existing database replica set(s). When you migrate one or more replica sets to Azure Cosmos DB, each collection held in those replica sets will be stored as an Azure Cosmos DB collection consisting of a sharded cluster with a 4x replication factor. You can read more about our architecture in this [partitioning and scaling guide](partitioning-overview.md). Request units are how throughput capacity is provisioned on a collection; you can [read the request units guide](request-units.md) and the RU/s [provisioning guide](set-throughput.md) to learn more. When you migrate a collection, Azure Cosmos DB provisions enough shards to serve your provisioned request units and store your data. Therefore estimating RU/s for collections is an important step in scoping out the scale of your planned Azure Cosmos DB data estate prior to migration. Based on our experience with thousands of customers, we have found this formula helps us arrive at a rough starting-point RU/s estimate from vCores or vCPUs:
	`17`	+This article explains how to estimate Azure Cosmos DB request units (RU/s) when you are considering data migration but all you know is the total vCore or vCPU count in your existing database replica set(s). When you migrate one or more replica sets to Azure Cosmos DB, each collection held in those replica sets will be stored as an Azure Cosmos DB collection consisting of a sharded cluster with a 4x replication factor. You can read more about our architecture in this [partitioning and scaling guide](partitioning.md). Request units are how throughput capacity is provisioned on a collection; you can [read the request units guide](request-units.md) and the RU/s [provisioning guide](set-throughput.md) to learn more. When you migrate a collection, Azure Cosmos DB provisions enough shards to serve your provisioned request units and store your data. Therefore estimating RU/s for collections is an important step in scoping out the scale of your planned Azure Cosmos DB data estate prior to migration. Based on our experience with thousands of customers, we have found this formula helps us arrive at a rough starting-point RU/s estimate from vCores or vCPUs:
`18`	`18`
`19`	`19`	`
`20`	`20`	`Provisioned RU/s = C*T/R`