Stimare e gestire la capacità di un servizio di ricerca

Prima di creare un servizio di ricerca e bloccare un piano tariffario specifico, è necessario qualche minuto per comprendere il funzionamento della capacità e come modificare le repliche e le partizioni per gestire la fluttuazione del carico di lavoro.

In Ricerca cognitiva di Azure la capacità è basata su repliche e partizioni che possono essere ridimensionate al carico di lavoro. Le repliche sono copie del motore di ricerca. Le partizioni sono unità di archiviazione. Ogni nuovo servizio di ricerca inizia con uno, ma è possibile modificare ogni unità in modo indipendente per supportare carichi di lavoro fluttuanti. L'aggiunta di una delle due unità è fatturabile.

Le caratteristiche fisiche delle repliche e delle partizioni, ad esempio la velocità di elaborazione e l'I/O del disco, variano in base al livello di servizio. Se è stato effettuato il provisioning su Standard, le repliche e le partizioni saranno più veloci e maggiori di quelle di Base.

La modifica della capacità non è istantanea. La commissione o la rimozione delle partizioni può richiedere fino a un'ora, in particolare per i servizi con grandi quantità di dati.

Quando si ridimensiona un servizio di ricerca, è possibile scegliere tra gli strumenti e gli approcci seguenti:

Concetti: unità di ricerca, repliche, partizioni, partizioni

La capacità è espressa in unità di ricerca che possono essere allocate in combinazioni di partizioni e repliche, usando un meccanismo di partizionamento orizzontale sottostante per supportare configurazioni flessibili:

Concetto Definizione
Unità di ricerca Un singolo incremento della capacità totale disponibile (36 unità). È anche l'unità di fatturazione per un servizio di Ricerca cognitiva di Azure. Per eseguire il servizio è necessario almeno un'unità.
Replica Istanze del servizio di ricerca, utilizzate principalmente per il bilanciamento di carico delle operazioni di query. Ogni replica ospita una copia di un indice. Se si allocano tre repliche, saranno disponibili tre copie di un indice per la manutenzione delle richieste di query.
Partizione Archiviazione fisica e I/O per operazioni di lettura/scrittura, ad esempio durante la ricompilazione o l'aggiornamento di un indice. Ogni partizione ha una sezione dell'indice totale. Se si allocano tre partizioni, l'indice viene diviso in terzi.
Shard Blocco di un indice. Ricerca cognitiva di Azure divide ogni indice in partizioni per velocizzare il processo di aggiunta di partizioni (spostando le partizioni in nuove unità di ricerca).

Il diagramma seguente illustra la relazione tra repliche, partizioni, partizioni e unità di ricerca. Viene illustrato un esempio di come un singolo indice sia esteso tra quattro unità di ricerca in un servizio con due repliche e due partizioni. Ognuna delle quattro unità di ricerca archivia solo la metà delle partizioni dell'indice. Le unità di ricerca nella colonna sinistra archiviano la prima metà delle partizioni, che comprendono la prima partizione, mentre quelle nella colonna destra archiviano la seconda metà delle partizioni, che comprendono la seconda partizione. Poiché sono presenti due repliche, sono presenti due copie di ogni partizione di indice. Le unità di ricerca nella riga superiore archiviano una copia, che comprende la prima replica, mentre quelle nella riga inferiore archiviano un'altra copia, che comprende la seconda replica.

Gli indici di ricerca vengono partizionati tra le partizioni.

Il diagramma precedente è solo un esempio. Sono possibili molte combinazioni di partizioni e repliche, fino a un massimo di 36 unità di ricerca totali.

In Ricerca cognitiva, la gestione delle partizioni è un dettaglio di implementazione e non configurabile, ma sapendo che un indice è partizionato consente di comprendere le anomalie occasionali nei comportamenti di classificazione e completamento automatico:

  • Anomalie di classificazione: i punteggi di ricerca vengono calcolati prima a livello di partizione e quindi aggregati in un singolo set di risultati. A seconda delle caratteristiche del contenuto della partizione, le corrispondenze di una partizione potrebbero essere classificate più elevate rispetto alle corrispondenze in un'altra. Se si nota una classificazione intuitiva dei contatori nei risultati della ricerca, è molto probabile che si verifichino effetti del partizionamento orizzontale, soprattutto se gli indici sono di piccole dimensioni. È possibile evitare queste anomalie di classificazione scegliendo di calcolare i punteggi a livello globale nell'intero indice, ma in questo modo si verifica una riduzione delle prestazioni.

  • Anomalie di completamento automatico: le query di completamento automatico, in cui le corrispondenze vengono effettuate nei primi caratteri di un termine parzialmente immesso, accettano un parametro fuzzy che perdona piccole deviazioni nell'ortografia. Per il completamento automatico, la corrispondenza fuzzy è vincolata ai termini all'interno della partizione corrente. Ad esempio, se una partizione contiene "Microsoft" e viene immesso un termine parziale di "micor", il motore di ricerca corrisponderà a "Microsoft" in tale partizione, ma non in altre partizioni che contengono le parti rimanenti dell'indice.

Approccio alla stima

La capacità e i costi di esecuzione del servizio vanno a portata di mano. I livelli impongono limiti a due livelli: il contenuto (un conteggio degli indici in un servizio, ad esempio) e l'archiviazione. È importante considerare entrambi perché il limite raggiunto per primo è il limite effettivo.

I conteggi degli indici e di altri oggetti sono in genere definiti dai requisiti aziendali e tecnici. Ad esempio, potrebbero essere presenti più versioni dello stesso indice per lo sviluppo, il test e la produzione attivi.

Le esigenze di archiviazione sono determinate dalle dimensioni degli indici che si prevede di compilare. Non ci sono solide euristica o generalità che aiutano con le stime. L'unico modo per determinare le dimensioni di un indice è compilarne uno. Le dimensioni saranno basate su dati importati, analisi del testo e configurazione dell'indice, ad esempio se si abilitano suggerimenti, filtri e ordinamento.

Per la ricerca full-text, la struttura dei dati primari è una struttura di indice invertita , che presenta caratteristiche diverse rispetto ai dati di origine. Per un indice invertito, le dimensioni e la complessità sono determinate dal contenuto, non necessariamente dalla quantità di dati inseriti. Un'origine dati di grandi dimensioni con ridondanza elevata può comportare un indice inferiore rispetto a un set di dati più piccolo che contiene contenuto altamente variabile. È quindi raramente possibile dedurre le dimensioni dell'indice in base alle dimensioni del set di dati originale.

Gli attributi sull'indice, ad esempio l'abilitazione dei filtri e l'ordinamento, influisceranno sui requisiti di archiviazione. L'uso dei suggerimenti ha anche implicazioni di archiviazione. Per altre informazioni, vedere Attributi e dimensioni dell'indice.

Nota

Anche se stimare le esigenze future per gli indici e l'archiviazione può sembrare un'ipotesi, vale la pena fare. Se la capacità di un livello risulta troppo bassa, sarà necessario effettuare il provisioning di un nuovo servizio a un livello superiore e quindi ricaricare gli indici. Non è previsto alcun aggiornamento sul posto di un servizio da un livello a un altro.

Stimare con il livello gratuito

Un approccio per la stima della capacità consiste nell'iniziare con il livello gratuito. Tenere presente che il servizio gratuito offre fino a tre indici, 50 MB di spazio di archiviazione e 2 minuti di tempo di indicizzazione. Può essere difficile stimare una dimensione dell'indice proiettata con questi vincoli, ma questi sono i passaggi seguenti:

  • Creare un servizio gratuito.

  • Preparare un set di dati piccolo e rappresentativo.

  • Creare un indice e caricare i dati. Se il set di dati può essere ospitato in un'origine dati di Azure supportata dagli indicizzatori, è possibile usare la procedura guidata Importa dati nel portale per creare e caricare l'indice. In caso contrario, è possibile usare REST e Postman per creare l'indice ed eseguire il push dei dati. Il modello push richiede che i dati siano sotto forma di documenti JSON, in cui i campi del documento corrispondono ai campi nell'indice.

  • Raccogliere informazioni sull'indice, ad esempio dimensioni. Le funzionalità e gli attributi hanno un impatto sull'archiviazione. Ad esempio, l'aggiunta di suggerimenti (query di ricerca come tipo) aumenterà i requisiti di archiviazione.

    Usando lo stesso set di dati, è possibile provare a creare più versioni di un indice, con attributi diversi in ogni campo, per verificare la variazione dei requisiti di archiviazione. Per altre informazioni, vedere "Implicazioni per l'archiviazione" in Creare un indice di base.

Con una stima approssimativa, è possibile raddoppiare tale importo per due indici (sviluppo e produzione) e quindi scegliere il livello di conseguenza.

Stimare con un livello fatturabile

Le risorse dedicate possono supportare tempi di campionamento ed elaborazione maggiori per stime più realistiche della quantità, delle dimensioni e dei volumi di query dell'indice durante lo sviluppo. Alcuni clienti passano direttamente con un livello fatturabile e quindi revalutano man mano che il progetto di sviluppo matura.

  1. Esaminare i limiti del servizio a ogni livello per determinare se i livelli inferiori possono supportare il numero di indici necessari. Nei livelli Basic, S1 e S2 i limiti di indice sono rispettivamente 15, 50 e 200. Il livello Ottimizzato per l'archiviazione ha un limite di 10 indici perché è progettato per supportare un numero ridotto di indici molto grandi.

  2. Creare un servizio a un livello fatturabile:

    • Iniziare a basso, in Basic o S1, se non si è certi del caricamento proiettato.
    • Iniziare ad alta, a S2 o addirittura S3, se il test include l'indicizzazione su larga scala e i caricamenti di query.
    • Iniziare con Ottimizzazione archiviazione, in L1 o L2, se si indicizza una grande quantità di dati e il carico di query è relativamente basso, come con un'applicazione aziendale interna.
  3. Generare un indice iniziale per determinare il modo in cui i dati di origine vengono convertiti in un indice. Questo è l'unico modo per stimare le dimensioni di un indice.

  4. Monitorare l'archiviazione, i limiti del servizio, il volume di query e la latenza nel portale. Il portale mostra le query al secondo, le query limitate e la latenza di ricerca. Tutti questi valori consentono di decidere se è stato selezionato il livello corretto.

  5. Aggiungere repliche se è necessaria una disponibilità elevata o se si verificano prestazioni di query lente.

    Non sono disponibili linee guida sul numero di repliche necessarie per supportare i caricamenti delle query. Le prestazioni delle query dipendono dalla complessità delle query e dai carichi di lavoro concorrenti. Sebbene l'aggiunta di repliche consenta certamente di migliorare le prestazioni, il risultato non è strettamente lineare. L'aggiunta di tre repliche, infatti, non garantisce una velocità effettiva triplicata. Per indicazioni sulla stima di QPS per la soluzione, vedere Scalabilità per le prestazionie Monitorare le query.

Nota

I requisiti di archiviazione possono essere gonfiati se si includono dati che non verranno mai cercati. Idealmente, i documenti contengono solo i dati necessari per l'esperienza di ricerca. I dati binari non sono ricercabili e devono essere archiviati separatamente (ad esempio in una tabella o in un archivio BLOB di Azure). Un campo deve quindi essere aggiunto nell'indice per contenere un riferimento URL ai dati esterni. La dimensione massima di un singolo documento di ricerca è di 16 MB (o meno se si caricano più documenti in una richiesta). Per altre informazioni, vedere Limiti del servizio in Ricerca cognitiva di Azure.

Considerazioni sul volume delle query

Le query al secondo (QPS) sono una metrica importante durante l'ottimizzazione delle prestazioni, ma in genere è solo una considerazione di livello se si prevede un volume di query elevato all'inizio.

I livelli Standard possono fornire un equilibrio tra repliche e partizioni. È possibile aumentare il turnaround delle query aggiungendo repliche per il bilanciamento del carico o aggiungendo partizioni per l'elaborazione parallela. È quindi possibile ottimizzare le prestazioni dopo il provisioning del servizio.

Se si prevede un numero elevato di volumi di query sostenuti fin dall'inizio, è consigliabile prendere in considerazione livelli Standard più elevati, supportati da hardware più potente. È quindi possibile portare offline le partizioni e le repliche o anche passare a un servizio di livello inferiore, se tali volumi di query non si verificano. Per altre informazioni su come calcolare la velocità effettiva delle query, vedere Ricerca cognitiva di Azure prestazioni e ottimizzazione.

I livelli ottimizzati per l'archiviazione sono utili per carichi di lavoro di dati di grandi dimensioni, supportando l'archiviazione di indici più complessivamente disponibile quando i requisiti di latenza delle query sono meno importanti. È comunque consigliabile usare repliche aggiuntive per il bilanciamento del carico e altre partizioni per l'elaborazione parallela. È quindi possibile ottimizzare le prestazioni dopo il provisioning del servizio.

Contratti di servizio

Le funzionalità del livello gratuito e dell'anteprima non sono coperte dai contratti di servizio.The Free tier and preview features are not covered by service-level agreement (SLAs). Per tutti i livelli fatturabili, i contratti di servizio diventano effettivi quando viene effettuato il provisioning di una ridondanza sufficiente per il servizio. È necessario avere due o più repliche per i contratti di servizio di query (lettura). È necessario avere tre o più repliche per i contratti di servizio di query e indicizzazione (lettura/scrittura). Il numero di partizioni non influisce sui contratti di servizio.

Suggerimenti per la pianificazione della capacità

  • Consentire alle metriche di compilare le query e raccogliere dati relativi ai modelli di utilizzo (query durante l'orario di ufficio, indicizzazione durante le ore di minore attività). Usare questi dati per informare le decisioni relative al provisioning dei servizi. Anche se non è pratico a cadenza oraria o giornaliera, è possibile regolare dinamicamente le partizioni e le risorse per adattare le modifiche pianificate nei volumi di query. È anche possibile gestire modifiche non pianificate ma sostenute se i livelli sono sufficientemente lunghi da giustificare l'azione.

  • Tenere presente che l'unico aspetto negativo del provisioning è che potrebbe essere necessario rimuovere un servizio se i requisiti effettivi sono maggiori delle stime. Per evitare interruzioni del servizio, creare un nuovo servizio a un livello superiore ed eseguirlo affiancato fino a quando tutte le app e le richieste non hanno come destinazione il nuovo endpoint.

Quando aggiungere capacità

Inizialmente, un servizio viene allocato un livello minimo di risorse costituito da una partizione e una replica. Il livello scelto determina le dimensioni e la velocità della partizione e ogni livello è ottimizzato in base a un set di caratteristiche che rientrano in vari scenari. Se si sceglie un livello superiore, potrebbe essere necessario un numero inferiore di partizioni rispetto a se si usa S1. Una delle domande che è necessario rispondere tramite test autoindirizzato è se una partizione più grande e più costosa produce prestazioni migliori rispetto a due partizioni più economiche in un servizio di cui è stato effettuato il provisioning a un livello inferiore.

Un singolo servizio deve disporre di risorse sufficienti per gestire tutti i carichi di lavoro (indicizzazione e query). Nessuno dei due carichi di lavoro viene eseguito in background. È possibile pianificare l'indicizzazione per i tempi in cui le richieste di query sono naturalmente meno frequenti, ma il servizio non assegna in altro modo priorità a un'attività rispetto a un'altra. Inoltre, una certa quantità di ridondanza riduce le prestazioni delle query quando i servizi o i nodi vengono aggiornati internamente.

Alcune linee guida per determinare se aggiungere capacità includono:

  • Soddisfare i criteri di disponibilità elevata per il contratto di servizio
  • La frequenza degli errori HTTP 503 aumenta
  • Sono previsti volumi di query di grandi dimensioni

Come regola generale, le applicazioni di ricerca tendono a richiedere più repliche rispetto alle partizioni, in particolare quando le operazioni del servizio sono distorte nei carichi di lavoro di query. Ogni replica è una copia dell'indice, consentendo al servizio di bilanciare il carico delle richieste su più copie. Il bilanciamento del carico e la replica di un indice vengono gestiti da Ricerca cognitiva di Azure ed è possibile modificare il numero di repliche allocate per il servizio in qualsiasi momento. È possibile allocare fino a 12 repliche in un servizio di ricerca Standard e 3 repliche in un servizio di ricerca Basic. L'allocazione delle repliche può essere eseguita dal portale di Azure o da una delle opzioni a livello di codice.

Le applicazioni di ricerca che richiedono l'aggiornamento dei dati quasi in tempo reale avranno bisogno in proporzione di più partizioni che repliche. L'aggiunta di partizioni distribuisce le operazioni di lettura/scrittura su un numero più ampio di risorse di calcolo. Offre inoltre più spazio su disco per l'archiviazione di documenti e indici aggiuntivi.

Infine, gli indici più grandi richiedono più tempo per eseguire query. Di conseguenza, si noterà che ogni aumento incrementale delle partizioni richiede un aumento delle repliche proporzionale ma più limitato. La complessità e il volume delle query influiscono sulla rapidità di esecuzione delle stesse.

Nota

L'aggiunta di più repliche o partizioni aumenta il costo dell'esecuzione del servizio e può introdurre lievi variazioni nella modalità di ordinamento dei risultati. Assicurarsi di controllare il calcolatore dei prezzi per comprendere le implicazioni di fatturazione dell'aggiunta di altri nodi. Il grafico seguente consente di fare riferimento incrociato al numero di unità di ricerca necessarie per una configurazione specifica. Per altre informazioni sull'impatto delle repliche aggiuntive sull'elaborazione delle query, vedere Ordinare i risultati.

Aggiungere o ridurre repliche e partizioni

  1. Accedere al portale di Azure e selezionare il servizio di ricerca.

  2. In Impostazioni aprire la pagina Scalabilità per modificare repliche e partizioni.

    Lo screenshot seguente mostra un provisioning Basic Standard con una replica e una partizione. La formula nella parte inferiore indica il numero di unità di ricerca in uso (1). Se il prezzo unitario era $100 (non un prezzo reale), il costo mensile di esecuzione di questo servizio sarebbe $100 in media.

    Pagina Ridimensiona che mostra i valori correnti

  3. Usare il dispositivo di scorrimento per aumentare o diminuire il numero di partizioni. Selezionare Salva.

    In questo esempio viene aggiunta una seconda replica e una seconda partizione. Si noti il numero di unità di ricerca; è ora quattro perché la formula di fatturazione è le repliche moltiplicate per partizioni (2 x 2). Il raddoppio della capacità supera il doppio del costo dell'esecuzione del servizio. Se il costo unitario di ricerca era di $100, la nuova fattura mensile sarebbe ora pari a $400.

    Per i costi correnti per unità di ogni livello, visitare la pagina Prezzi.

    Aggiungere repliche e partizioni

  4. Dopo il salvataggio, è possibile controllare le notifiche per confermare che l'azione è riuscita.

    Salvare le modifiche

    Il completamento delle modifiche alla capacità può richiedere da 15 minuti fino a diverse ore. Non è possibile annullare dopo l'avvio del processo e non è disponibile alcun monitoraggio in tempo reale per le rettifiche di replica e partizione. Tuttavia, il messaggio seguente rimane visibile mentre sono in corso le modifiche.

    Messaggio di stato nel portale

Nota

Dopo il provisioning di un servizio, non può essere aggiornato a un livello superiore. È necessario creare un servizio di ricerca a un nuovo livello e ricaricare gli indici. Per informazioni sul provisioning dei servizi, vedere Creare un servizio Ricerca cognitiva di Azure nel portale.

Modalità di gestione delle richieste di scalabilità

Al ricevimento di una richiesta di scalabilità, il servizio di ricerca:

  1. Controlla se la richiesta è valida.
  2. Avvia il backup di dati e informazioni di sistema.
  3. Verifica se il servizio è già in uno stato di provisioning (attualmente aggiunta o eliminazione di repliche o partizioni).
  4. Avvia il provisioning.

Il ridimensionamento di un servizio può richiedere meno di 15 minuti o oltre un'ora, a seconda delle dimensioni del servizio e dell'ambito della richiesta. Il backup può richiedere diversi minuti, a seconda della quantità di dati e del numero di partizioni e repliche.

I passaggi precedenti non sono completamente consecutivi. Ad esempio, il sistema avvia il provisioning quando può farlo in modo sicuro, che potrebbe essere durante la chiusura del backup.

Errori durante il ridimensionamento

Il messaggio di errore "Le operazioni di aggiornamento del servizio non sono consentite in questo momento perché si sta elaborando una richiesta precedente" viene causata dalla ripetizione di una richiesta per ridurre o aumentare quando il servizio sta già elaborando una richiesta precedente.

Risolvere questo errore controllando lo stato del servizio per verificare lo stato del provisioning:

  1. Usare l'API REST di gestione, Azure PowerShell o l'interfaccia della riga di comando di Azure per ottenere lo stato del servizio.
  2. Chiama get service
  3. Controllare la risposta per "provisioningState": "provisioning"

Se lo stato è "Provisioning", attendere il completamento della richiesta. Lo stato deve essere "Riuscito" o "Non riuscito" prima che venga tentata un'altra richiesta. Non è disponibile alcun stato per il backup. Il backup è un'operazione interna ed è improbabile che sia un fattore in qualsiasi interruzione di un esercizio di scalabilità.

combinazioni di partizioni e repliche

Il servizio Basic prevede esattamente una partizione e fino a tre repliche, per un massimo di tre unità di ricerca. Le repliche sono l'unica risorsa regolabile. Per la disponibilità elevata relativa alle query è necessario un minimo di due repliche.

Tutti i servizi di ricerca ottimizzati per l'archiviazione e standard possono assumere le combinazioni seguenti di repliche e partizioni, soggetti al limite 36-SU consentito per questi livelli.

1 partizione 2 partizioni 3 partizioni 4 partizioni 6 partizioni 12 partizioni
1 replica. 1 unità di ricerca 2 unità di ricerca 3 unità di ricerca 4 unità di ricerca 6 unità di ricerca 12 unità di ricerca
2 repliche 2 unità di ricerca 4 unità di ricerca 6 unità di ricerca 8 unità di ricerca 12 unità di ricerca 24 unità di ricerca
3 repliche 3 unità di ricerca 6 unità di ricerca 9 unità di ricerca 12 unità di ricerca 18 unità di ricerca 36 unità di ricerca
4 repliche 4 unità di ricerca 8 unità di ricerca 12 unità di ricerca 16 unità di ricerca 24 unità di ricerca N/D
5 repliche 5 unità di ricerca 10 unità di ricerca 15 unità di ricerca 20 unità di ricerca 30 unità di ricerca N/D
6 repliche 6 unità di ricerca 12 unità di ricerca 18 unità di ricerca 24 unità di ricerca 36 unità di ricerca N/D
12 repliche 12 unità di ricerca 24 unità di ricerca 36 unità di ricerca N/D N/D N/D

Le unità di ricerca, i prezzi e le capacità sono illustrati in dettaglio nel sito web di Azure. Per altre informazioni, vedere Dettagli prezzi.

Nota

Il numero di repliche e partizioni divide equamente per 12 (in particolare 1, 2, 3, 4, 6, 12). Ricerca cognitiva di Azure pre-divide ogni indice in 12 partizioni in modo che possa essere distribuito in parti uguali in tutte le partizioni. Ad esempio, se il servizio ha tre partizioni e si crea un indice, ogni partizione conterrà quattro partizioni dell'indice. Come Ricerca cognitiva di Azure partizioni di un indice è un dettaglio dell'implementazione, soggetto a modifiche nelle versioni future. Sebbene il numero attualmente sia 12, tale numero potrebbe non essere 12 in futuro.

Passaggi successivi