2010-02-15 15 views
8

Ho implementato MS Search Server 2010 e finora è davvero buono. Sto facendo le query di ricerca tramite il loro servizio web, ma a causa dell'inconsistente results, sto pensando invece di mettere in cache il risultato.Memorizzazione dei risultati di ricerca per cercapersone e ordinamento

Il sito è una piccola intranet (500 dipendenti), quindi non dovrebbe esserci alcun problema, ma sono curioso di sapere come procedere se si trattasse di un sito più grande.

Ho un po 'su Google, ma non ho mai trovato nulla di specifico. Quindi, alcune domande:

  • Quali altri approcci ci sono? E perché sono migliori?
  • Quanto costa memorizzare un dataview di 400-500 righe? Quali dimensioni sono fattibili?
  • Altri punti da tenere in considerazione.

Qualsiasi ingresso è benvenuto :)

+0

Hai guardato Apache SOLR? –

risposta

2

È necessario impiegare molte tecniche per rimuoverlo correttamente.

Primo, è necessario un qualche tipo di livello di persistenza. Se si sta utilizzando un semplice sito Web vecchio, la sessione dell'utente sarebbe il livello più logico da utilizzare. Se si utilizzano servizi Web (ovvero senza sessioni) e si effettuano chiamate attraverso un client, è necessario disporre di una sorta di livello applicazione (una sorta di sessione condivisa) per i propri servizi. Perché? Questo strato ospiterà la cache dei risultati del database.

Secondo, è necessario un metodo di memorizzazione nella cache dei risultati in qualsiasi contenitore utilizzato (sessione o livello di applicazione dei servizi Web). Puoi farlo in due modi ... Se la query è qualcosa che qualsiasi utente può fare, allora funzionerà un semplice hash della query, e potrai condividere questo risultato memorizzato tra gli altri utenti. Probabilmente vorresti ancora una sorta di GUID per il risultato, in modo che tu possa passarlo nella tua applicazione client, ma avere una ricerca hash dalle query ai risultati sarà utile. Se queste query sono univoche, è sufficiente utilizzare il GUID univoco per il risultato della query e inoltrarlo all'applicazione client. In questo modo è possibile eseguire la funzionalità di memorizzazione nella cache ...

Il meccanismo di memorizzazione nella cache può incorporare una sorta di buffer o coda di lunghezza fissa ... in modo che i vecchi risultati vengano automaticamente eliminati/rimossi man mano che ne vengono aggiunti di nuovi. Quindi, se arriva una query che è un errore di cache, verrà eseguita normalmente e aggiunta alla cache.

Terzo, si sta andando a voler in qualche modo alla pagina l'oggetto risultato ... il pattern Iterator funziona bene qui, anche se probabilmente qualcosa di più semplice potrebbe funzionare ... come recuperare X quantità di risultati a partire dal punto di Y. Tuttavia, il pattern Iterator potrebbe essere migliore, in quanto è possibile rimuovere successivamente il meccanismo di memorizzazione nella cache e la pagina direttamente dal database, se lo si desidera.

Quarto, è necessaria una sorta di meccanismo di pre-recupero (come suggerito da altri). Dovresti avviare una discussione che eseguirà la ricerca completa e nella tua discussione principale esegui una rapida ricerca con il numero X numero di articoli. Si spera che quando l'utente tenta il paging, il secondo thread sarà terminato e il risultato completo sarà ora nella cache. Se il risultato non è pronto, puoi semplicemente incorporare una semplice logica di caricamento dello schermo.

Questo dovrebbe farti un po 'di strada ... fammi sapere se vuoi chiarimenti/maggiori dettagli su una particolare parte.

Ti lascio qualche altro suggerimento ...

  1. Non si vuole essere l'invio l'intero risultato al app cliente (se si utilizza Ajax o qualcosa come un iPhone app). Perché? Bene perché questo è un enorme spreco. L'utente probabilmente non sta andando a pagina attraverso tutti i risultati ... ora hai appena inviato oltre 2 MB di campi risultato per niente.

  2. Javascript è un linguaggio fantastico, ma ricorda che è ancora un linguaggio di scripting lato client ... non vuoi rallentare troppo l'esperienza utente inviando enormi quantità di dati per il tuo client Ajax da gestire. Basta inviare il risultato prefetch al client e ai risultati aggiuntivi della pagina come pagine utente.

  3. Astrazione di astrazione astrazione ... si desidera astrarre la cache, l'interrogazione, il paging, il prefetching ... il più possibile. Perché? Bene, diciamo che vuoi cambiare database o vuoi fare una pagina direttamente dal database invece di usare un oggetto risultato nella cache ... beh, se lo fai bene, è molto più facile cambiare in seguito. Inoltre, se si utilizzano i servizi Web, molte altre applicazioni possono utilizzare questa logica in seguito.

Ora, probabilmente ho suggerito una soluzione ingegnerizzata per quello che ti serve :). Ma se riesci a farcela usando tutte le tecniche giuste, imparerai una tonnellata e avrai un'ottima base nel caso tu voglia estendere la funzionalità o riutilizzare questo codice.

Fatemi sapere se avete domande.

+0

Ho dimenticato di rispondere. Scusate. Ho usato il caching per le chiamate di servizio web e la sessione per le ricerche sul server web. Grazie per la risposta esaustiva, davvero utile! – Mattias

0

devo ammettere che io non sono terribilmente familiarità con MS Search Server quindi questo potrebbe non essere applicabile. Ho spesso avuto situazioni in cui un'applicazione doveva cercare tra centinaia di milioni di record per i set di risultati che dovevano essere ordinati, impaginati e sottoposti a ricerca secondaria in un server SQL. Generalmente ciò che faccio è un approccio in due fasi. Per prima cosa raccolgo i primi risultati "x" che devono essere visualizzati e inviarli al browser per una visualizzazione rapida. In secondo luogo, su un altro thread, ho terminato la query completa e spostato i risultati in una tabella temporanea in cui possono essere archiviati e recuperati più rapidamente. Ogni query fornita può avere migliaia o decine di migliaia di risultati, ma in confronto alle centinaia di milioni o addirittura miliardi di record totali, questo sottoinsieme più piccolo può essere manipolato molto facilmente dalla tabella temporanea. Mette anche meno stress sulle altre tabelle man mano che si verificano le query. Se l'utente ha bisogno di una seconda pagina di record, o ha bisogno di ordinarli, o vuole solo un sottoinsieme della query originale, questo viene tutto estratto dalla tabella temporanea.

La logica quindi deve essere messa in atto per controllare le tabelle temporanee obsolete e rimuoverle. Questo è abbastanza semplice e lascio che SQL Server gestisca tale funzionalità. Infine, la logica deve essere messa in atto per quando la query originale cambia (cambiamenti significativi del perimetro) in modo che un nuovo set di dati possa essere estratto e inserito in una nuova tabella temporanea per ulteriori interrogazioni. Tutto ciò è relativamente semplice.

Gli utenti sono così abituati a suddividere il secondo tempo di ritorno da luoghi come Google e questo modello mi dà abbastanza flessibilità per realizzarlo senza il software specializzato e l'hardware che usano.

Spero che questo aiuti un po '.

0

La risposta di Tim è un ottimo modo per gestire le cose se si ha la possibilità di eseguire la query iniziale in un secondo thread e la logica (paging/ordinamento/filtro) da applicare ai risultati richiede un'azione sul server. ... altrimenti ....

Se è possibile utilizzare AJAX, è possibile chiamare un set di risultati di 500 righe nella pagina e cercarlo o ordinarlo sul client. Questo può portare ad alcune caratteristiche davvero interessanti .... dai un'occhiata alle soluzioni datagrid di jQueryUI e Dojo per l'ispirazione!

E per funzioni davvero intensive come filtri regex arbitrari e riordino di colonne drag-and-drop è possibile liberare completamente il server.

Il caricamento dei dati nel browser consente inoltre di chiamare i dati di supporto (anteprime delle pagine, ecc.) In quanto "li richiede" dall'utente.

Il problema principale è limitare i dati restituiti per risultato a ciò che effettivamente utilizzerai per i tuoi ordinamenti e filtri.

Le possibilità sono infinite :)

+0

Ma si spera che il tuo algoritmo di ricerca porti presto dei buoni risultati, quindi dovresti caricare inutilmente 490 risultati e le immagini di anteprima delle pagine –

1

Suona come la parte lenta della ricerca è la ricerca full-text, non il recupero risultato. Che ne dici di mettere in cache gli ID dei record delle risorse risultanti? Inoltre, poiché potrebbe essere vero che le query di ricerca sono spesso duplicate, memorizzare un hash della query di ricerca, la query e le risorse corrispondenti. Quindi puoi recuperare la prossima pagina dei risultati per ID. Funziona anche con AJAX.

Poiché si tratta di una intranet e si possono controllare le risorse ricercate, è possibile anche pre-calcolare la corrispondenza di una risorsa nuova o aggiornata con le query più comuni durante il periodo di inattività.

Problemi correlati