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

當您建立 Azure 搜尋服務服務時,資源會在服務存留期內固定的定價層 (或 SKU) 上建立。When you create an Azure Search service, a resource is created at a pricing tier (or SKU) that's fixed for the lifetime of the service. 層包括免費、基本、標準和儲存體優化。Tiers include Free, Basic, Standard, and Storage Optimized. 標準和儲存體優化提供數個設定和容量。Standard and Storage Optimized are available with several configurations and capacities.

大部分的客戶都是從免費層開始, 讓他們可以評估服務。Most customers start with the Free tier so they can evaluate the service. 評估後, 通常會在開發和生產部署的其中一個較高層級建立第二個服務。Post-evaluation, it's common to create a second service at one of the higher tiers for development and production deployments.

雖然所有層 (包括免費層) 通常都會提供功能同位, 但較大的工作負載可能會要求較高的層級。Although all tiers, including the Free tier, generally offer feature parity, larger workloads can dictate a need for higher tiers. 例如,具有認知服務的 AI 擴充具有長時間執行的技能, 這會在免費的服務上運作, 除非資料集很小。For example, AI enrichment with Cognitive Services has long-running skills that time out on a free service unless the dataset is small.

注意

功能同位的例外狀況是無法在 S3 HD 上使用的索引子The exception to feature parity is indexers, which are not available on S3 HD.

可用的層級Available tiers

層級會反映裝載服務之硬體的特性 (而非功能),並會依下列方式來加以區分:Tiers reflect the characteristics of the hardware hosting the service (rather than features) and are differentiated by:

  • 您可以建立的索引和索引子數量Quantity of indexes and indexers you can create
  • 分割區的大小和速度 (實體儲存體)Size and speed of partitions (physical storage)

您選取的層級會決定可計費的費率。The tier you select determines the billable rate. 下列來自 Azure 入口網站的螢幕擷取畫面顯示可用的層, 減去定價 (您可以在入口網站和定價頁面上找到)。The following screenshot from Azure portal shows the available tiers, minus pricing (which you can find in the portal and on the pricing page. 免費」、「基本」和「標準」是最常見的層級。Free, Basic, and Standard are the most common tiers.

[免費] 會在叢集上建立受限的搜尋服務, 與其他訂閱者共用。Free creates a limited search service on a cluster, shared with other subscribers. 您可以完成小型專案, 包括快速入門和教學課程, 但無法調整服務或執行重要的工作負載。You can complete small projects, including quickstarts and tutorials, but you cannot scale the service or run significant workloads. [基本] 和 [標準] 是最常用的可計費層, 預設值是 [標準]。Basic and Standard are the most commonly used billable tiers, with Standard being the default.

Azure 搜尋服務的定價層Pricing tiers of Azure Search

某些層級已針對特定類型的工作進行優化。Some tiers are optimized for certain types of work. 例如,標準3高密度 (S3 HD) 是 S3 的主控模式, 其中基礎硬體已針對大量較小的索引進行優化, 適用于多租使用者案例。For example, Standard 3 High Density (S3 HD) is a hosting mode for S3, where the underlying hardware is optimized for a large number of smaller indexes and is intended for multitenancy scenarios. S3 HD 與 S3 具有相同的每單位費用, 但是硬體已針對大量較小索引的快速檔案讀取優化。S3 HD has the same per-unit charge as S3, but the hardware is optimized for fast file reads on a large number of smaller indexes.

儲存體優化層以比標準層低的價格提供更大的儲存體容量。Storage Optimized tiers offer larger storage capacity at a lower price per TB than the Standard tiers. 主要的取捨是較高的查詢延遲, 您應該針對特定的應用程式需求進行驗證。The primary tradeoff is higher query latency, which you should validate for your specific application requirements. 若要深入瞭解此層的效能考慮, 請參閱效能和優化考慮To learn more about the performance considerations of this tier, see Performance and optimization considerations.

您可以在定價頁面上找到有關各層的詳細資訊, 請參閱Azure 搜尋服務文章的服務限制一文, 以及在布建服務時的入口網站頁面。You can find out more about the various tiers on the pricing page, in the Service limits in Azure Search article, and on the portal page when you're provisioning a service.

可計費事件Billable events

以 Azure 搜尋服務為基礎的解決方案會以下列方式產生成本:A solution built on Azure Search can incur costs in the following ways:

  • 最低設定服務的基本成本 (建立服務)Base cost of service at minimum configuration (create a service)
  • 相應增加時的累加成本 (新增複本或資料分割)Incremental cost when scaling up (add replicas or partitions)
  • 頻寬費用 (輸出資料傳輸)Bandwidth charges (outbound data transfer)
  • 認知搜尋 (附加認知服務 AI 擴充、適用于知識存放區的 Azure 儲存體)Cognitive search (attach Cognitive Services for AI enrichment, Azure storage for knowledge store)

服務成本Service costs

不同于可「暫停」以避免費用的虛擬機器或其他資源, Azure 搜尋服務服務一律可供您專屬使用的硬體使用。Unlike virtual machines or other resources that can be "paused" to avoid charges, an Azure Search service is always available on hardware dedicated for your exclusive use. 因此, 建立服務是一種可計費事件, 會在您建立服務時啟動, 並在您刪除服務時結束。As such, creating a service is a billable event that starts when you create the service, and ends when you delete the service.

最低費用是依計費費率的第一個搜尋單位 (一個複本 x 一個資料分割)。The minimum charge is the first search unit (one replica x one partition) at the billable rate. 此最小值在服務的存留期間內已修正, 因為服務無法在此設定的任何專案上執行。This minimum is fixed for the lifetime of the service because the service can't run on anything less than this configuration. 除了最小值之外, 您還可以單獨新增複本和分割區。Beyond the minimum, you can add replicas and partitions independently of each other. 透過複本和分割區增量增加的容量, 將會根據下列公式來增加您的帳單: (複本 x 分割區 x 速率), 而您需支付的費用取決於您選取的定價層。Incremental increases in capacity through replicas and partitions will increase your bill based on the following formula: (replicas x partitions x rate), where the rate you're charged depends on the pricing tier you select.

當您要預估搜尋解決方案的成本時, 請記住, 定價和容量不是線性的。When you're estimating the cost of a search solution, keep in mind that pricing and capacity aren't linear. (容量加倍大於將成本加倍)。如需公式運作方式的範例, 請參閱如何配置複本和分割區。(Doubling capacity more than doubles the cost.) For an example of how of the formula works, see How to allocate replicas and partitions.

頻寬費用Bandwidth charges

根據服務的位置而定, 使用Azure 搜尋服務索引子可能會影響計費。Using Azure Search indexers might affect billing, depending on the location of your services. 如果您在與資料相同的區域中建立 Azure 搜尋服務服務, 則可以完全排除資料輸出費用。You can eliminate data egress charges entirely if you create the Azure Search service in the same region as your data. 以下是頻寬定價頁面的一些資訊:Here's some information from the bandwidth pricing page:

  • Microsoft 不會針對 Azure 上的任何服務或來自 Azure 搜尋服務的任何輸出資料, 收取任何輸入資料的費用。Microsoft doesn't charge for any inbound data to any service on Azure, or for any outbound data from Azure Search.
  • 在 multiservice 解決方案中, 當所有服務都位於相同的區域時, 就不會對跨越網路的資料收費。In multiservice solutions, there's no charge for data crossing the wire when all services are in the same region.

如果服務位於不同的區域, 則會收取輸出資料的費用。Charges do apply for outbound data if services are in different regions. 這些費用並不是您 Azure 搜尋服務帳單的一部分。These charges aren't actually part of your Azure Search bill. 這裡有提到, 因為如果您使用資料或 AI 擴充的索引子, 從不同的區域提取資料, 您會看到整體帳單中反映的成本。They're mentioned here because if you're using data or AI-enriched indexers to pull data from different regions, you'll see costs reflected in your overall bill.

認知服務的認知搜尋 AI 擴充Cognitive search AI enrichment with Cognitive Services

針對具有認知服務的 AI 擴充, 您應該規劃將可計費的 Azure 認知服務資源(位於與 Azure 搜尋服務相同的區域) 連結到隨用隨付處理的 S0 定價層。For AI enrichment with Cognitive Services, you should plan to attach a billable Azure Cognitive Services resource, in the same region as Azure Search, at the S0 pricing tier for pay-as-you-go processing. 附加認知服務並沒有相關聯的固定成本。There's no fixed cost associated with attaching Cognitive Services. 您只需要支付所需的處理費用。You pay only for the processing you need.

運算Operation 計費影響Billing impact
檔破解, 文字解壓縮Document cracking, text extraction 免費Free
檔破解, 影像解壓縮Document cracking, image extraction 根據從您的檔中解壓縮的影像數目來計費。Billed according to the number of images extracted from your documents. 索引子設定中, imageAction是用來觸發影像解壓縮的參數。In an indexer configuration, imageAction is the parameter that triggers image extraction. 如果 [ imageAction ] 設定為 [無] (預設值), 則不會向您收取影像解壓縮的費用。If imageAction is set to "none" (the default), you won't be charged for image extraction. 影像解壓縮的速率會記錄在 Azure 搜尋服務的 [定價詳細資料] 頁面上。The rate for image extraction is documented on the pricing details page for Azure Search.
預先建立的認知技能Pre-built cognitive skills 以與您直接使用認知服務執行工作時相同的費率來計費。Billed at the same rate as if you had performed the task by using Cognitive Services directly.
自訂技能Custom skills 自訂技能是您所提供的功能。A custom skill is functionality you provide. 使用自訂技能的成本完全取決於自訂程式碼是否呼叫其他計量付費服務。The cost of using a custom skill depends entirely on whether custom code is calling other metered services.

計費公式 (R x P = SU)Billing formula (R x P = SU)

若要瞭解 Azure 搜尋服務作業, 最重要的計費概念是搜尋單位(SU)。The most important billing concept to understand for Azure Search operations is the search unit (SU). 因為 Azure 搜尋服務需要複本和分割區才能編製索引和查詢,因此僅依據其中之一來計費沒有意義。Because Azure Search depends on both replicas and partitions for indexing and queries, it doesn't make sense to bill by just one or the other. 相反地,會將兩者合併來計費。Instead, billing is based on a composite of both.

SU 是服務所使用之複本和資料分割的乘積: (R x P = SU)SU is the product of the replicas and partitions used by a service: (R x P = SU).

每個服務都以一個 SU (一個複本乘以一個分割區) 作為最小值。Every service starts with one SU (one replica multiplied by one partition) as the minimum. 任何服務的最大值為 36 su。The maximum for any service is 36 SUs. 可以透過多種方式達到此上限:6個數據分割 x 6 個複本, 或3個分割區 x 12 個複本, 例如。This maximum can be reached in multiple ways: 6 partitions x 6 replicas, or 3 partitions x 12 replicas, for example. 通常會使用小於總容量 (例如, 3 個複本、3個數據分割服務, 以9個 su 計費)。It's common to use less than total capacity (for example, a 3-replica, 3-partition service billed as 9 SUs). 如需有效的組合, 請參閱資料分割和複本組合圖表。See the Partition and replica combinations chart for valid combinations.

計費費率為每 SU 每小時。The billing rate is hourly per SU. 每一層都有漸進較高的速率。Each tier has a progressively higher rate. 較高的層級隨附較大且 speedier 的資料分割, 而這對於該階層的整體每小時費率也會增加。Higher tiers come with larger and speedier partitions, and this contributes to an overall higher hourly rate for that tier. 您可以在 [定價詳細資料] 頁面上, 查看每一層的費率。You can view the rates for each tier on the pricing details page.

大多數客戶只能線上提供總容量的一部分,其餘部分則保留。Most customers bring just a portion of total capacity online, holding the rest in reserve. 針對計費, 您所上線的資料分割和複本數目 (由 SU 公式計算) 會決定您以小時為單位支付的費用。For billing, the number of partitions and replicas that you bring online, calculated by the SU formula, determines what you pay on an hourly basis.

如何管理和降低成本How to manage and reduce costs

除了下列建議以外, 請造訪計費和成本管理In addition to the following suggestions, visit Billing and cost management.

  • 在相同區域中建立所有資源, 或盡可能在較少的區域中, 以最小化或排除頻寬費用。Create all resources in the same region, or in as few regions as possible, to minimize or eliminate bandwidth charges.

  • 將所有服務合併成一個資源群組, 例如 Azure 搜尋服務、認知服務, 以及解決方案中使用的任何其他 Azure 服務。Consolidate all services into one resource group, such as Azure Search, Cognitive Services, and any other Azure services used in your solution. 在 Azure 入口網站中, 尋找資源群組, 並使用成本管理命令, 以深入瞭解實際和預估的支出。In the Azure portal, find the resource group and use the Cost Management commands for insight into actual and projected spending.

  • 請考慮適用于您前端應用程式的 Azure Web 應用程式, 讓要求和回應保留在資料中心界限內。Consider Azure Web App for your front-end application so that requests and responses stay within the data center boundary.

  • 針對需要大量資源的作業 (例如索引編制) 進行相應增加, 然後針對一般查詢工作負載重新調整。Scale up for resource-intensive operations like indexing, and then readjust downwards for regular query workloads. 從 Azure 搜尋服務的最小設定 (一個由一個資料分割和一個複本組成的 SU) 開始, 然後監視使用者活動, 以識別可能表示需要更多容量的使用模式。Start with the minimum configuration for Azure Search (one SU composed of one partition and one replica), and then monitor user activity to identify usage patterns that would indicate a need for more capacity. 如果有可預測的模式, 您可以同步處理調整與活動 (您需要撰寫程式碼來自動化這項作業)。If there is a predictable pattern, you might be able to synchronize scale with activity (you would need to write code to automate this).

您無法關閉搜尋服務來減少帳單。You can't shut down a search service to reduce your bill. 專用資源一律可運作, 並配置給您的服務存留期專屬使用。Dedicated resources are always operational, allocated for your exclusive use for the lifetime of your service. 就服務本身而言, 降低帳單的唯一方法, 是將複本和分割區減少到仍然提供可接受的效能和SLA 合規性的層級, 或在較低層建立服務 (S1 每小時費率低於 S2 或 S3 速率)。In terms of the service itself, the only way to lower your bill is to reduce replicas and partitions to a level that still provides acceptable performance and SLA compliance, or create a service at a lower tier (S1 hourly rates are lower than S2 or S3 rates). 假設您在負載預測的低端布建服務, 則您可以建立第二個較大的階層式服務, 在第二個服務上重建索引, 然後刪除第一個服務。Assuming you provision your service at the lower end of your load projections, if you outgrow the service, you can create a second larger-tiered service, rebuild your indexes on the second service, and then delete the first one.

如何評估容量需求How to evaluate capacity requirements

在 Azure 搜尋服務中,容量是由「複本」和「分割區」所構成。In Azure Search, capacity is structured as replicas and partitions.

  • 複本是搜尋服務的實例。Replicas are instances of the search service. 每個複本主控一個索引的負載平衡複本。Each replica hosts one load-balanced copy of an index. 例如, 具有六個複本的服務在服務中載入的每個索引都有6個複本。For example, a service with six replicas has six copies of every index loaded in the service.

  • 分割區會儲存索引, 並自動分割可搜尋的資料。Partitions store indexes and automatically split searchable data. 兩個分割區會將索引分成一半、三個分割區分成三分之二, 依此類推。Two partitions split your index in half, three partitions split it into thirds, and so on. 就容量而言,分割區大小是各層間主要的區分功能。In terms of capacity, partition size is the primary differentiating feature among tiers.

注意

所有標準和儲存體優化層都支援彈性的複本和分割區組合, 讓您可以藉由變更餘額來優化系統的速度或儲存All Standard and Storage Optimized tiers support flexible combinations of replicas and partitions so you can optimize your system for speed or storage by changing the balance. 基本層最多可提供三個複本以提供高可用性, 但只有一個資料分割。The Basic tier offers up to three replicas for high availability but has only one partition. 免費層不會提供專用資源: 多個訂閱者會共用計算資源。Free tiers don't provide dedicated resources: computing resources are shared by multiple subscribers.

評估容量Evaluating capacity

產能和執行服務的成本。Capacity and the costs of running the service go hand in hand. 階層會限制兩個層級: 儲存體和資源。Tiers impose limits on two levels: storage and resources. 您應該考慮這兩個原因, 因為您第一次達到的限制是有效的限制。You should think about both because whichever limit you reach first is the effective limit.

商務需求通常會決定您需要的索引數目。Business requirements typically dictate the number of indexes you'll need. 例如, 您可能需要大型檔存放庫的全域索引。For example, you might need a global index for a large repository of documents. 或者, 您可能需要以區域、應用程式或業務的小型為基礎的多個索引。Or you might need multiple indexes based on region, application, or business niche.

若要判斷索引的大小,您必須建置一個索引。To determine the size of an index, you have to build one. Azure 搜尋服務中的資料結構主要是反向索引結構, 其具有與來源資料不同的特性。The data structure in Azure Search is primarily 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.

注意

即使估計索引和儲存空間的未來需求也可以像猜測一樣, 但還是值得一試。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. 服務無法就地升級至另一個 SKU。There's no in-place upgrade of a service from one SKU 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:

使用粗略的估計值, 您可以將兩個索引 (開發和生產) 的預算加倍, 然後據以選擇您的定價層。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 you know you're going to have 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. 您也可以藉由啟用搜尋流量分析, 設定深度監視值, 例如點選連結分析。You also can configure deep monitoring of values like clickthrough analysis by enabling search traffic analytics.

索引編號和大小對您的分析同樣重要。Index number and size are equally important to your analysis. 這是因為最大限制是透過儲存體 (資料分割) 的完整使用量, 或資源 (索引、索引子等等) 的最大限制來達到, 視何者先發生。This is because maximum limits are reached through full utilization of storage (partitions) or by maximum limits on resources (indexes, indexers, and so forth), whichever comes first. 入口網站可協助您追蹤這兩項,在 [概觀] 頁面上並排顯示目前的使用量和最大限制。The portal helps you keep track of both, showing current usage and maximum limits side by side on the Overview page.

注意

如果檔包含無關的資料, 則儲存需求可能會擴大。Storage requirements can be inflated if documents contain extraneous data. 在理想的情況下, 檔只包含搜尋體驗所需的資料。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 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 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 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 don't provide 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 tier evaluation

  • 瞭解如何建立有效率的索引, 並瞭解哪些重新整理方法的影響最小。Learn how to build efficient indexes, and learn which refresh methods have the least impact. 使用搜尋流量分析來取得查詢活動的深入解析。Use search traffic analytics to gain insights on query activity.

  • 允許以查詢為依據的計量, 並收集使用模式的資料 (工作時間內的查詢, 在離峰時段編制索引)。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.

  • 請記住, underprovisioning 的唯一缺點是, 如果實際需求大於預測, 您可能必須卸載服務。Remember that the only downside of underprovisioning 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 in the same subscription at a higher tier and run it side by side until all apps and requests target the new endpoint.

後續步驟Next steps

從免費層開始, 並使用您資料的子集來建立初始索引, 以瞭解其特性。Start with a Free tier and build an initial index by using a subset of your data to understand its characteristics. Azure 搜尋服務中的資料結構是反向的索引結構。The data structure in Azure Search is an inverted index structure. 反向索引的大小和複雜性取決於內容。The size and complexity of an inverted index is determined by content. 請記住,重複性高的內容所產生的索引,往往會比差異性高的內容所產生的索引小。Remember that highly redundant content tends to result in a smaller index than highly irregular content. 因此, 內容特性, 而不是資料集的大小, 會決定索引儲存需求。So content characteristics rather than the size of the dataset determine index storage requirements.

在您有索引大小的初始估計之後, 請在本文討論的其中一個層級上布建可計費服務:基本、標準或儲存體已優化。After you have an initial estimate of your index size, provision a billable service on one of the tiers discussed in this article: Basic, Standard, or Storage Optimized. 放寬資料大小的任何人工條件約束, 並重建您的索引, 以包含您想要搜尋的所有資料。Relax any artificial constraints on data sizing and rebuild your index to include all the data that you want to be searchable.

視需要配置資料分割和複本,以取得所需的效能和規模。Allocate partitions and replicas as needed to get the performance and scale you require.

如果效能和容量都沒問題, 您就大功告成了。If performance and capacity are fine, you're done. 否則,請在更符合需求的不同定價層重新建立搜尋服務。Otherwise, re-create a search service at a different tier that more closely aligns with your needs.

注意

如有任何疑問, 請張貼至StackOverflow連絡人 Azure 支援If you have questions, post to StackOverflow or contact Azure support.