Scalabilità per le prestazioni in Azure ricerca cognitivaScale for performance on Azure Cognitive Search

Questo articolo descrive le procedure consigliate per gli scenari avanzati con requisiti sofisticati per la scalabilità e la disponibilità.This article describes best practices for advanced scenarios with sophisticated requirements for scalability and availability.

Inizia con i numeri di baseStart with baseline numbers

Prima di intraprendere un lavoro di distribuzione più ampio, assicurarsi di conoscere l'aspetto di un carico di query tipico.Before undertaking a larger deployment effort, make sure you know what a typical query load looks like. Le linee guida seguenti consentono di arrivare ai numeri di query di base.The following guidelines can help you arrive at baseline query numbers.

  1. Selezione una latenza di destinazione (o la quantità massima di tempo) che una ricerca tipica richiede per il completamento.Pick a target latency (or maximum amount of time) that a typical search request should take to complete.

  2. Creare e testare un carico di lavoro reale nel servizio di ricerca con un set di dati realistico per misurare questi tassi di latenza.Create and test a real workload against your search service with a realistic data set to measure these latency rates.

  3. Iniziare con un numero ridotto di query al secondo (query al secondo) e quindi aumentare gradualmente il numero eseguito nel test fino a quando la latenza della query scende sotto la destinazione predefinita.Start with a low number of queries per second (QPS) and then gradually increase the number executed in the test until the query latency drops below the predefined target. Si tratta di un benchmark importante per la pianificazione della scalabilità man mano che aumenta l'uso dell'applicazione.This is an important benchmark to help you plan for scale as your application grows in usage.

  4. Se possibile, riusare le connessioni HTTP.Wherever possible, reuse HTTP connections. Se si usa Azure ricerca cognitiva .NET SDK, questo significa che è necessario riutilizzare un'istanza di o un'istanza di SearchClient . Se si usa l'API REST, è necessario riusare un singolo HttpClient.If you are using the Azure Cognitive Search .NET SDK, this means you should reuse an instance or SearchClient instance, and if you are using the REST API, you should reuse a single HttpClient.

  5. Variare la sostanza delle richieste di query in modo che la ricerca venga eseguita su diverse parti dell'indice.Vary the substance of query requests so that search occurs over different parts of your index. La variazione è importante perché se si eseguono continuamente le stesse richieste di ricerca, la memorizzazione nella cache dei dati inizierà a migliorare le prestazioni rispetto a una serie di query più diverse.Variation is important because if you continually execute the same search requests, caching of data will start to make performance look better than it might with a more disparate query set.

  6. Variare la struttura delle richieste di query in modo da ottenere tipi diversi di query.Vary the structure of query requests so that you get different types of queries. Non tutte le query di ricerca vengono eseguite allo stesso livello.Not every search query performs at the same level. Ad esempio, una ricerca di documenti o un suggerimento di ricerca è in genere più veloce di una query con un numero significativo di facet e filtri.For example, a document lookup or search suggestion is typically faster than a query with a significant number of facets and filters. La composizione dei test deve includere diverse query, approssimativamente le stesse proporzioni che ci si aspetterebbe nell'ambiente di produzione.Test composition should include various queries, in roughly the same ratios as you would expect in production.

Durante la creazione di questi carichi di lavoro di test, è necessario tenere presenti alcune caratteristiche di Azure ricerca cognitiva:While creating these test workloads, there are some characteristics of Azure Cognitive Search to keep in mind:

  • È possibile sovraccaricare il servizio effettuando un numero eccessivo di query di ricerca alla volta.It is possible overload your service by pushing too many search queries at one time. In questo caso, vengono visualizzati i codici di risposta HTTP 503.When this happens, you will see HTTP 503 response codes. Per evitare un 503 durante i test, iniziare con diversi intervalli di richieste di ricerca per vedere le differenze nei tassi di latenza quando si aggiungono altre richieste di ricerca.To avoid a 503 during testing, start with various ranges of search requests to see the differences in latency rates as you add more search requests.

  • Azure ricerca cognitiva non esegue attività di indicizzazione in background.Azure Cognitive Search does not run indexing tasks in the background. Se il servizio gestisce contemporaneamente i carichi di lavoro di query e di indicizzazione, è necessario prendere in considerazione l'introduzione dei processi di indicizzazione nei test di query o l'esplorazione delle opzioni per l'esecuzione di processi di indicizzazione durante gli orari di minore attività.If your service handles query and indexing workloads concurrently, take this into account by either introducing indexing jobs into your query tests, or by exploring options for running indexing jobs during off peak hours.

Suggerimento

È possibile simulare un carico di query realistico usando gli strumenti di test di carico.You can simulate a realistic query load using load testing tools. Provare a eseguire il test di carico con Azure DevOps o usare una di queste alternative.Try load testing with Azure DevOps or use one of these alternatives.

Scalabilità per un volume di query elevatoScale for high query volume

Un servizio viene sovraccaricato quando le query richiedono troppo tempo o quando il servizio inizia a eliminare richieste.A service is overburdened when queries take too long or when the service starts dropping requests. In tal caso, è possibile risolvere il problema in uno dei due modi seguenti:If this happens, you can address the problem in one of two ways:

  • Aggiungere replicheAdd replicas

    Ogni replica è una copia dei dati, consentendo al servizio di bilanciare il carico delle richieste rispetto a più copie.Each replica is a copy of your data, allowing the service to load balance requests against multiple copies. Il bilanciamento del carico e la replica dei dati vengono gestiti da Azure ricerca cognitiva ed è possibile modificare il numero di repliche allocate per il servizio in qualsiasi momento.All load balancing and replication of data is managed by Azure Cognitive Search and you can alter the number of replicas allocated for your service at any time. È possibile allocare fino a 12 repliche in un servizio di ricerca Standard e 3 repliche in un servizio di ricerca Basic.You can allocate up to 12 replicas in a Standard search service and 3 replicas in a Basic search service. Le repliche possono essere modificate dal portale di Azure o da PowerShell.Replicas can be adjusted either from the Azure portal or PowerShell.

  • Creare un nuovo servizio a un livello superioreCreate a new service at a higher tier

    Azure ricerca cognitiva è disponibile in diversi livelli, ognuno dei quali offre diversi livelli di prestazioni.Azure Cognitive Search comes in a number of tiers and each one offers different levels of performance. In alcuni casi, è possibile che si disponga di un numero così elevato di query di cui il livello si è in grado di fornire un tempo di indisponibilità sufficiente anche quando le repliche sono al massimo In questo caso, si consiglia di passare a un livello di prestazioni superiore, ad esempio il livello S3 standard, progettato per scenari con un numero elevato di documenti e carichi di lavoro di query estremamente elevati.In some cases, you may have so many queries that the tier you are on cannot provide sufficient turnaround, even when replicas are maxed out. In this case, consider moving to a higher performing tier, such as the Standard S3 tier, designed for scenarios having large numbers of documents and extremely high query workloads.

Scalabilità per singole query lenteScale for slow individual queries

Un altro motivo per i tassi di latenza elevata è una singola query che richiede troppo tempo per il completamento.Another reason for high latency rates is a single query taking too long to complete. In questo caso, l'aggiunta di repliche non è utile.In this case, adding replicas will not help. Di seguito sono riportate due possibili opzioni che possono essere utili:Two possible options that might help include the following:

  • Aumentare le partizioniIncrease Partitions

    Una partizione suddivide i dati tra le risorse di elaborazione aggiuntive.A partition splits data across extra computing resources. Due partizioni suddividono i dati a metà, una terza partizione la suddivide in tre e così via.Two partitions split data in half, a third partition splits it into thirds, and so forth. Un effetto collaterale positivo è che le query più lente a volte vengono eseguite più velocemente grazie al calcolo parallelo.One positive side-effect is that slower queries sometimes perform faster due to parallel computing. È stata annotata la parallelizzazione su query con selettività bassa, ad esempio query che corrispondono a molti documenti, o facet che forniscono conteggi su un numero elevato di documenti.We have noted parallelization on low selectivity queries, such as queries that match many documents, or facets providing counts over a large number of documents. Poiché è necessario un calcolo significativo per assegnare un punteggio alla pertinenza dei documenti o per conteggiare il numero di documenti, l'aggiunta di partizioni aggiuntive consente di completare più velocemente le query.Since significant computation is required to score the relevancy of the documents, or to count the numbers of documents, adding extra partitions helps queries complete faster.

    Il servizio di ricerca standard e una partizione nel servizio di ricerca di base possono contenere un massimo di 12 partizioni.There can be a maximum of 12 partitions in Standard search service and 1 partition in the Basic search service. Le partizioni possono essere modificate dal portale di Azure o da PowerShell.Partitions can be adjusted either from the Azure portal or PowerShell.

  • Limitare i campi di cardinalità elevataLimit High Cardinality Fields

    Un campo di cardinalità elevata è costituito da un campo di facet o filtrabile con un numero significativo di valori univoci e, di conseguenza, utilizza risorse significative durante il calcolo dei risultati.A high cardinality field consists of a facetable or filterable field that has a significant number of unique values, and as a result, consumes significant resources when computing results. Ad esempio, l'impostazione di un campo ID prodotto o descrizione come facet/filtrabile viene conteggiata come alta cardinalità poiché la maggior parte dei valori dal documento al documento sono univoci.For example, setting a Product ID or Description field as facetable/filterable would count as high cardinality because most of the values from document to document are unique. Se possibile, limitare il numero di campi a cardinalità elevata.Wherever possible, limit the number of high cardinality fields.

  • Aumenta livello di ricercaIncrease Search Tier

    Il passaggio a un livello di ricerca cognitiva di Azure superiore può essere un altro modo per migliorare le prestazioni delle query lente.Moving up to a higher Azure Cognitive Search tier can be another way to improve performance of slow queries. Ogni livello superiore fornisce CPU più veloci e una maggiore quantità di memoria, che hanno un impatto positivo sulle prestazioni delle query.Each higher tier provides faster CPUs and more memory, both of which have a positive impact on query performance.

Scalabilità per la disponibilitàScale for availability

Le repliche non solo consentono di ridurre la latenza delle query, ma possono anche garantire disponibilità elevata.Replicas not only help reduce query latency, but can also allow for high availability. Con una singola replica, è necessario prevedere un tempo di inattività periodico dovuto al riavvio del server dopo gli aggiornamenti software o per altri interventi di manutenzione.With a single replica, you should expect periodic downtime due to server reboots after software updates or for other maintenance events that will occur. Di conseguenza, è importante considerare se l'applicazione richiede disponibilità elevata di ricerche, ovvero query, e operazioni di scrittura, ovvero eventi indicizzazione.As a result, it is important to consider if your application requires high availability of searches (queries) as well as writes (indexing events). Azure ricerca cognitiva offre opzioni di SLA per tutte le offerte di ricerca a pagamento con i seguenti attributi:Azure Cognitive Search offers SLA options on all the paid search offerings with the following attributes:

  • Due repliche per la disponibilità elevata di carichi di lavoro di sola lettura, vale a dire query.Two replicas for high availability of read-only workloads (queries)

  • Tre o più repliche per la disponibilità elevata dei carichi di lavoro di lettura e scrittura (query e indicizzazione)Three or more replicas for high availability of read-write workloads (queries and indexing)

Per altri dettagli, visitare il Contratto di servizio ricerca cognitiva di Azure.For more details on this, please visit the Azure Cognitive Search Service Level Agreement.

Poiché le repliche sono copie dei dati, la presenza di più repliche consente ad Azure ricerca cognitiva di eseguire riavvii del computer e manutenzione su una replica, mentre l'esecuzione delle query continua su altre repliche.Since replicas are copies of your data, having multiple replicas allows Azure Cognitive Search to do machine reboots and maintenance against one replica, while query execution continues on other replicas. Viceversa, se si eliminano le repliche, si verifica un calo delle prestazioni delle query, presupponendo che tali repliche fossero una risorsa sottoutilizzata.Conversely, if you take replicas away, you'll incur query performance degradation, assuming those replicas were an under-utilized resource.

Zone di disponibilitàAvailability Zones

Zone di disponibilità dividere i Data Center di un'area in gruppi di percorsi fisici distinti per fornire disponibilità elevata, all'interno della stessa area.Availability Zones divide a region's data centers into distinct physical location groups to provide high-availability, within the same region. Per ricerca cognitiva, le singole repliche sono le unità per l'assegnazione di zona.For Cognitive Search, individual replicas are the units for zone assignment. Un servizio di ricerca viene eseguito all'interno di un'area; le repliche vengono eseguite in zone diverse.A search service runs within one region; its replicas run in different zones.

È possibile usare zone di disponibilità con ricerca cognitiva di Azure aggiungendo due o più repliche al servizio di ricerca.You can utilize Availability Zones with Azure Cognitive Search by adding two or more replicas to your search service. Ogni replica verrà posizionata in una zona di disponibilità diversa all'interno dell'area.Each replica will be placed in a different Availability Zone within the region. Se si dispone di più repliche rispetto a zone di disponibilità, le repliche verranno distribuite tra zone di disponibilità nel modo più uniforme possibile.If you have more replicas than Availability Zones, the replicas will be distributed across Availability Zones as evenly as possible.

Azure ricerca cognitiva supporta attualmente zone di disponibilità per i servizi di ricerca di livello standard o superiore creati in una delle aree seguenti:Azure Cognitive Search currently supports Availability Zones for Standard tier or higher search services that were created in one of the following regions:

  • Australia orientale (creato il 30 gennaio 2021 o versione successiva)Australia East (created January 30, 2021 or later)
  • Canada centrale (creato il 30 gennaio 2021 o versione successiva)Canada Central (created January 30, 2021 or later)
  • Stati Uniti centrali (creati il 4 dicembre 2020 o versione successiva)Central US (created December 4, 2020 or later)
  • Stati Uniti orientali (creati il 27 gennaio 2021 o versione successiva)East US (created January 27, 2021 or later)
  • Stati Uniti orientali 2 (creati il 30 gennaio 2021 o versione successiva)East US 2 (created January 30, 2021 or later)
  • Francia centrale (creato il 23 ottobre 2020 o versione successiva)France Central (created October 23, 2020 or later)
  • Giappone orientale (creato il 30 gennaio 2021 o versione successiva)Japan East (created January 30, 2021 or later)
  • Europa settentrionale (creata il 28 gennaio 2021 o versione successiva)North Europe (created January 28, 2021 or later)
  • Sud Asia orientale (creato il 31 gennaio 2021 o versione successiva)South East Asia (created January 31, 2021 or later)
  • Regno Unito meridionale (creato il 30 gennaio 2021 o versione successiva)UK South (created January 30, 2021 or later)
  • Europa occidentale (creata il 29 gennaio 2021 o versione successiva)West Europe (created January 29, 2021 or later)
  • Stati Uniti occidentali 2 (creati il 30 gennaio 2021 o versione successiva)West US 2 (created January 30, 2021 or later)

Zone di disponibilità non influiscano sul contratto di servizio di ricerca cognitiva di Azure.Availability Zones do not impact the Azure Cognitive Search Service Level Agreement. Sono comunque necessarie tre o più repliche per la disponibilità elevata delle query.You still need 3 or more replicas for query high availability.

Scalabilità per carichi di lavoro distribuiti geograficamente e ridondanza geograficaScale for geo-distributed workloads and geo-redundancy

Per i carichi di lavoro distribuiti geograficamente, gli utenti che si trovano lontano dall'host data center avranno tassi di latenza superiori.For geo-distributed workloads, users who are located far from the host data center will have higher latency rates. Una mitigazione consiste nel provisioning di più servizi di ricerca in aree con prossimità più vicina a questi utenti.One mitigation is to provision multiple search services in regions with closer proximity to these users.

Azure ricerca cognitiva attualmente non offre un metodo automatizzato per la replica geografica degli indici di ricerca cognitiva di Azure tra le aree, ma sono disponibili alcune tecniche che possono rendere questo processo semplice da implementare e gestire.Azure Cognitive Search does not currently provide an automated method of geo-replicating Azure Cognitive Search indexes across regions, but there are some techniques that can be used that can make this process simple to implement and manage. Queste tecniche vengono illustrate nelle prossime sezioni.These are outlined in the next few sections.

L'obiettivo di un set con distribuzione geografica di servizi di ricerca consiste nel disporre di due o più indici disponibili in due o più aree, in cui un utente viene indirizzato al servizio ricerca cognitiva di Azure che offre la latenza più bassa, come illustrato in questo esempio:The goal of a geo-distributed set of search services is to have two or more indexes available in two or more regions, where a user is routed to the Azure Cognitive Search service that provides the lowest latency as seen in this example:

Incrocio dei servizi per area

Mantieni i dati sincronizzati tra più serviziKeep data synchronized across multiple services

Sono disponibili due opzioni per mantenere sincronizzati i servizi di ricerca distribuiti, che possono essere usati con l' indicizzatore ricerca cognitiva di Azure o l'API push (detta anche API REST di Azure ricerca cognitiva).There are two options for keeping your distributed search services in sync, which consist of either using the Azure Cognitive Search Indexer or the Push API (also referred to as the Azure Cognitive Search REST API).

Usare gli indicizzatori per aggiornare il contenuto su più serviziUse indexers for updating content on multiple services

Se si usa già l'indicizzatore in un servizio, è possibile configurare un secondo indicizzatore in un secondo servizio per usare lo stesso oggetto origine dati, estraendo i dati dallo stesso percorso.If you are already using indexer on one service, you can configure a second indexer on a second service to use the same data source object, pulling data from the same location. Ogni servizio in ogni area ha un proprio indicizzatore e un indice di destinazione (l'indice di ricerca non è condiviso, il che significa che i dati sono duplicati), ma ogni indicizzatore fa riferimento alla stessa origine dati.Each service in each region has its own indexer and a target index (your search index is not shared, which means data is duplicated), but each indexer references the same data source.

Di seguito è riportato un oggetto visivo di alto livello dell'aspetto dell'architettura.Here is a high-level visual of what that architecture would look like.

Singola origine dati con indicizzatore distribuito e combinazioni di servizio

Usare le API REST per il push degli aggiornamenti del contenuto su più serviziUse REST APIs for pushing content updates on multiple services

Se si usa l'API REST di Azure ricerca cognitiva per eseguire il push del contenuto nell'indice ricerca cognitiva di Azure, è possibile sincronizzare i vari servizi di ricerca eseguendo il push delle modifiche a tutti i servizi di ricerca ogni volta che è necessario un aggiornamento.If you are using the Azure Cognitive Search REST API to push content in your Azure Cognitive Search index, you can keep your various search services in sync by pushing changes to all search services whenever an update is required. Nel codice, assicurarsi di gestire i casi in cui un aggiornamento a un servizio di ricerca ha esito negativo, ma ha esito positivo per altri servizi di ricerca.In your code, make sure to handle cases where an update to one search service fails but succeeds for other search services.

Sfruttare gestione traffico di AzureLeverage Azure Traffic Manager

Gestione traffico di Azure consente di instradare le richieste a più siti Web con localizzazione geografica, supportati da più servizi di ricerca.Azure Traffic Manager allows you to route requests to multiple geo-located websites that are then backed by multiple search services. Un vantaggio di gestione traffico è che può sondare Azure ricerca cognitiva per assicurarsi che sia disponibile e indirizzare gli utenti a servizi di ricerca alternativi in caso di tempi di inattività.One advantage of the Traffic Manager is that it can probe Azure Cognitive Search to ensure that it is available and route users to alternate search services in the event of downtime. Inoltre, se si esegue il routing delle richieste di ricerca tramite siti Web di Azure, gestione traffico di Azure consente di bilanciare il carico dei casi in cui il sito Web è attivo, ma non di Azure ricerca cognitiva.In addition, if you are routing search requests through Azure Web Sites, Azure Traffic Manager allows you to load balance cases where the Website is up but not Azure Cognitive Search. Di seguito è riportato un esempio di un'architettura che usa Gestione traffico.Here is an example of what the architecture that leverages Traffic Manager.

Incrocio dei servizi per area con Gestione traffico centrale

Passaggi successiviNext steps

Per altre informazioni sui piani tariffari e sui limiti dei servizi, vedere limiti del servizio.To learn more about the pricing tiers and services limits for each one, see Service limits. Per altre informazioni sulle combinazioni di partizioni e repliche, vedere pianificare la capacità .See Plan for capacity to learn more about partition and replica combinations.

Per informazioni sulle prestazioni e le dimostrazioni delle tecniche descritte in questo articolo, guardare il video seguente:For a discussion about performance and demonstrations of the techniques discussed in this article, watch the following video: