預估及管理 Azure 認知搜尋服務的容量Estimate and manage capacity of an Azure Cognitive Search service

提供搜尋服務 並鎖定特定定價層之前,請花幾分鐘的時間來瞭解容量的運作方式,以及如何調整複本和資料分割以因應工作負載波動。Before provisioning a search service and locking in a specific pricing tier, take a few minutes to understand how capacity works and how you might adjust replicas and partitions to accommodate workload fluctuation.

容量是 服務層的函式,可建立每個服務的最大儲存空間、每個分割區,以及您可以建立之物件數目的最大限制。Capacity is a function of the service tier, establishing maximum storage per service, per partition, and the maximum limits on the number of objects you can create. 基本層是專為具有適度儲存需求的應用程式所設計, (一個資料分割) 但可以在高可用性設定中執行 (3 個複本) 。The Basic tier is designed for apps having modest storage requirements (one partition only) but with the ability to run in a high availability configuration (3 replicas). 其他層則是針對特定的工作負載或模式(例如多租使用者)所設計。Other tiers are designed for specific workloads or patterns, such as multitenancy. 就內部而言,在這些層級上建立的服務會受益于有助於這些案例的硬體。Internally, services created on those tiers benefit from hardware that helps those scenarios.

Azure 認知搜尋中的擴充性架構是以彈性的複本和資料分割組合為基礎,因此您可以根據您是否需要更多查詢或索引編制功能來改變容量。The scalability architecture in Azure Cognitive Search is based on flexible combinations of replicas and partitions so that you can vary capacity depending on whether you need more query or indexing power. 一旦建立服務之後,您就可以單獨增加或減少複本或資料分割的數目。Once a service is created, you can increase or decrease the number of replicas or partitions independently. 成本會隨著每個額外的實體資源而增加,但在大型工作負載完成後,您可以減少調整以降低帳單。Costs will go up with each additional physical resource, but once large workloads are finished, you can reduce scale to lower your bill. 視層級和調整大小而定,增加或減少容量可能需要15分鐘到數小時的時間。Depending on the tier and the size of the adjustment, adding or reducing capacity can take anywhere from 15 minutes to several hours.

修改複本和分割區的配置時,建議使用 Azure 入口網站。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. 但是,如果您需要以腳本為基礎或以程式碼為基礎的布建方法, Azure PowerShell管理 REST API 是替代的解決方案。However, if you require a script-based or code-based provisioning approach, the Azure PowerShell or the Management REST API are alternative solutions.

概念:搜尋單位、複本、資料分割、分區Concepts: search units, replicas, partitions, shards

容量是以可透過資料 分割和**複本 組合來配置的 搜尋單位 來表示,並使用基礎 分區化 機制來支援彈性設定:Capacity is expressed in search units that can be allocated in combinations of partitions and replicas, using an underlying sharding mechanism to support flexible configurations:

概念Concept 定義Definition
搜尋單位Search unit 總可用容量的單一增量 (36 單位) 。A single increment of total available capacity (36 units). 這也是 Azure 認知搜尋服務的計費單位。It is also the billing unit for an Azure Cognitive Search service. 至少需要一個單位才能執行服務。A minimum of one unit is required to run the service.
複本Replica 搜尋服務的執行個體,主要用來讓查詢作業達到負載平衡。Instances of the search service, used primarily to load balance query operations. 每個複本都會裝載一份索引。Each replica hosts one copy of an index. 如果您配置三個複本,則會有三個索引複本可用於服務查詢要求。If you allocate three replicas, you'll have three copies of an index available for servicing query requests.
資料分割Partition 讀取/寫入作業的實體儲存體和 i/o (例如,在重建或重新整理索引) 時。Physical storage and I/O for read/write operations (for example, when rebuilding or refreshing an index). 每個分割區都有總計索引的配量。Each partition has a slice of the total index. 如果您配置三個數據分割,則索引會分成三分之二。If you allocate three partitions, your index is divided into thirds.
碎片Shard 索引的區塊。A chunk of an index. Azure 認知搜尋會將每個索引分割成分區,藉由將分區移至新的搜尋單位) ,讓新增資料分割的過程 (更快速。Azure Cognitive Search divides each index into shards to make the process of adding partitions faster (by moving shards to new search units).

下圖顯示覆本、磁碟分割、分區和搜尋單位之間的關聯性。The following diagram shows the relationship between replicas, partitions, shards, and search units. 它會顯示一個範例,說明如何在具有兩個複本和兩個數據分割的服務中,跨越四個搜尋單位的單一索引。It shows an example of how a single index is spanned across four search units in a service with two replicas and two partitions. 這四個搜尋單位的每一個都只會儲存索引的一半分區。Each of the four search units stores only half of the shards of the index. 左欄中的搜尋單位會儲存第一半的分區,其中包含第一個資料分割,而右邊資料行中的資料行則是由第二個數據分割組成的分區後半部。The search units in the left column store the first half of the shards, comprising the first partition, while those in the right column store the second half of the shards, comprising the second partition. 由於有兩個複本,因此每個索引分區都有兩個複本。Since there are two replicas, there are two copies of each index shard. 頂端資料列中的搜尋單位會儲存一個複本,其中包含第一個複本,而底部資料列中的資料會儲存另一個複本,其中包含第二個複本。The search units in the top row store one copy, comprising the first replica, while those in the bottom row store another copy, comprising the second replica.

搜尋索引會跨資料分割分區化。

上圖只是一個範例。The diagram above is only one example. 有許多分割區和複本的組合可供使用,最多可達36的搜尋單位總數。Many combinations of partitions and replicas are possible, up to a maximum of 36 total search units.

在認知搜尋中,分區管理是一個執行詳細資料和不可設定的,但瞭解索引分區化有助於瞭解排名和自動完成行為中偶爾發生的異常狀況:In Cognitive Search, shard management is an implementation detail and non-configurable, but knowing that an index is sharded helps to understand the occasional anomalies in ranking and autocomplete behaviors:

  • 排名異常:先在分區層級計算搜尋分數,然後匯總成單一結果集。Ranking anomalies: Search scores are computed at the shard level first, and then aggregated up into a single result set. 根據分區內容的特性而定,一個分區的相符專案可能會高於另一個的相符專案。Depending on the characteristics of shard content, matches from one shard might be ranked higher than matches in another one. 如果您注意到搜尋結果中有直覺排名的計數器,最有可能是因為分區化的影響,尤其是當索引較小時。If you notice counter intuitive rankings in search results, it is most likely due to the effects of sharding, especially if indexes are small. 您可以選擇在 整個索引的全域計算分數,以避免這些排名異常,但是這樣做會導致效能的負面影響。You can avoid these ranking anomalies by choosing to compute scores globally across the entire index, but doing so will incur a performance penalty.

  • 自動完成異常:自動完成查詢,在部分輸入詞彙的前幾個字元上進行相符專案的情況下,接受模糊參數以 forgives 模糊的微小偏差。Autocomplete anomalies: Autocomplete queries, where matches are made on the first several characters of a partially entered term, accept a fuzzy parameter that forgives small deviations in spelling. 針對自動完成,模糊比對會限制為目前分區內的詞彙。For autocomplete, fuzzy matching is constrained to terms within the current shard. 例如,如果分區包含 "Microsoft" 且輸入了 "micor" 的部分詞彙,則搜尋引擎會比對該分區中的 "Microsoft",但不會比對剩餘索引部分的其他分區。For example, if a shard contains "Microsoft" and a partial term of "micor" is entered, the search engine will match on "Microsoft" in that shard, but not in other shards that hold the remaining parts of the index.

接近估計Approaching estimation

開始執行服務的容量和成本。Capacity and the costs of running the service go hand in hand. 階層會限制兩個層級:內容 (服務上索引的計數,例如) 和儲存體。Tiers impose limits on two levels: content (a count of indexes on a service, for example) and storage. 請務必考慮這兩者,因為您最先達到的限制是有效的限制。It's important to consider both because whichever limit you reach first is the effective limit.

索引和其他物件的計數通常是由商務和工程需求所決定。Counts of indexes and other objects are typically dictated by business and engineering requirements. 例如,您可能會有相同索引的多個版本,以供主動開發、測試和生產環境使用。For example, you might have multiple versions of the same index for active development, testing, and production.

儲存體需求取決於您預期要建立的索引大小。Storage needs are determined by the size of the indexes you expect to build. 沒有可協助評估的穩固啟發學習法或 generalities。There are no solid heuristics or generalities that help with estimates. 判斷索引大小的唯一方式是 建立一個The only way to determine the size of an index is build one. 其大小會以匯入的資料、文字分析和索引設定為基礎,例如您是否啟用建議工具、篩選和排序。Its size will be based on imported data, text analysis, and index configuration such as whether you enable suggesters, filtering, and sorting.

針對全文檢索搜尋,主要資料結構是 反向索引 結構,其具有與來源資料不同的特性。For full text search, the primary data structure is an inverted index structure, which has different characteristics than source data. 對於反向索引,大小和複雜度是由內容所決定,而不一定是您饋送至其中的資料量。For an inverted index, size and complexity are determined by content, not necessarily by the amount of data that you feed into it. 具有高冗余性的大型資料來源可能會產生比包含高度變數內容的較小資料集更小的索引。A large data source with high redundancy could result in a smaller index than a smaller dataset that contains highly variable content. 因此很少可以根據原始資料集的大小推斷索引大小。So it's rarely possible to infer index size based on the size of the original dataset.

索引上的屬性(例如啟用篩選和排序)將會影響儲存體需求。Attributes on the index, such as enabling filters and sorting, will impact storage requirements. 使用建議工具也會影響儲存體。The use of suggesters also has storage implications. 如需詳細資訊,請參閱 屬性和索引大小For more information, see Attributes and index size.

注意

雖然預估索引和儲存空間的未來需求可能會像是猜測,但還是值得一試。Even though estimating future needs for indexes and storage can feel like guesswork, it's worth doing. 如果層的容量太低,您將需要在較高的層級布建新的服務,然後 重載您的索引If a tier's capacity turns out to be too low, you'll need to provision a new service at a higher tier and then reload your indexes. 沒有將服務從一個階層就地升級到另一個層級。There's no in-place upgrade of a service from one tier to another.

使用免費層進行評估Estimate with the Free tier

其中一個預估容量的方法是從免費層開始。One approach for estimating capacity is to start with the Free tier. 請記住,免費服務提供最多三個索引、50 MB 的儲存空間,以及2分鐘的索引時間。Remember that the Free service offers up to three indexes, 50 MB of storage, and 2 minutes of indexing time. 使用這些條件約束來估計投影的索引大小可能會很困難,但這些步驟如下:It can be challenging to estimate a projected index size with these constraints, but these are the steps:

  • 建立免費服務Create a free service.

  • 準備小型、具代表性的資料集。Prepare a small, representative dataset.

  • 建立索引並載入您的資料。Create an index and load your data. 如果資料集可以裝載于索引子支援的 Azure 資料來源中,您可以使用 入口網站中的 [匯入資料] 嚮導 來建立和載入索引。If the dataset can be hosted in an Azure data source supported by indexers, you can use the Import data wizard in the portal to both create and load the index. 否則,您應該使用 REST 和 PostmanVisual Studio Code 來建立索引並推送資料。Otherwise, you should use REST and Postman or Visual Studio Code to create the index and push the data. 推送模型要求資料的格式為 JSON 檔,檔中的欄位會對應至索引中的欄位。The push model requires data to be in the form of JSON documents, where fields in the document correspond to fields in the index.

  • 收集索引的相關資訊,例如大小。Collect information about the index, such as size. 功能和屬性會影響儲存體。Features and attributes have an impact on storage. 例如,新增建議工具 (搜尋即輸入查詢) 將會增加儲存需求。For example, adding suggesters (search-as-you-type queries) will increase storage requirements.

    使用相同的資料集,您可能會嘗試在每個欄位上建立具有不同屬性的多個索引版本,以查看儲存需求的差異。Using the same data set, you might try creating multiple versions of an index, with different attributes on each field, to see how storage requirements vary. 如需詳細資訊,請參閱 建立基本索引中的「存放裝置含意」。For more information, see "Storage implications" in Create a basic index.

有了粗略的估計值,您可以將兩個索引的數量加倍 (開發和生產) ,然後據以選擇您的定價層。With a rough estimate in hand, you might double that amount to budget for two indexes (development and production) and then choose your tier accordingly.

使用可計費層進行估計Estimate with a billable tier

專用資源可以容納較大型的取樣和處理時間,以在開發期間更實際估計索引數量、大小和查詢量。Dedicated resources can accommodate larger sampling and processing times for more realistic estimates of index quantity, size, and query volumes during development. 某些客戶會直接使用計費層,然後在開發專案成熟時重新評估。Some customers jump right in with a billable tier and then re-evaluate as the development project matures.

  1. 查看每一層的服務限制 ,判斷較低的層級是否可以支援您需要的索引數目。Review service limits at each tier to determine whether lower tiers can support the number of indexes you need. 在基本、S1 和 S2 層中,索引限制分別為15、50和200。Across the Basic, S1, and S2 tiers, index limits are 15, 50, and 200, respectively. 儲存體優化層有10個索引的限制,因為它的設計是為了支援少量的極大型索引。The Storage Optimized tier has a limit of 10 indexes because it's designed to support a low number of very large indexes.

  2. 在可計費的定價層建立服務Create a service at a billable tier:

    • 如果您不確定預計的負載,請在 [基本] 或 [S1] 上啟動。Start low, at Basic or S1, if you're not sure about the projected load.
    • 如果測試包含大規模的索引和查詢負載,請從 S2 或甚至 S3 開始。Start high, at S2 or even S3, if testing includes large-scale indexing and query loads.
    • 如果您要編制大量資料的索引,且查詢負載相對較低(如同內部商務應用程式),請從 L1 或 L2 的儲存體進行優化。Start with Storage Optimized, at L1 or L2, if you're indexing a large amount of data and query load is relatively low, as with an internal business application.
  3. 建置初始索引,以判斷來源資料轉譯為索引的情形。Build an initial index to determine how source data translates to an index. 這是唯一能預估索引大小的方式。This is the only way to estimate index size.

  4. 在入口網站中監視儲存體、服務限制、查詢量和延遲Monitor storage, service limits, query volume, and latency in the portal. 入口網站會顯示每秒查詢數、節流查詢和搜尋延遲。The portal shows you queries per second, throttled queries, and search latency. 所有這些值都可以協助您決定是否選取了正確的層級。All of these values can help you decide if you selected the right tier.

  5. 如果您需要高可用性,或如果您遇到查詢效能緩慢的情況,請新增複本。Add replicas if you need high availability or if you experience slow query performance.

    對於需要多少個複本來容納查詢負載,並沒有任何相關指導方針。There are no guidelines on how many replicas are needed to accommodate query loads. 查詢效能取決於查詢和競爭工作負載的複雜性。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 的指導方針,請參閱 針對效能監視查詢進行調整。For guidance in estimating QPS for your solution, see Scale for performanceand Monitor queries.

注意

如果您包含永遠不會搜尋的資料,則可以擴大儲存體需求。Storage requirements can be inflated if you include data that will never be searched. 在理想情況下,檔只包含搜尋體驗所需的資料。Ideally, documents contain only the data that you need for the search experience. 二進位資料無法搜尋,而且應該個別儲存 (可能在 Azure 資料表或 blob 儲存體) 中。Binary data isn't searchable and should be stored separately (maybe in an Azure table or blob storage). 接著,應該在索引中加入欄位,以保存外部資料的 URL 參考。A field should then be added in the index to hold a URL reference to the external data. 如果您要在單一) 要求中大量上傳多份檔,則個別搜尋檔的大小上限為 16 MB (或較少。The maximum size of an individual search document is 16 MB (or less if you're bulk uploading multiple documents in one request). 如需詳細資訊,請參閱 Azure 認知搜尋中的服務限制For more information, see Service limits in Azure Cognitive Search.

查詢量的考量Query volume considerations

每秒查詢數 (QPS) 是效能調整期間的重要計量,但如果您在一開始就預期會有大量的查詢量,通常只會考慮階層。Queries per second (QPS) is an important metric during performance tuning, but it's generally only a tier consideration if you expect high query volume at the outset.

標準層可以提供複本和資料分割的平衡。The Standard tiers can provide a balance of replicas and partitions. 您可以藉由新增負載平衡的複本或加入資料分割以進行平行處理,來增加查詢週期。You can increase query turnaround by adding replicas for load balancing or add partitions for parallel processing. 然後,您可以在布建服務之後調整效能。You can then tune for performance after the service is provisioned.

如果您預期從一開始就會有高度持續的查詢磁片區,您應該考慮較高的標準層,並支援更強大的硬體。If you expect high sustained query volumes from the outset, you should consider higher Standard tiers, backed by more powerful hardware. 然後,您可以讓分割區和複本離線,或甚至切換至較低層的服務(如果沒有發生這些查詢磁片區)。You can then take partitions and replicas offline, or even switch to a lower-tier service, if those query volumes don't occur. 如需如何計算查詢輸送量的詳細資訊,請參閱 Azure 認知搜尋效能和優化For more information on how to calculate query throughput, see Azure Cognitive Search performance and optimization.

儲存體優化層適用于大型資料工作負載,當查詢延遲需求較不重要時,支援更多的整體可用索引儲存體。The Storage Optimized tiers are useful for large data workloads, supporting more overall available index storage for when query latency requirements are less important. 您仍應使用額外的複本來進行負載平衡,並使用額外的資料分割來進行平行處理。You should still use additional replicas for load balancing and additional partitions for parallel processing. 然後,您可以在布建服務之後調整效能。You can then tune for performance after the service is provisioned.

服務等級協定Service-level agreements

免費層和預覽功能未涵蓋在 服務等級協定 (sla) The Free tier and preview features are not covered by service-level agreements (SLAs). 在所有可計費層中,SLA 會在您為您的服務佈建足夠的備援性時生效。For all billable tiers, SLAs take effect when you provision sufficient redundancy for your service. 您需要有兩個以上的複本,查詢 (讀取) Sla。You need to have two or more replicas for query (read) SLAs. 您需要有三個以上的複本,以便查詢和編制索引 (讀寫) Sla。You need to have three or more replicas for query and indexing (read-write) SLAs. 磁碟分割數目不會影響 Sla。The number of partitions doesn't affect SLAs.

容量規劃的秘訣Tips for capacity planning

  • 允許計量以查詢為依據,並收集在上班時間 (查詢的使用模式資料,在離峰時段編制索引) 。Allow metrics to build around queries, and collect data around usage patterns (queries during business hours, indexing during off-peak hours). 使用此資料來通知服務布建決策。Use this data to inform service provisioning decisions. 雖然不是每小時或每日的頻率,您可以動態調整分割區和資源,以配合查詢磁片區中的規劃變更。Though it's not practical at an hourly or daily cadence, you can dynamically adjust partitions and resources to accommodate planned changes in query volumes. 如果層級保有足夠的時間足以保證採取動作,您也可以容納未計畫但持續的變更。You can also accommodate unplanned but sustained changes if levels hold long enough to warrant taking action.

  • 請記住,在布建下的唯一缺點是,如果實際需求大於您的預測,您可能必須卸載服務。Remember that the only downside of under provisioning is that you might have to tear down a service if actual requirements are greater than your predictions. 為了避免服務中斷,您會在較高的層級建立新的服務,並並存執行,直到所有應用程式和要求都以新端點為目標為止。To avoid service disruption, you would create a new service at a higher tier and run it side by side until all apps and requests target the new endpoint.

新增容量的時機When to add capacity

一開始,服務會配置由一個資料分割和一個複本組成的基本資源層級。Initially, a service is allocated a minimal level of resources consisting of one partition and one replica. 您選擇的層級會決定資料分割的大小和速度,而每一層都會針對符合各種案例的一組特性進行優化。The tier you choose determines partition size and speed, and each tier is optimized around a set of characteristics that fit various scenarios. 如果您選擇較高階的層級,您可能需要比使用 S1 更少的資料分割。If you choose a higher-end tier, you might need fewer partitions than if you go with S1. 您必須透過自我導向測試回答的問題之一,就是,較大且較昂貴的資料分割是否可在布建于較低層的服務上,產生比兩個較便宜的資料分割更佳的效能。One of the questions you'll need to answer through self-directed testing is whether a larger and more expensive partition yields better performance than two cheaper partitions on a service provisioned at a lower tier.

單一服務必須具有足夠的資源,才能處理所有工作負載 (編製索引和查詢)。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. 此外,當服務或節點在內部更新時,特定數量的冗余會將查詢效能變得更平滑。Additionally, a certain amount of redundancy smooths out query performance when services or nodes are updated internally.

決定是否要新增容量的一些指導方針包括:Some guidelines for determining whether to add capacity include:

  • 符合服務等級協定的高可用性準則Meeting the high availability criteria for service level agreement
  • HTTP 503 錯誤的頻率增加The frequency of HTTP 503 errors is increasing
  • 需要大型查詢磁片區Large query volumes are expected

一般而言,搜尋應用程式所需的複本比分割區多,特別是當服務作業偏差查詢工作負載時。As a general rule, search applications tend to need more replicas than partitions, particularly when the service operations are biased toward query workloads. 每個複本都是索引的複本,可讓服務針對多個複本進行負載平衡要求。Each replica is a copy of your index, allowing the service to load balance requests against multiple copies. 索引的所有負載平衡和複寫都是由 Azure 認知搜尋管理,而且您可以隨時變更為服務配置的複本數目。All load balancing and replication of an index is managed by Azure Cognitive Search and you can alter the number of replicas allocated for your service at any time. 您最多可在標準搜尋服務中配置 12 個複本,並在基本搜尋服務中配置 3 個複本。You can allocate up to 12 replicas in a Standard search service and 3 replicas in a Basic search service. 您可以從 Azure 入口網站 或其中一個程式設計選項來進行複本配置。Replica allocation can be made either from the Azure portal or one of the programmatic options.

要求近乎即時資料重新整理的搜尋應用程式,按比例需要比複本更多的資料分割數。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.

最後,較大的索引需要較長的時間來進行查詢。Finally, 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.

注意

加入更多複本或資料分割會增加執行服務的成本,而且可能會在排序結果的方式中帶來些許變化。Adding more replicas or partitions increases the cost of running the service, and can introduce slight variations in how results are ordered. 請務必檢查 定價計算機 ,以瞭解新增更多節點的計費含意。Be sure to check the pricing calculator to understand the billing implications of adding more nodes. 下圖可協助您交叉參考特定設定所需的搜尋單位數目。The chart below can help you cross-reference the number of search units required for a specific configuration. 如需其他複本如何影響查詢處理的詳細資訊,請參閱 排序結果For more information on how additional replicas impact query processing, see Ordering results.

新增或減少複本和磁碟分割Add or reduce replicas and partitions

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

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

    下列螢幕擷取畫面顯示已布建一個複本和分割區的基本標準。The following screenshot shows a Basic Standard 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.

    顯示目前值的縮放頁面

  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. 選取 [儲存]。Select Save.

    此範例會新增第二個複本和資料分割。This example adds a second replica and partition. 請注意搜尋單位元數目;這現在是四個,因為計費公式是複本乘以資料分割 (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.

    新增複本和磁碟分割

  4. 儲存之後,您可以檢查通知來確認動作是否成功。After saving, you can check notifications to confirm the action succeeded.

    儲存變更

    容量的變更可能需要15分鐘到數小時的時間才能完成。Changes in capacity can take anywhere from 15 minutes up to 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.

    入口網站中的狀態訊息

注意

服務在布建之後,即無法升級至較高的層級。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. 請參閱 入口網站中的建立 Azure 認知搜尋服務 ,以取得服務布建方面的協助。See Create an Azure Cognitive Search service in the portal 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.

資料分割與複本組合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 allowed for these tiers.

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 Cognitive 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 Cognitive 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.

下一步Next steps