address comments

Author: timsander1

articles/cosmos-db/partition-data.md

@@ -1,31 +1,29 @@
 ---
 title: Partitioning and horizontal scaling in Azure Cosmos DB
 description: Learn about how partitioning works in Azure Cosmos DB, how to configure partitioning and partition keys, and how to choose the right partition key for your application.
-author: markjbrown
-ms.author: mjbrown
+author: deborahc
+ms.author: dech
 ms.service: cosmos-db
 ms.topic: conceptual
-ms.date: 04/24/2020
+ms.date: 04/28/2020
 
 ---
 
 # Partitioning and horizontal scaling in Azure Cosmos DB
 
-This article explains the difference between logical and physical partitions. It also discusses best practices for partitioning and gives an in-depth view at how horizontal scaling works in Azure Cosmos DB. It's not necessary to understand these internal details to [select your partition key](partitioning-overview.md#choose-partitionkey) but we have covered them so you have clarity for how Azure Cosmos DB works.
+This article explains the relationship between logical and physical partitions. It also discusses best practices for partitioning and gives an in-depth view at how horizontal scaling works in Azure Cosmos DB. It's not necessary to understand these internal details to [select your partition key](partitioning-overview.md#choose-partitionkey) but we have covered them so you have clarity for how Azure Cosmos DB works.
 
 ## Logical partitions
 
 A logical partition consists of a set of items that have the same partition key. For example, in a container that contains data about food nutrition, all items contain a `foodGroup` property. You can use `foodGroup` as the partition key for the container. Groups of items that have specific values for `foodGroup`, such as `Beef Products`,`Baked Products`, and `Sausages and Luncheon Meats`, form distinct logical partitions. You don't have to worry about deleting a logical partition when the underlying data is deleted.
 
 A logical partition also defines the scope of database transactions. You can update items within a logical partition by using a [transaction with snapshot isolation](database-transactions-optimistic-concurrency.md). When new items are added to a container, new logical partitions are transparently created by the system.
 
-In Azure Cosmos DB, a container is the fundamental unit of scalability. Data that's added to the container and the throughput that you provision on the container are automatically (horizontally) partitioned across a set of logical partitions. For more information, see [Create an Azure Cosmos container](how-to-create-container.md).
-
-There is no limit to the number of logical partitions in your container. Each logical partition can store up to 20GB of data. Good partition key choices have a wide range of possible values. For example, in a container where all items contain a `foodGroup`property, the data within the `Beef Products` logical partition can grow up to 20GB. Selecting a partition key with a wide range of possible values ensures that the container is able to scale.
+There is no limit to the number of logical partitions in your container. Each logical partition can store up to 20GB of data. Good partition key choices have a wide range of possible values. For example, in a container where all items contain a `foodGroup`property, the data within the `Beef Products` logical partition can grow up to 20GB. [Selecting a partition key](partitioning-overview.md#choose-partitionkey) with a wide range of possible values ensures that the container is able to scale.
 
 ## Physical partitions
 
-An Azure Cosmos container is scaled by distributing data and throughput across physical partitions. Internally, one or more logical partitions are mapped to a single physical partition. Most small Cosmos containers have many logical partitions but only require a single physical partition. Unlike logical partitions, physical partitions are an internal implementation of the system.
+An Azure Cosmos container is scaled by distributing data and throughput across physical partitions. Internally, one or more logical partitions are mapped to a single physical partition. Most small Cosmos containers have many logical partitions but only require a single physical partition. Unlike logical partitions, physical partitions are an internal implementation of the system and they are entirely managed by Azure Cosmos DB.
 
 The number of physical partitions in your Cosmos container depends on the following:
 
@@ -48,6 +46,8 @@ If we provision a throughput of 18,000 request units per second (RU/s), then eac
 
 Each physical partition consists of a set of replicas, also referred to as a [*replica set*](global-dist-under-the-hood.md). Each replica set hosts an instance of the Azure Cosmos database engine. A replica set makes the data stored within the physical partition durable, highly available, and consistent. Each replica that makes up the physical partition inherits the partition's storage quota. All replicas of a physical partition collectively support the throughput that's allocated to the physical partition. Azure Cosmos DB automatically manages replica sets.
 
+Most small Cosmos containers only require a single physical partition but will still have at least 4 replicas.
+
 The following image shows how logical partitions are mapped to physical partitions that are distributed globally:
 
 ![An image that demonstrates Azure Cosmos DB partitioning](./media/partition-data/logical-partitions.png)

articles/cosmos-db/partitioning-overview.md

@@ -1,11 +1,11 @@
 ---
 title: Partitioning in Azure Cosmos DB
 description: Learn about partitioning in Azure Cosmos DB, best practices when choosing a partition key, and how to manage logical partitions
-author: markjbrown
-ms.author: mjbrown
+author: deborahc
+ms.author: dech
 ms.service: cosmos-db
 ms.topic: conceptual
-ms.date: 04/24/2020
+ms.date: 04/28/2020
 
 ---
 
@@ -58,6 +58,8 @@ If your container could grow to more than a few physical partitions, then you sh
 
 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 system property *item ID* is guaranteed to exist in every item in your Cosmos container. You may have other properties in your document that represent a logical id of your item. In many cases, these are also great partition key choices for the same reasons as the *item ID*.
+
 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).
@@ -67,7 +69,7 @@ The *item ID* is a great partition key choice for the following reasons:
 Some things to consider when selecting the *item ID* as the partition key include:
 
 * If the *item ID* is the partition key, it will become a unique identifier throughout your entire container. You won't be able to have items that have a duplicate *item ID*.
-* If you have a read-heavy container that has a lot of [physical partitions](partition-data.md#physical-partitions), all of your queries will be cross-partition
+* If you have a read-heavy container that has a lot of [physical partitions](partition-data.md#physical-partitions), queries will be more efficient if they have an equality filter with the *item ID*.
 * You can't run stored procedures or triggers across multiple logical partitions.
 
 ## Next steps