Considerazioni sulle prestazioni e sull'ottimizzazione di Ricerca di AzureAzure Search performance and optimization considerations

Un'esperienza eccellente è la chiave del successo per molti dispositivi mobili e applicazioni Web.A great search experience is a key to success for many mobile and web applications. Dal mercato immobiliare, passando per il mercato dell'usato dei veicoli fino ai negozi online, la ricerca veloce e i risultati rilevanti influiscono sull'esperienza dell'utente.From real estate, to used car marketplaces to online catalogs, fast search and relevant results will affect the customer experience. Questo documento aiuta l'utente a scoprire le procedure consigliate su come ottenere il massimo da Ricerca di Azure, in particolare per scenari avanzati con requisiti di scalabilità avanzati, con supporto multilingue o classificazione personalizzata.This document is intended to help you discover best practices for how to get the most out of Azure Search, especially for advanced scenarios with sophisticated requirements for scalability, multi-language support, or custom ranking. Questo documento illustra anche i meccanismi interni e descrive gli approcci efficienti per le applicazioni reali dei clienti.In addition, this document outlines internals and covers approaches that work effectively in real-world customer apps.

Prestazioni e pianificazione della scalabilità per i servizi di RicercaPerformance and scale tuning for Search services

Tutti conosciamo e usiamo motori di ricerca come Bing e Google e le relative prestazioni offerte.We are all used to search engines such as Bing and Google and the high performance they offer. Di conseguenza, quando i clienti usano applicazioni mobili o Web abilitate per la ricerca, si aspettano prestazioni simili.As a result, when customers use your search-enabled web or mobile application, they will expect similar performance characteristics. Per l'ottimizzazione delle prestazioni di ricerca, l'approccio migliore consiste nel concentrarsi sulla latenza, ovvero sul tempo necessario per completare la query e restituire i risultati.When optimizing for search performance, one of the best approaches is to focus on latency, which is the time a query takes to complete and return results. Durante l'ottimizzazione della latenza della ricerca, è importante:When optimizing for search latency it is important to:

  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 reale per misurare i tassi di latenza.Create and test a real workload against your search service with a realistic dataset to measure these latency rates.
  3. Iniziare con un numero ridotto di query al secondo (QPS) e continuare ad aumentare il numero di query testate fino a quando la latenza delle query diventa inferiore alla latenza di destinazione definita.Start with a low number of queries per second (QPS) and continue to increase the number executed in the test until the query latency drops below the defined target latency. 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 .NET SDK di Ricerca di Azure, è necessario riusare un'istanza o un'istanza SearchIndexClient. Se si usa l'API REST, è necessario riusare un singolo HttpClient.If you are using the Azure Search .NET SDK, this means you should reuse an instance or SearchIndexClient instance, and if you are using the REST API, you should reuse a single HttpClient.

Durante la creazione di questi carichi di lavoro di test, è opportuno considerare alcune caratteristiche di Ricerca di Azure:While creating these test workloads, there are some characteristics of Azure Search to keep in mind:

  1. È possibile eseguire un numero di query di ricerca per volta finché le risorse disponibili nel servizio di Ricerca di Azure non sono sovraccariche.It is possible to push so many search queries at one time, that the resources available in your Azure Search service will be overwhelmed. In questo caso, vengono visualizzati i codici di risposta HTTP 503.When this happens, you will see HTTP 503 response codes. Per questo motivo, è preferibile iniziare con vari intervalli di richieste di ricerca per vedere le differenze nei tassi di latenza all'aggiunta di nuove richieste di ricerca.For this reason, it is best to start with various ranges of search requests to see the differences in latency rates as you add more search requests.
  2. Il caricamento del contenuto in Ricerca di Azure influisce sulle prestazioni complessive e sulla latenza del servizio Ricerca di Azure.Uploading of content to Azure Search will impact the overall performance and latency of the Azure Search service. Se si prevede di inviare i dati mentre gli utenti eseguono ricerche, è importante prendere in considerazione questo carico di lavoro durante i test.If you expect to send data while users are performing searches, it is important to take this workload into account in your tests.
  3. Non tutte le query di ricerca verranno eseguite con lo stesso livello di prestazioni.Not every search query will perform at the same performance levels. Ad esempio, la visualizzazione di un documento o un consiglio sulla ricerca viene generalmente eseguito più velocemente rispetto a una query con un numero significativo di facet e filtri.For example, a document lookup or search suggestion will typically perform faster than a query with a significant number of facets and filters. Durante la compilazione del test, è consigliabile scegliere le varie query che si desidera vedere nel proprio account.It is best to take the various queries you expect to see into account when building your tests.
  4. È importante variare le richieste di ricerca perché, se si eseguono continuamente le stesse richieste, verrà avviato il caching dei dati per migliorare le prestazioni rispetto alla qualità offerta da un set di query più eterogeneo.Variation of search requests 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.

Nota

Il test di carico di Visual Studio è un metodo molto valido per eseguire i test di benchmark in quanto consente di eseguire le richieste HTTP nello stesso modo richiesto per l'esecuzione di query con Ricerca di Azure e consente la parallelizzazione delle richieste.Visual Studio Load Testing is a really good way to perform your benchmark tests as it allows you to execute HTTP requests as you would need for executing queries against Azure Search and enables parallelization of requests.

Ridimensionamento di Ricerca di Azure per tassi elevati di query e richieste limitateScaling Azure Search for high query rates and throttled requests

Quando si ricevono troppe richieste limitate o si superano i tassi di latenza di destinazione da un carico maggiore di query, è possibile considerare di ridurre il tasso di latenza in uno dei due modi seguenti:When you are receiving too many throttled requests or exceed your target latency rates from an increased query load, you can look to decrease latency rates in one of two ways:

  1. Aumentare le repliche: una replica è una copia dei dati che consente a Ricerca di Azure di bilanciare il carico con le numerose copie.Increase Replicas: A replica is like a copy of your data allowing Azure Search to load balance requests against the multiple copies. Il bilanciamento del carico e la replica dei dati tra le repliche vengono gestiti da Ricerca di Azure ed è possibile modificare in qualsiasi momento il numero delle repliche allocate per il servizio.All load balancing and replication of data across replicas is managed by Azure 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.
  2. Aumentare il livello di Ricerca: sono disponibili diversi livelli per Ricerca di Azure, ognuno dei quali offre diversi livelli di prestazioni.Increase Search Tier: Azure Search comes in a number of tiers and each of these tiers offers different levels of performance. In alcuni casi, è possibile che l'utente disponga di un numero talmente elevato di query che il livello a cui appartiene non fornisce tassi di latenza sufficientemente bassi, anche quando si raggiunge il limite massimo delle repliche. In questo caso, è consigliabile considerare di usare uno dei livelli di Ricerca di Azure più elevati, ad esempio il livello S3, adatto a scenari con un numero elevato di documenti e carichi di lavoro delle query estremamente elevati.In some cases, you may have so many queries that the tier you are on cannot provide sufficiently low latency rates, even when replicas are maxed out. In this case, you may want to consider leveraging one of the higher search tiers such as the Azure Search S3 tier that is well suited for scenarios with large numbers of documents and extremely high query workloads.

Ridimensionamento di Ricerca di Azure per le singole query lenteScaling Azure Search for slow individual queries

Un altro motivo per cui il tasso di latenza può essere lento è una singola query che impiega troppo tempo.Another reason why latency rates can be slow is from a single query taking too long to complete. In questo caso, l'aggiunta di repliche non migliorerà il tasso di latenza.In this case, adding replicas will not improve latency rates. In questo caso sono disponibili due opzioni:For this case there are two options available:

  1. Aumentare le partizioni: una partizione è un meccanismo per la suddivisione dei dati tra le risorse aggiuntive.Increase Partitions A partition is a mechanism for splitting your data across extra resources. Per questo motivo, quando si aggiunge una seconda partizione, si ottengono dati divisi in due parti.For this reason, when you add a second partition, your data gets split into two. Una terza partizione suddivide l'indice in tre parti e così via. Questo fattore, in alcuni casi, si traduce in un aumento di velocità delle query lente grazie alla parallelizzazione del calcolo.A third partition splits your index into three, etc. This also has the effect that in some cases, slow queries will perform faster due to the parallelization of computation. Sono disponibili alcuni esempi dell'efficienza della parallelizzazione con query che dispongono di query a selettività ridotta.There are a few examples of where we have seen this parallelization work extremely well with queries that have low selectivity queries. Si tratta di query che corrispondono a molti documenti o ai casi in cui i facet devono fornire calcoli su un grande numero di documenti.This consists of queries that match many documents or when faceting needs to provide counts over large numbers of documents. Poiché sono necessari molti calcoli per valutare la rilevanza dei documenti o per calcolare il numero dei documenti, l'aggiunta di altre partizioni consente di fornire calcoli aggiuntivi.Since there is a lot of computation needed to score the relevancy of the documents or to count the numbers of documents, adding extra partitions can help to provide additional computation.

    Il servizio di ricerca Standard offe fino a un massimo di 12 partizioni, mentre il servizio Basic offre 1 partizione.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.

  2. Limitare i campi a cardinalità elevata: un campo a cardinalità elevata è costituito da un facet o da un campo filtrabile che dispone di un numero significativo di valori univoci e, di conseguenza, richiede molte risorse per calcolare i risultati.Limit High Cardinality Fields: A high cardinality field consists of a facetable or filterable field that has a significant number of unique values, and as a result, takes a lot of resources to compute results over. Ad esempio, l'impostazione di un campo ID prodotto o la descrizione come facet/filtrabile comporterebbe un'elevata cardinalità perché la maggior parte dei valori dei documenti è univoca.For example, setting a Product ID or Description field as facetable/filterable would make for 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.
  3. Aumentare il livello di Ricerca: il passaggio a un livello superiore di Ricerca di Azure può essere un altro modo per migliorare le prestazioni delle query lente.Increase Search Tier: Moving up to a higher Azure Search tier can be another way to improve performance of slow queries. Ogni livello superiore fornisce CPU più veloce e memoria più ampia, elementi che possono avere un impatto positivo sulle prestazioni delle query.Each higher tier also provides faster CPU’s and more memory which can have a positive impact on query performance.

Ridimensionamento per la disponibilitàScaling for availability

Le repliche non solo consentono di ridurre la latenza delle query ma possono anche favorire una 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). Ricerca di Azure offre opzioni di Contratto di servizio in tutte le offerte a pagamento, con le caratteristiche seguenti:Azure Search offers SLA options on all the paid search offerings with the following attributes:

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

Per ulteriori informazioni, visitare il Contratto di Servizio per Ricerca di Azure.For more details on this, please visit the Azure Search Service Level Agreement.

Poiché le repliche sono copie dei dati, la presenza di più repliche consente a Ricerca di Azure di riavviare le macchine e di eseguire la manutenzione su una replica per volta, consentendo allo stesso tempo l'esecuzione delle query sulle altre repliche.Since replicas are copies of your data, having multiple replicas allows Azure Search to do machine reboots and maintenance against one replica at a time while allowing queries to continue to be executed against the other replicas. Per questo motivo, è necessario anche considerare in che modo il tempo di inattività può influire sulle query che devono ora essere eseguite su una copia dei dati in meno.For that reason, you will also need to consider how this downtime may impact the queries that now have to be executed against one less copy of the data.

Ridimensionamento dei carichi di lavoro distribuiti geograficamente e ridondanza geograficaScaling geo-distributed workloads and provide geo-redundancy

Per i carichi di lavoro distribuiti geograficamente, si noterà che gli utenti lontani dal data center in cui è ospitato il servizio Ricerca di Azure registrano tassi di latenza superiori.For geo-distributed workloads, you will find that users located far from the data center where your Azure Search service is hosted will have higher latency rates. Per questo motivo, è spesso importante disporre di più servizi di ricerca nelle aree vicine a tali utenti.For this reason, it is often important to have multiple search services in regions that are in closer proximity to these users. Ricerca di Azure attualmente non fornisce un metodo automatizzato per la replica geografica degli indici di Ricerca di Azure tra le aree, ma esistono alcune tecniche che semplificano l'implementazione e la gestione del processo.Azure Search does not currently provide an automated method of geo-replicating Azure 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 di servizi di ricerca distribuito geograficamente consiste nel disporre di due o più indici disponibili in due o più aree in cui un utente verrà reindirizzato al servizio di Ricerca di Azure che offre il tasso di latenza più basso, 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 will be routed to the Azure Search service that provides the lowest latency as seen in this example:

Incrocio dei servizi per area

Mantenere sincronizzati i dati tra più servizi di Ricerca di AzureKeeping data in sync across multiple Azure Search services

Sono disponibili due opzioni per mantenere sincronizzati i servizi di ricerca distribuiti: l'uso dell'indicizzatore di Ricerca di Azure o l'API Push, conosciuta anche come API REST di Ricerca di Azure.There are two options for keeping your distributed search services in sync which consist of either using the Azure Search Indexer or the Push API (also referred to as the Azure Search REST API).

Indicizzatori di Ricerca di AzureAzure Search Indexers

Se si usa l'indicizzatore di Ricerca di Azure, si importano le modifiche ai dati da un archivio dati centrale, ad esempio database SQL di Azure o Azure Cosmos DB.If you are using the Azure Search Indexer, you are already importing data changes from a central datastore such as Azure SQL DB or Azure Cosmos DB. Quando si crea un nuovo servizio di Ricerca, è sufficiente creare un nuovo indicizzatore di Ricerca di Azure per il servizio creato, che punta allo stesso archivio dati.When you create a new search Service, you simply also create a new Azure Search Indexer for that service that points to this same datastore. In questo modo, ogni volta che le nuove modifiche entrano nell'archivio dati, vengono indicizzate dai diversi indicizzatori.That way, whenever new changes come into the data store, they will then be indexed by the various Indexers.

Di seguito è riportato un esempio dell'aspetto dell'architettura.Here is an example of what that architecture would look like.

Singola origine dati con indicizzatore distribuito e combinazioni di servizio

API PushPush API

Se si usa l'API Push di Ricerca di Azure per aggiornare il contenuto dell'indice di Ricerca di Azure, è possibile mantenere sincronizzati i vari servizi di ricerca trasferendo le modifiche apportate a tutti i servizi di ricerca ogni volta che è necessario un aggiornamento.If you are using the Azure Search Push API to update content in your Azure Search index, you can keep your various search services in sync by pushing changes to all search services whenever an update is required. Quando si esegue questa operazione è importante verificare di gestire i casi in cui si verifica un errore nell'aggiornamento del servizio di ricerca e i casi in cui uno o più aggiornamenti hanno esito positivo.When doing this it is important to make sure to handle cases where an update to one search service fails and one or more updates succeed.

Uso di Gestione traffico di AzureLeveraging Azure Traffic Manager

Gestione traffico di Azure consente di indirizzare le richieste su più siti Web geograficamente localizzati e supportati da più servizi di Ricerca di Azure.Azure Traffic Manager allows you to route requests to multiple geo-located websites that are then backed by multiple Azure Search Services. Uno dei vantaggi di Gestione traffico è la capacità di esplorare Ricerca di Azure per garantire che sia disponibile e di 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 Search to ensure that it is available and route users to alternate search services in the event of downtime. In aggiunta, se si esegue il routing delle richieste di ricerca tramite siti Web di Azure, Gestione traffico di Azure consente di bilanciare i casi in cui il sito Web è attivo ma Ricerca di Azure non lo è.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 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

Monitoraggio delle prestazioniMonitoring performance

Ricerca di Azure offre la possibilità di analizzare e monitorare le prestazioni del servizio tramite Analisi del traffico di ricerca (STA).Azure Search offers the ability to analyze and monitor the performance of your service through Search Traffic Analytics (STA). Tramite il servizio STA è possibile registrare le singole operazioni di ricerca e le metriche di aggregazione su un account di archiviazione di Azure che può essere elaborato per l'analisi o visualizzato in Power BI.Through STA, you can optionally log the individual search operations as well as aggregated metrics to an Azure Storage account that can then be processed for analysis or visualized in Power BI. Con le metriche STA, è possibile esaminare le statistiche sulle prestazioni, ad esempio il numero medio delle query o i tempi di risposta alle query.Using STA metrics, you can review performance statistics such as average number of queries or query response times. In aggiunta, la registrazione delle operazioni consente di esaminare i dettagli di operazioni di ricerca specifiche.In addition, the operation logging allows you to drill into details of specific search operations.

STA è uno strumento utile per comprendere i tassi di latenza da tale punto di vista di Ricerca di Azure.STA is a valuable tool to understand latency rates from that Azure Search perspective. Poiché le metriche sulle prestazioni delle query registrate sono basate sul tempo necessario per l'elaborazione della query in Ricerca di Azure, ovvero dal momento della richiesta al momento del completamento, è possibile usare questa opzione per determinare se i problemi di latenza provengono dal servizio di Ricerca di Azure o dall'esterno del servizio, ad esempio dalla latenza di rete.Since the query performance metrics logged are based on the time a query takes to be fully processed in Azure Search (from the time it is requested to when it is sent out), you are able to use this to determine if latency issues are from the Azure Search service side or outside of the service, such as from network latency.

Passaggi successiviNext steps

Per altre informazioni sui piani tariffari e sui limiti dei servizi, vedere Limiti dei servizi in Ricerca di Azure.To learn more about the pricing tiers and services limits for each one, see Service limits in Azure Search.

Per altre informazioni sulle combinazioni di partizione e replica, vedere Pianificazione della capacità .Visit Capacity planning to learn more about partition and replica combinations.

Per maggiori dettagli sulle prestazioni e per vedere alcune dimostrazioni su come implementare le ottimizzazioni descritte in questo articolo, guardare il video seguente:For more drilldown on performance and to see some demonstrations of how to implement the optimizations discussed in this article, watch the following video: