Ottimizzare le prestazioni di una soluzione di Azure AI Search
Le prestazioni delle soluzioni di ricerca possono essere influenzate dalle dimensioni e dalla complessità degli indici. È anche necessario sapere come scrivere query efficienti per la ricerca e scegliere il livello di servizio appropriato.
In questa unità si esploreranno tutte queste dimensioni e i passaggi da compiere per migliorare le prestazioni della soluzione di ricerca.
Misurare le prestazioni di ricerca correnti
Non è possibile ottimizzare il servizio di ricerca se non se ne conoscono le prestazioni. Creare un benchmark delle prestazioni di base, per poter convalidare i miglioramenti apportati, ma anche verificare l'eventuale riduzione delle prestazioni nel corso del tempo.
Per iniziare, abilitare la registrazione diagnostica usando Log Analytics:
- Nel portale di Azure selezionare Impostazioni di diagnostica.
- Selezionare + Aggiungi impostazione di diagnostica.
- Assegnare un nome all'impostazione della diagnostica.
- Selezionare allLogs e AllMetrics.
- Selezionare Invia all'area di lavoro Log Analytics.
- Scegliere o creare l'area di lavoro Log Analytics.
È importante acquisire queste informazioni di diagnostica a livello di servizio di ricerca. Esistono infatti diversi punti in cui gli utenti finali o le app possono riscontrare problemi di prestazioni.
Se si riesce a dimostrare che il servizio di ricerca funziona bene, è possibile eliminarlo dai possibili fattori che causano problemi di prestazioni.
Controllare se il servizio di ricerca è limitato
Le ricerche e gli indici di Azure AI Search possono essere limitati. Se le ricerche degli utenti o delle app vengono limitate, il problema viene acquisito in Log Analytics con una risposta HTTP 503. Se gli indici vengono limitati, vengono visualizzati come risposte HTTP 207.
Questa query che si può eseguire sui log del servizio di ricerca mostra se il servizio di ricerca è soggetto a limitazioni.
Nel portale di Azure, in Monitoraggio selezionare Log. Nella scheda Nuova query 1 usare questa query:
AzureDiagnostics
| where TimeGenerated > ago(7d)
| summarize count() by resultSignature_d
| render barchart
Eseguire il comando per visualizzare un grafico a barre delle risposte HTTP dei servizi di ricerca. Nell'immagine qui sopra è possibile notare che sono state fornite diverse risposte 503.
Controllare le prestazioni delle singole query
Il modo migliore per testare le prestazioni delle singole query è usare uno strumento client come Postman. È possibile usare qualsiasi strumento che mostri le intestazioni nella risposta a una query. Azure AI Search restituirà sempre un valore "elapsed-time" per il tempo impiegato dal servizio per completare la query.
Per sapere quanto tempo è necessario per inviare e quindi ricevere la risposta dal client, sottrarre il tempo trascorso dal round trip totale. Nel caso di cui sopra, si tratta di 125 ms - 21 ms, per un totale di 104 ms.
Ottimizzare le dimensioni e lo schema degli indici
Le prestazioni delle query di ricerca sono direttamente collegate alle dimensioni e alla complessità degli indici. Più piccoli e ottimizzati sono gli indici, più veloce è la risposta di Azure AI Search alle query. Ecco alcuni suggerimenti che possono essere utili se sono stati riscontrati problemi di prestazioni in singole query.
Se non si presta attenzione, gli indici possono crescere nel corso del tempo. È consigliabile verificare che tutti i documenti presenti nell'indice siano ancora pertinenti e ricercabili.
Se non è possibile rimuovere alcun documento, è possibile ridurre la complessità dello schema? È ancora necessario che gli stessi campi siano ricercabili? Sono ancora necessari tutti i set di competenze con cui si è iniziato l'indice?
Valutare la possibilità di esaminare tutti gli attributi abilitati in ogni campo. Ad esempio, l'aggiunta del supporto per filtri, facet e ordinamenti può quadruplicare lo spazio di archiviazione necessario per supportare l'indice.
Nota
Un numero eccessivo di attributi per un campo ne limita le funzionalità. In un campo con facet, filtrabile e ricercabile, ad esempio, si possono archiviare solo 16 KB. Un campo ricercabile può invece contenere fino a 16 MB di testo.
Se l'indice è stato ottimizzato, ma le prestazioni non sono ancora all'altezza, si può scegliere di aumentare le prestazioni o il numero di istanze del servizio di ricerca.
Migliorare le prestazioni delle query
Se si conosce il funzionamento del servizio di ricerca, è possibile ottimizzare le query per migliorare drasticamente le prestazioni. Usare questo elenco di controllo per scrivere query migliori:
- Specificare solo i campi che è necessario cercare usando il parametro searchFields. Un numero maggiore di campi richiede infatti un'elaborazione supplementare.
- Restituire il minor numero possibile di campi di cui eseguire il rendering nella pagina dei risultati della ricerca. La restituzione di più dati richiede più tempo.
- Cercare di evitare termini di ricerca parziali, ad esempio la ricerca con prefisso o le espressioni regolari. Questi tipi di ricerche sono più costosi in termini di calcolo.
- Evitare di usare valori skip elevati. Ciò impone al motore di ricerca di recuperare e classificare volumi di dati più grandi.
- Limitare l'uso di campi con facet e filtrabili ai dati con livello di cardinalità basso.
- Usare le funzioni di ricerca invece dei singoli valori nei criteri di filtro. È ad esempio possibile usare
search.in(userid, '123,143,563,121',',')
invece di$filter=userid eq 123 or userid eq 143 or userid eq 563 or userid eq 121
.
Se sono stati applicati tutti gli accorgimenti sopra descritti e le singole query non funzionano, è possibile aumentare il numero di istanze dell'indice. A seconda del livello di servizio usato per creare la soluzione di ricerca, è possibile aggiungere fino a 12 partizioni. Le partizioni sono la memoria fisica in cui si trova l'indice. Per impostazione predefinita, tutti i nuovi indici di ricerca vengono creati con una sola partizione. Se si aggiungono altre partizioni, l'indice viene archiviato su tutte le partizioni. Se ad esempio l'indice è di 200 GB e le partizioni sono quattro, ogni partizione contiene 50 GB di indice.
L'aggiunta di ulteriori partizioni consente di migliorare le prestazioni perché il motore di ricerca può essere eseguito in parallelo in ogni partizione. I miglioramenti più significativi si registrano per le query che restituiscono un gran numero di documenti e per le query che utilizzano facet che forniscono conteggi su un gran numero di documenti. Ciò è dovuto al costo in termini di calcolo del punteggio di pertinenza dei documenti.
Usare il livello di servizio migliore per le esigenze di ricerca
Si è visto che è possibile aumentare i livelli di servizio aggiungendo altre partizioni. È possibile aumentare il numero di istanze con le repliche se è necessario un dimensionamento a causa di un aumento del carico. È anche possibile aumentare le prestazioni del servizio di ricerca usando un livello superiore.
Le dimensioni dei due indici di ricerca precedenti sono pari a 200 GB. Il livello S1 usa otto partizioni, il livello S2 invece solo due. Entrambi hanno due repliche ed entrambi hanno all'incirca lo stesso costo. Per scegliere il livello migliore per la soluzione di ricerca, è necessario conoscere la dimensione totale approssimativa necessaria per la risorsa di archiviazione. L'indice più grande attualmente supportato è di 12 partizioni nel livello L2, per un totale di 24 TB.
Livello | Digita | Storage | Repliche | Partizioni |
---|---|---|---|---|
F | Disponibile | 50 MB | 1 | 1 |
B | Di base | 2 GB | 3 | 1 |
S1 | Standard | 25 GB/partizione | 12 | 12 |
S2 | Standard | 100 GB/partizione | 12 | 12 |
S3 | Standard | 200 GB/partizione | 12 | 12 |
S3HD | Alta densità | 200 GB/partizione | 12 | 3 |
L1 | Con ottimizzazione per l'archiviazione | 1 TB/partizione | 12 | 12 |
L2 | Con ottimizzazione per l'archiviazione | 2 TB/partizione | 12 | 12 |
Quale dei due livelli dell'esempio precedente si ritiene che abbia le prestazioni migliori? Si è visto che l'aumento del numero di istanze offre vantaggi in termini di prestazioni grazie al parallelismo. Tuttavia, i livelli superiori sono anche dotati di spazio di archiviazione Premium, risorse di calcolo più potenti e memoria aggiuntiva. La scelta della seconda opzione offre un'infrastruttura più potente e consente una crescita futura dell'indice. Sfortunatamente, la scelta del livello migliore dipende dalle dimensioni e dalla complessità dell'indice e dalle query scritte per la ricerca. Entrambe le opzioni potrebbero quindi essere quella migliore.
Pianificare la crescita futura dell'uso della soluzione di ricerca significa prendere in considerazione le unità di ricerca. Un'unità di ricerca è il prodotto di repliche e partizioni. Ciò significa che il livello S1 di cui si è parlato sopra usa 16 unità di ricerca e il livello S2 solo 4 unità di ricerca. I costi sono simili perché i livelli superiori comportano un costo maggiore per ogni unità di ricerca.
Si supponga di dover dimensionare la soluzione di ricerca a causa dell'aumento del carico. Aggiungendo un'altra replica a entrambi i livelli, il livello S1 sale a 24 unità di ricerca, mentre il livello S2 sale solo a 6 unità di ricerca.