在 Azure 搜尋服務中調整資料分割和複本以進行查詢和編制索引工作負載Scale partitions and replicas for query and indexing workloads in Azure Search

在您選擇定價層佈建搜尋服務之後,下一個步驟是選擇性地增加服務所使用的複本或分割區數目。After you choose a pricing tier and provision a search service, 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.

當您在基本層或其中一個標準或儲存體優化層中設定服務時, 可以使用資源設定。Resource configuration is available when you set up a service at the Basic tier or one of the Standard or Storage Optimized tiers. 對於這些層的服務,購買容量就是增加「搜尋單位」(SU),每個分割區和複本會計為一個 SU。For services at these tiers, capacity is purchased in increments of search units (SUs) where each partition and replica counts as one SU.

使用較少 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.

注意

刪除服務會刪除它上面的一切。Deleting a service deletes everything on it. Azure 搜尋服務內沒有任何機制可備份和還原持續性搜尋資料。There is no facility within Azure 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.

術語: 複本和分割區Terminology: replicas and partitions

複本和分割區是回到搜尋服務的主要資源。Replicas and partitions are the primary resources that back a search service.

ResourceResource 定義Definition
分割數Partitions 為讀寫作業 (例如,在重建或重新整理索引時) 提供索引儲存體和 I/O。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. 如果您有 12 個複本,服務上就會分別載入 12 份索引。If you have 12 replicas, you will have 12 copies of every index loaded on the service.

注意

沒有任何方法可直接操作或管理哪些索引會在複本上執行。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

在「Azure 搜尋服務」中,一開始會為服務配置由一個分割區和一個複本組成的最低層級資源。In Azure Search, a service is initially allocated a minimal level of resources consisting of one partition and one replica. 如果階層支援,您便可以增量調整運算資源,方法是在您需要較多的儲存體和 I/O 時新增分割區,或新增更多複本來因應較大的查詢磁碟區或提供較佳的效能。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.

若要增加或變更複本和分割區的配置,建議使用 Azure 入口網站。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. 如果您需要以腳本為基礎或以程式碼為基礎的布建方法, Azure PowerShell管理 REST API為替代解決方案。If you require a script-based or code-based provisioning approach, the Azure PowerShell or the Management REST API 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 explains why.

  1. 登入 Azure 入口網站,然後選取搜尋服務。Sign in to the Azure portal and select the search service.

  2. 在 [設定] 中, 開啟 [調整] 頁面以修改複本和分割區。In Settings, open the Scale page to modify replicas and partitions.

    下列螢幕擷取畫面顯示以一個複本和分割區布建的標準服務。The following screenshot shows a standard service provisioned with one replica and partition. 底部的公式表示正在使用的搜尋單位數目 (1)。The formula at the bottom indicates how many search units are being used (1). 如果單價為 $100 (不是真正的價格), 執行這項服務的每月成本會平均為 $100。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

  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.

    這個範例會將容量加倍, 其中每個都有兩個複本和分割區。This example doubles capacity, with two replicas and partitions each. 請注意搜尋單位元數目;這現在是四個, 因為計費公式是複本乘以分割區 (2 x 2)。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. 如果搜尋單位成本為 $100, 則新的每月帳單現在會是 $400。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.

    ![新增複本和]分割區(media/search-capacity-planning/2-add-2-each.png "新增複本和")分割區Add replicas and partitions

  4. 按一下 [儲存] 以確認變更。Click Save to confirm the changes.

    確認變更規模和計費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

注意

服務在佈建之後,即無法升級到較高的 SKU。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. 如需有關服務佈建的說明,請參閱 在入口網站中建立 Azure 搜尋服務See Create an Azure Search service in the portal for help with service provisioning.

資料分割與複本組合Partition and replica combinations

「基本」服務可以有不多不少 1 個分割區及最多 3 個複本,上限為 3 個 SU。A Basic service can have exactly one partition and up to three replicas, for a maximum limit of three SUs. 唯一可調整的資源是複本。The only adjustable resource is replicas. 您至少需要 2 個複本,才能在查詢上達到高可用性。You need a minimum of two replicas for high availability on queries.

所有標準和儲存體優化的搜尋服務都可以採用下列複本和分割區組合, 受限於 36-SU 限制。All Standard and Storage Optimized search services can assume the following combinations of replicas and partitions, subject to the 36-SU limit.

1 個資料分割1 partition 2 個資料分割2 partitions 3 個資料分割3 partitions 4 個資料分割4 partitions 6 個資料分割6 partitions 12 個資料分割12 partitions
1 個複本1 replica 1 SU1 SU 2 SU2 SU 3 SU3 SU 4 SU4 SU 6 SU6 SU 12 SU12 SU
2 個複本2 replicas 2 SU2 SU 4 SU4 SU 6 SU6 SU 8 SU8 SU 12 SU12 SU 24 SU24 SU
3 個複本3 replicas 3 SU3 SU 6 SU6 SU 9 SU9 SU 12 SU12 SU 18 SU18 SU 36 SU36 SU
4 個複本4 replicas 4 SU4 SU 8 SU8 SU 12 SU12 SU 16 SU16 SU 24 SU24 SU N/AN/A
5 個複本5 replicas 5 SU5 SU 10 SU10 SU 15 SU15 SU 20 SU20 SU 30 SU30 SU N/AN/A
6 個複本6 replicas 6 SU6 SU 12 SU12 SU 18 SU18 SU 24 SU24 SU 36 SU36 SU N/AN/A
12 個複本12 replicas 12 SU12 SU 24 SU24 SU 36 SU36 SU N/AN/A N/AN/A N/AN/A

SU、定價和容量會在 Azure 網站上詳細說明。SUs, pricing, and capacity are explained in detail on the Azure website. 如需詳細資訊,請參閱定價詳細資料For more information, see Pricing Details.

注意

複本數和資料分割數可整除 12 (明確來說就是 1、2、3、4、6、12)。The number of replicas and partitions divides evenly into 12 (specifically, 1, 2, 3, 4, 6, 12). 這是因為「Azure 搜尋服務」會將每個索引預先劃分成 12 個分區,以便將其平均散佈到所有分割區。This is because Azure Search pre-divides each index into 12 shards so that it can be spread in equal portions across all partitions. 例如,如果您的服務有三個資料分割,而您建立了索引,則每個資料分割將會包含 4 個該索引的分區。For example, if your service has three partitions and you create an index, each partition will contain four shards of the index. Azure 搜尋服務將索引分區的方法是實作細節,有可能在未來版本中變更。How Azure Search shards an index is an implementation detail, subject to change in future releases. 雖然現在分區數為 12,但您不應預期未來該數字永遠都會是 12。Although the number is 12 today, you shouldn't expect that number to always be 12 in the future.

高可用性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:

  • 針對唯讀工作負載 (查詢),需有 2 個複本才能達到高可用性Two replicas for high availability of read-only workloads (queries)

  • 針對讀寫工作負載 (查詢再加上新增、更新或刪除個別文件時的索引編製),需有 3 個或更多個複本才能達到高可用性Three or more replicas for high availability of read/write workloads (queries plus indexing as individual documents are added, updated, or deleted)

「Azure 搜尋服務」的「服務等級協定」(SLA) 是針對查詢作業和由新增、更新或刪除文件所組成的索引更新。Service level agreements (SLA) for Azure Search are targeted at query operations and at index updates that consist of adding, updating, or deleting documents.

基本層最多一個分割區和三個複本。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

「Azure 搜尋服務」的高可用性與查詢和不涉及重建索引的索引更新相關。High availability for Azure 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.

注意

您可以將新欄位新增至 Azure 搜尋服務索引,而不需重建索引。You can add new fields to an Azure Search index without rebuilding the index. 所有已在索引中之文件的新欄位值將為 null。The value of the new field will be null for all documents already in the index.

若要讓索引在重建期間保持可用,您必須在相同服務上有使用不同名稱的索引副本,或在不同服務上有相同名稱的索引副本,然後在您的程式碼中提供重新導向或容錯移轉邏輯。To maintain index availability during a rebuild, you must have a copy of the 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.

嚴重損壞修復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.

利用複本提高查詢效能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.

我們無法提供固定的每秒查詢數目 (QPS) 預估值:查詢效能取決於查詢和競爭工作負載的複雜性。We cannot provide hard estimates on queries per second (QPS): query performance depends on the complexity of the query and competing workloads. 雖然新增複本會明顯獲得更好的效能,但是最終結果並不會完全地呈線性關係:新增 3 個複本並不保證有 3 倍的輸送量。Although adding replicas clearly results in better performance, the result is not strictly linear: adding three replicas does not guarantee triple throughput.

如需有關評估工作負載 QPS 的指引,請參閱 Azure 搜尋服務的效能與最佳化考量For guidance in estimating QPS for your workloads, see Azure Search performance and optimization considerations.

使用資料分割提高編製索引的效能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

選擇 Azure 搜尋服務的定價層Choose a pricing tier for Azure Search