Merge pull request #104391 from HeidiSteen/heidist-toc

[Azure Cognitive Search]  Scale/performance TOC and doc updates

Author: PMEds28

articles/search/TOC.yml

@@ -105,9 +105,9 @@
       href: search-sku-tier.md
     - name: Service limits
       href: search-limits-quotas-capacity.md
-    - name: Scale partitions and replicas
+    - name: Adjust capacity
       href: search-capacity-planning.md
-    - name: Deployment strategies and best practices
+    - name: Scale for performance
       href: search-performance-optimization.md
     - name: Multitenant architecture
       href: search-modeling-multitenant-saas-applications.md

articles/search/search-capacity-planning.md

@@ -1,5 +1,5 @@
 ---
-title:  Scale capacity for query and index workloads
+title:  Adjust capacity for query and index workloads
 titleSuffix: Azure Cognitive Search
 description: Adjust partition and replica computer resources in Azure Cognitive Search, where each resource is priced in billable search units.
 
@@ -8,68 +8,60 @@ author: HeidiSteen
 ms.author: heidist
 ms.service: cognitive-search
 ms.topic: conceptual
-ms.date: 11/04/2019
+ms.date: 02/14/2020
 ---
 
-# Scale up partitions and replicas to add capacity for query and index workloads in Azure Cognitive Search
+# Adjust capacity in Azure Cognitive Search
 
-After you [choose a pricing tier](search-sku-tier.md) and [provision a search service](search-create-service-portal.md), the next step is to optionally increase the number of replicas or partitions used by your service. Each tier offers a fixed number of billing units. This article explains how to allocate those units to achieve an optimal configuration that balances your requirements for query execution, indexing, and storage.
+Before [provisioning a search service](search-create-service-portal.md) and locking in a specific pricing tier, take a few minutes to understand the role of replicas and partitions in a service, whether you need proportionally larger or faster partitions, and how you might configure the service for expected load.
 
-Resource configuration is available when you set up a service at the [Basic tier](https://aka.ms/azuresearchbasic) or one of the [Standard or Storage Optimized tiers](search-limits-quotas-capacity.md). For services at these tiers, capacity is purchased in increments of *search units* (SUs) where each partition and replica counts as one SU. 
-
-Using fewer SUs results in a proportionally lower bill. Billing is in effect for as long as the service is set up. If you are temporarily not using a service, the only way to avoid billing is by deleting the service and then re-creating it when you need it.
-
-> [!Note]
-> Deleting a service deletes everything on it. There is no facility within Azure Cognitive Search for backing up and restoring persisted search data. To redeploy an existing index on a new service, you should run the program used to create and load it originally. 
+Capacity is a function of the [tier you choose](search-sku-tier.md) (tiers determine hardware characteristics), and the replica and partition combination necessary for projected workloads. This article focuses on replica and partition combinations and interactions.
 
 ## Terminology: replicas and partitions
-Replicas and partitions are the primary resources that back a search service.
 
-| Resource | Definition |
-|----------|------------|
-|*Partitions* | Provides index storage and I/O for read/write operations (for example, when rebuilding or refreshing an index).|
-|*Replicas* | Instances of the search service, used primarily to load balance query operations. Each replica always hosts one copy of an index. If you have 12 replicas, you will have 12 copies of every index loaded on the service.|
+|||
+|-|-|
+|*Partitions* | Provides index storage and I/O for read/write operations (for example, when rebuilding or refreshing an index). Each partition has a share of the total index. If you allocate three partitions, your index is divided into thirds. |
+|*Replicas* | Instances of the search service, used primarily to load balance query operations. Each replica is one copy of an index. If you allocate three replicas, you'll have three copies of an index available for servicing query requests.|
 
-> [!NOTE]
-> There is no way to directly manipulate or manage which indexes run on a replica. One copy of each index on every replica is part of the service architecture.
->
+## How to allocate replicas and partitions
 
+Initially, a service is allocated a minimal level of resources consisting of one partition and one replica. 
 
-## How to allocate replicas and partitions
-In Azure Cognitive Search, a service is initially allocated a minimal level of resources consisting of one partition and one replica. For tiers that support it, you can incrementally adjust computational resources by increasing partitions if you need more storage and I/O, or add more replicas for larger query volumes or better performance. A single service must have sufficient resources to handle all workloads (indexing and queries). You cannot subdivide workloads among multiple services.
+A single service must have sufficient resources to handle all workloads (indexing and queries). Neither workload runs in the background. You can schedule indexing for times when query requests are naturally less frequent, but the service will not otherwise prioritize one task over another.
 
-To increase or change the allocation of replicas and partitions, we recommend using the Azure portal. The portal enforces limits on allowable combinations that stay below maximum limits. If you require a script-based or code-based provisioning approach, the [Azure PowerShell](search-manage-powershell.md) or the [Management REST API](https://docs.microsoft.com/rest/api/searchmanagement/services) are alternative solutions.
+When modifying the allocation of replicas and partitions, we recommend using the Azure portal. The portal enforces limits on allowable combinations that stay below maximum limits of a tier. However, if you require a script-based or code-based provisioning approach, the [Azure PowerShell](search-manage-powershell.md) or the [Management REST API](https://docs.microsoft.com/rest/api/searchmanagement/services) are alternative solutions.
 
-Generally, search applications need more replicas than partitions, particularly when the service operations are biased toward query workloads. The section on [high availability](#HA) explains why.
+As a general rule, search applications tend to need more replicas than partitions, particularly when the service operations are biased toward query workloads. The section on [high availability](#HA) explains why.
 
 1. Sign in to the [Azure portal](https://portal.azure.com/) and select the search service.
 
-2. In **Settings**, open the **Scale** page to modify replicas and partitions. 
+1. In **Settings**, open the **Scale** page to modify replicas and partitions. 
 
    The following screenshot shows a standard service provisioned with one replica and partition. The formula at the bottom indicates how many search units are being used (1). If the unit price was $100 (not a real price), the monthly cost of running this service would be $100 on average.
 
    ![Scale page showing current values](media/search-capacity-planning/1-initial-values.png "Scale page showing current values")
 
-3. Use the slider to increase or decrease the number of partitions. The formula at the bottom indicates how many search units are being used.
+1. Use the slider to increase or decrease the number of partitions. The formula at the bottom indicates how many search units are being used.
 
    This example doubles capacity, with two replicas and partitions each. Notice the search unit count; it is now four because the billing formula is replicas multiplied by partitions (2 x 2). Doubling capacity more than doubles the cost of running the service. If the search unit cost was $100, the new monthly bill would now be $400.
 
    For the current per unit costs of each tier, visit the [Pricing page](https://azure.microsoft.com/pricing/details/search/).
 
    ![Add replicas and partitions](media/search-capacity-planning/2-add-2-each.png "Add replicas and partitions")
 
-3. Click **Save** to confirm the changes.
+1. Click **Save** to confirm the changes.
 
    ![Confirm changes to scale and billing](media/search-capacity-planning/3-save-confirm.png "Confirm changes to scale and billing")
 
    Changes in capacity take several hours to complete. You cannot cancel once the process has started and there is no real-time monitoring for replica and partition adjustments. However, the following message remains visible while changes are underway.
 
    ![Status message in the portal](media/search-capacity-planning/4-updating.png "Status message in the portal")
 
-
 > [!NOTE]
-> After a service is provisioned, it cannot be upgraded to a higher SKU. You must create a search service at the new tier and reload your indexes. See [Create an Azure Cognitive Search service in the portal](search-create-service-portal.md) for help with service provisioning.
+> After a service is provisioned, it cannot be upgraded to a higher tier. You must create a search service at the new tier and reload your indexes. See [Create an Azure Cognitive Search service in the portal](search-create-service-portal.md) for help with service provisioning.
 >
+> Additionally, partitions and replicas are managed exclusively and internally by the service. There is no concept of processor affinity, or assigning a workload to a specific node.
 >
 
 <a id="chart"></a>
@@ -96,10 +88,10 @@ SUs, pricing, and capacity are explained in detail on the Azure website. For mor
 > The number of replicas and partitions divides evenly into 12 (specifically, 1, 2, 3, 4, 6, 12). This is because Azure Cognitive Search pre-divides each index into 12 shards so that it can be spread in equal portions across all partitions. For example, if your service has three partitions and you create an index, each partition will contain four shards of the index. How Azure Cognitive Search shards an index is an implementation detail, subject to change in future releases. Although the number is 12 today, you shouldn't expect that number to always be 12 in the future.
 >
 
-
 <a id="HA"></a>
 
 ## High availability
+
 Because it's easy and relatively fast to scale up, we generally recommend that you start with one partition and one or two replicas, and then scale up as query volumes build. Query workloads run primarily on replicas. If you need more throughput or high availability, you will probably require additional replicas.
 
 General recommendations for high availability are:
@@ -112,31 +104,27 @@ Service level agreements (SLA) for Azure Cognitive Search are targeted at query
 
 Basic tier tops out at one partition and three replicas. If you want the flexibility to immediately respond to fluctuations in demand for both indexing and query throughput, consider one of the Standard tiers.  If you find your storage requirements are growing much more rapidly than your query throughput, consider one of the Storage Optimized tiers.
 
-### Index availability during a rebuild
+## Disaster recovery
 
-High availability for Azure Cognitive Search pertains to queries and index updates that don't involve rebuilding an index. If you delete a field, change a data type, or rename a field, you will need to rebuild the index. To rebuild the index, you must delete the index, re-create the index, and reload the data.
+Currently, there is no built-in mechanism for disaster recovery. Adding partitions or replicas would be the wrong strategy for meeting disaster recovery objectives. The most common approach is to add redundancy at the service level by setting up a second search service in another region. As with availability during an index rebuild, the redirection or failover logic must come from your code.
 
-> [!NOTE]
-> You can add new fields to an Azure Cognitive Search index without rebuilding the index. The value of the new field will be null for all documents already in the index.
+## Estimate replicas
 
-When rebuilding the index there will be a period of time when the data is being added to the new index. If you would like to continue to make your old index available during this time, you must have a copy of the old index with a different name on the same service, or a copy of the index with the same name on a different service, and then provide redirection or failover logic in your code.
+On a production service, you should allocate three replicas for SLA purposes. If you experience slow query performance, one remedy is to add replicas so that additional copies of the index are brought online to support bigger query workloads and to load balance the requests over the multiple replicas.
 
-## Disaster recovery
-Currently, there is no built-in mechanism for disaster recovery. Adding partitions or replicas would be the wrong strategy for meeting disaster recovery objectives. The most common approach is to add redundancy at the service level by setting up a second search service in another region. As with availability during an index rebuild, the redirection or failover logic must come from your code.
+We do not provide guidelines on how many replicas are needed to accommodate query loads. Query performance depends on the complexity of the query and competing workloads. Although adding replicas clearly results in better performance, the result is not strictly linear: adding three replicas does not guarantee triple throughput.
 
-## Increase query performance with replicas
-Query latency is an indicator that additional replicas are needed. Generally, a first step toward improving query performance is to add more of this resource. As you add replicas, additional copies of the index are brought online to support bigger query workloads and to load balance the requests over the multiple replicas.
+For guidance in estimating QPS for your solution, see [Scale for performance](search-performance-optimization.md)and [Monitor queries](search-monitor-queries.md)
 
-We cannot provide hard estimates on queries per second (QPS): query performance depends on the complexity of the query and competing workloads. Although adding replicas clearly results in better performance, the result is not strictly linear: adding three replicas does not guarantee triple throughput.
+## Estimate partitions
 
-For guidance in estimating QPS for your workloads, see [Azure Cognitive Search performance and optimization considerations](search-performance-optimization.md).
+The [tier you choose](search-sku-tier.md) determines partition size and speed, and each tier is optimized around a set of characteristics that fit various scenarios. If you choose a higher-end tier, you might need fewer partitions than if you go with S1.
 
-## Increase indexing performance with partitions
 Search applications that require near real-time data refresh will need proportionally more partitions than replicas. Adding partitions spreads read/write operations across a larger number of compute resources. It also gives you more disk space for storing additional indexes and documents.
 
 Larger indexes take longer to query. As such, you might find that every incremental increase in partitions requires a smaller but proportional increase in replicas. The complexity of your queries and query volume will factor into how quickly query execution is turned around.
 
-
 ## Next steps
 
-[Choose a pricing tier for Azure Cognitive Search](search-sku-tier.md)
+> [!div class="nextstepaction"]
+> [Choose a pricing tier for Azure Cognitive Search](search-sku-tier.md)