Le prestazioni di un motore di Information Retrieval si valutano, tra gli altri aspetti, nella rapidità con la quale esso è in grado di dare un risultto che sia assolutamente esatto, certo o, in caso di ricerche compiute in modo incerto, limitando quanto più possibile gli effetti di rumore ma soprattutto di silenzio.
A questo scopo ci sono accorgimenti che possono essere presi in esame per miglioare il comportamento del server limitando la perdita di funzionalità. In altre parole, si può accettare una minore precisione o rinunciare ad alcune funzionalità fruibili dopo la selezione per rendere più veloce e performante la stessa.
Quello che va sottolineato è che ci sono operazioni che risultano particolarmente gravose per il server, operazioni che richiedono elaborazioni più complesse per essere condotte a termine.
Allo stesso modo ci sono operazioni che il server compie, diciamo preventivamente, durante la fase di selezione che possono dimostrarsi non necessarie in quanto non utilizzate nelle fasi successive (consultazione dell'esito della selezione e fruizione dei documenti selezionati).
Vediamo di seguito come è buona norma comportarsi.
Ci sono diversi modi per ottenere lo stesso risultato. Alcuni sono più corretti di altri o per lo meno è buona norma scegliere la modalità più opportuna per soddisfare una particolare esigenza.
Partendo dal presupposto che sarebbe bene che qualsiasi operatore che abbia a che fare con un'applicazione eXtraWAy conoscesse le norme descritte in questo capitolo, esse sono principalmente pensate per dare a chi sviluppa simili applicazioni delle linee guida su come ottenere il massimo dalle proprie selezioni.
Questo capitolo si sofferma su carico di lavoro rappresentato, per un server eXtraWay, da selezioni la cui sintassi risulti, ad esempio, ripetitiva oppure ricca di adiacenze e/o negazioni.
La prima buona norma consiste nel cercare di evitare le ripetizioni. Partiamo da un facile esempio Il concetto di...
('a' AND ('b' OR 'c') ) AND ('d' AND ('b' OR 'c')) ... può essere rappresentato evitando alcune ripetizioni nella forma...
('a' AND 'd') AND ('b' OR 'c') Chiaramente questo è solo un esempio ma ci da uno spunto interessante. Se invece di cercare 'a' e 'd' assieme con una ulteriore clausola che unisce in OR 'b' e 'c' dovessimo compiere ricerche distinte per 'a' e per 'd' avremmo due singole frasi di ricerca come segue...
('a' AND ('b' OR 'c')) ...e...
('d' AND ('b' OR 'c')) Questa divisione pone in evidenza un ulteriore aspetto. C'è una clausola che accomuna le due selezioni, quella che unisce in OR 'b' e 'c', che viene ripetuta due volte. Inoltre le due selezioni hanno al loro interno operatori AND ed OR che, per il momento, definiremo opposti. Sappiamo quindi che una parte della prima ricerca si potrebbe riciclare nella seconda. Per farlo le due ricerche vanno spezzate in... 3! Prima si risolverà la clausola comune...
('b' OR 'c') ...e l'esito della selezione, rappresentato da un identificatore univoco di selezione, potrà essere usato nelle altre operazioni. Supponiamo che l'Id univoco di selezione sia il seguente 3se123456789, le selezioni successive assumerebbero il seguente aspetto...
('a' AND [?SEL]="3se123456789") ...e...
('d' AND [?SEL]="3se123456789") Questa trasformazione evidenzia due aspetti.
Il primo è che una particolare clausola viene effettivamente riciclata in due successive selezioni. Tanto superiore è il numero di volte in cui una simile clausola può essere riciclata e tanto maggiore sarà il risparmio in termini di prestazioni. Va inoltre detto che se la clausola sintetizzata in una selezione preventiva comporta l'uso di numerose chiavi di selezione o di chiavi aventi catene di riferimenti molto ampie (chiavi, in sostanza, che selezionano molti documenit), il risparmio può divenire assolutamente sensibile.
Il secondo, più velato ma non meno importante, consiste nel fatto che nessuna delle tre selezioni presenta ora degli operatori opposti. La prima selezione prevede solo operatori 'OR' e le successive solo operatori 'AND'. A fronte di selezioni complesse vale la pena sottolineare come possa essere maggiormente performante compiere selezioni separate, che prevedano uno solo di questi due tipi d'operatore, per poi combinare tra loro gli esiti anziché eseguire direttamente la selezione complessa. Ovviamente, la cardinalità dei vocabolari interessati ovvero dei documenti in archivio è la più sensibile discriminante.
A quanto detto precedentemente va aggiunto il carico di lavoro rappresentato dalle ricerche in adiacenza.
Esse sono una ulteriore restrizione delle ricerche con operatore AND in quanto selezionano quel sottoinsieme di documenti che non solo soddisfano la condizione di presenza contemporanea ma anche la condizione di distanza massima tra i termini oggetto della selezione. (Maggiori dettagli sono disponibili consultando la documentazione: Ricerca in adiacenza. Modalità di ricerca e comportamento del server eXtraWay)
Questo comporta che quando un documento sembra papabile, esso va verificato nelle distanze tra i termini e solo se passa questo secondo esame risulta essere un documento selezionato.
E' convenzione ormai radicata nel tempo che nelle ricerche sui canali multi valore (Sintassi di Ricerca: Canali mono e multi valore.) l'assenza di un operatore tra due operandi sottintenda l'adiacenza, mentre per ottenere una ricerca per adiacenza tra valori di più canali (ad esempio valori di attributi della stessa ripetizione di un elemento ovvero in generale ricerche per bacino di pescaggio) sia necessario esplicitare l'operatore ADJ.
Quando quest'operatore è sottointeso, quindi assente tra due operandi applicati ad un canale multi valore, non è infrequente che l'esigenza effettiva sia quella di esprimere un'AND e non un'ADJ. Pensiamo, ad esempio, alle caselle di ricerca libera che trovano posto normalmente nelle applicazioni. Il concetto di prossimità non è sempre in possesso degli operatori che, esprimendo una sequenza di termini, non intendono in realtà richiedere che essi sia presenti e prossimi, ma solo che il documento li comprenda tutti, indipendentemente dalla loro posizione.
Va da se, quindi, che una simile ricerca darebbe un risultato non buono sotto due aspetti. Il primo è una sorta di involontario silenzio, dato dal fatto che soddisfando l'adiacenza i documenti selezionati potrebbero essere inferiori, anche molto inferiori, al numero di documenti che si troverebbero se l'operatore sottinteso fosse trattato come l'AND. Da un lato quest'inconveniente può essere aggirato esprimendo una distanza tra i termini sufficientemente ampia da colmare questo silenzio.
Simili selezioni posson quindi essere effettuate con il modificatore di campo Adj_Ignore (Vds.:Modificatori dei singoli Canali di ricerca) in modo che l'utente non sia tenuto a conoscere il comportamento del server in assenza di operatori logici.
Le ricerche con Wild Card prevedono la determinazione di tutte le chiavi di vocabolario che soddisfano l'espressione data.
L'approccio alle Wild Cards ha due aspetti. Nello scenario complesso si esprime una chiave che contiene più Wild Cards per soddisfare una particolare condizione, che potemmo quasi identificare con una maschera di caratteri fissi e variabili. In questo caso entra spesso in gioco il carattere '?'.
Lo scenario opposto, decisamente più frequente, vede l'uso della sola Wild Card '*' come ultimo carattere della chiave ricercata.
In questo secondo caso la sintassi della ricerca, se espressa differentemente, può risultare particolarmente vantaggiosa in termini presazionali. Ciò può avvenire ad alcune condizioni.
[canale]=<radice>*
[canale]=AB*
[canale]={AB|AC} [canale]={AB^ABZZZZZZZZ} Le ricerche basate su Range di valori possono interessare un elevato numero di chiavi e/o chiavi con una catena di riferimenti (documenti selezionabili) molto ampia. In entrambe i casi, l'estensione ad un simile Range può comportare un dispendio di tempo per la composizione di un semilavorato da utilizzare poi nella selezione finale. In alcuni casi può essere utile esplicitare che la selezione deve procedere ad una forma semplificata nel produrre il semilavorato applicando al canale interessato il modificatore SimpleExt (Vds.: Modificatori dei singoli Canali di ricerca).
Le ricerche si considerano solitamente positive.
Ci si abitua a ragionare nei termini di: cercami nell'archivio tutti i documenti che parlano di questo o quello o che contengono questo o quel valore.
In alcuni casi, però, risulta necessario rilevare l'assenza di un valore o compiere selezioni mirate ad ottenere l'insieme complementare di una ricerca positiva.
Questi obiettivi possono essere ottenuti in modi diversi.
A seconda della dimensione dell'archivio, del numero delle chiavi diverse appartenenti al vocabolario in esame e del numero dei documenti che sono presenti in archivio può infatti essere vantaggioso compiere una ricerca positiva inversa al posto di una ricerca negativa.
Selezionare i documenti che non contengono un dato valore corrisponde, in sostanza, a selezionare i documenti che contengono qualsiasi altro valore ma non quello. Se il vocabolario del canale in esame è ragionevolmente contenuto, questa ricerca darà lo stesso esito della ricerca negativa ma con tempi potenzialmente più contenuti. Solitamente compiere la ricerca negativa di un singolo valore non è un'operazione gravosa, la cosa però cambia quando sono più termini ad entrare in gioco (ad esempio la negazione di un range può essere fatta corrispondere alla ricerca positiva dell'anti range).
Va inoltre aggiunto che una ricerca negativa comporta una complicazione nei test che eleggono i documenti potenzialmente da selezionare. Se la negazione interessa l'intera selezione ed essa è articolata, può essere maggiormente performante compiere una selezione positiva e poi negare l'esito intero della selezione. Particolare riguardo va posto alle selezioni con adiacenza. La negazione di un'adiacenza è, malauguratamente, una delle operazioni più complesse da risolvere per il server eXtraWay (o quanto meno una di quelle in cui i tentativi di previsione non portano ai risultati voluti). Anche in questo caso, quindi, può essere meglio compiere le ricerche positive per le clausole di adiacenza e poi usare gli Id di selezione ottenuti nella successiva ricerca ove essi potranno essere negati.
In fine, visto che compiere una ricerca negativa corrisponde spesso a voler cercare tutti i documenti che non contengono non un valore ben definito ma alcun valore in un canale dato, è buona norma configurare l'archivio perché per il canale richiesto venga costituita la chiave nulla, una chiave che viene alimentata in automatico ogni volta che in un documento un certo canale, rappresentato da un elemento o attributo, non è presente oppure è presente ma assolutamente privo di valore. In tal modo la ricerca per la chiave nulla consente di affrontare anche quest'esigenza come una ricerca positiva.
Il server eXtraWay compie una serie di operazioni a corredo della selezione nello stilare il file contenente l'elenco dei documenti selezionati. Senza interessarci, ora, dell'ordinamento dei documenti che comporta un ulteriore aggravio in termini di prestazioni in ricerca, vediamo com'è possibile ridurre i tempi di selezione del server agendo su questa lavorazione a margine della mera selezione dei documenti.
Tra le attività che il server svolge ci sono le seguenti:
Vediamo di sequito su quali aspetti è possibile intervenire con perdite, più o meno sensibili, di funzionalità.
Come precedentemente annunciato, una delle operazioni svolte dal server consiste nella creazione di una catena dei riferimenti che contiene, per ogni documento selezionato, la posizione in cui si trova il termine che ha concorso alla sua selezione. Essa interessa tutti i termini rilevati e, nel caso di una ricerca per adiacenza, le sole posizioni nel documento in cui i termini posti in adiacenza tra loro hanno soddisfatto le condizioni di ordine e distanza.
Questo comportamento risulta particolarmente interessante quando la visualizzazione dei documenti ne fa uso per mostrare, ad esempio con una diversa colorazione, proprio i termini all'origine della selezione, specie se sono state applicate regole di estensione (ad esempio facendo uso di un thesaurus della lingua italiana) che ci mostri quali termini sono stati scelti (ad esempio per sinonimia con i termini originariamente impostati in ricerca). Altro esempio potrebbe essere quello della visualizzazione dei documenti esito di una ricerca per somiglianza ad uno o più documenti originari. Visualizzando tali documenti i termini evidenzaiti mostreranno in che modo i due documenti sono stati considerati simili.
Oltre alla rappresentazione esteriore dei documenti selezionati, questa catena di riferimenti ha un ruolo cardine nel compiere altre selezioni avvalendosi dell'esito di una selezione precedente. In particolare, quindi, i raffinamenti delle selezioni (ponendo l'esito di una selezione precedente in AND con nuove clausole di ricerca) risulta particolarmente perfomante.
In fine, la stessa catena di riferimenti viene utilizzata per compiere le analisi spettrali ovvero l'accesso ai vocabolari dei canali di ricerca limitato nei contenuti alle chiavi che selezionerebbero un sottoinsieme di un archivio rappresentato, appunto, dall'esito di una selezione.
La fase di costituzione di questa catena di riferimenti, però, risulta essere particolarmente dispendiosa in termini di tempo specie se l'archivio conta un elevato numero di documenti e si stimolano molte chiavi di ricerca o chiavi con catene di riferimenti piuttosto lunghe.
Si da il caso, comunque, che la catena dei riferimenti deve in primo luogo identificare i documenti prensenti nella selezione e solo in un secondo luogo, per un sottoinsieme delle attività possibili, anche la posizione dei termini selezionati nel documento.
E' quindi possibile richiedere al server di compiere la selezione ignorando il dettaglio della posizione delle parole limitandosi a tenere corretta traccia dei documenti. Ad essi viene associata una parola virtuale in posizione fissa pari ad '1' e la selezione, nelle condizioni più gravose, può subire miglioramenti prestazionali notevoli.
Vediamo i comportamenti del server e gli interventi da compiere.
Il server, per default, compila la catena dei riferimenti nel suo formato ricco, quindi con dispendio di tempo.
Per imporre al server, su un dato archivio, il comportamento opposto, sarà sufficiente impostare nel file di configurazione la seguente voce...
<profile type="search.skipiw" value="true"/>
In virtà del comportamento del server, che sia quello di default o l'opposto, si può dinamicamente camiare il comportamento del server modifiando la sintassi di ricerca (Vds.: Modificatori Globali della ricerca):
Torna a Indice delle voci