Domanda

Qualcuno ha utilizzato Lucene.NET anziché utilizzare la ricerca full-text fornita con SQL Server?

Se è così, sarei interessato a come lo hai implementato.

Ad esempio, hai scritto un servizio Windows che interrogava il database ogni ora e poi salvava i risultati nell'indice lucene.net?

È stato utile?

Soluzione

Sì, l'ho usato esattamente per quello che stai descrivendo.Avevamo due servizi: uno per la lettura e uno per la scrittura, ma solo perché avevamo più lettori.Sono sicuro che avremmo potuto farlo con un solo servizio (lo scrittore) e incorporare il lettore nell'app Web e nei servizi.

Ho utilizzato lucene.net come indicizzatore generale del database, quindi quello che ho ottenuto erano fondamentalmente gli ID DB (per i messaggi di posta elettronica indicizzati) e l'ho anche usato per recuperare informazioni sufficienti per popolare i risultati della ricerca o simili senza toccare il Banca dati.Ha funzionato benissimo in entrambi i casi, anche se l'SQL può diventare un po' lento, dato che praticamente devi ottenere un ID, selezionare un ID ecc.Abbiamo risolto questo problema creando una tabella temporanea (con solo la riga ID al suo interno) e inserendola in blocco da un file (che era l'output di lucene), quindi unendoci alla tabella dei messaggi.È stato molto più veloce.

Lucene non è perfetto e devi pensare un po' fuori dagli schemi del database relazionale, perché TOTALMENTE non lo è, ma è molto, molto bravo in quello che fa.Vale la pena dare un'occhiata e, mi è stato detto, non ha i problemi "oops, scusa, devi ricostruire di nuovo il tuo indice" come fa FTI di MS SQL.

A proposito, avevamo a che fare con 20-50 milioni di e-mail (e circa 1 milione di allegati univoci), per un totale di circa 20 GB di indice lucene, credo, e oltre 250 GB di database SQL + allegati.

Le prestazioni sono state fantastiche, per non dire altro: assicurati solo di pensare e modificare i fattori di unione (quando unisce i segmenti dell'indice).Non c'è alcun problema nell'avere più di un segmento, ma può esserci un GRANDE problema se provi a unire due segmenti che contengono 1 milione di elementi ciascuno e hai un thread di osservazione che interrompe il processo se impiega troppo tempo... ..(sì, ci ha fatto il culo per un po').Quindi mantieni BASSO il numero massimo di documenti per oggetto (ovvero, non impostarlo su maxint come abbiamo fatto noi!)

EDIT Corey Trager ha documentato come utilizzare Lucene.NET in BugTracker.NET Qui.

Altri suggerimenti

Non l'ho ancora fatto rispetto al database, la tua domanda è piuttosto aperta.

Se vuoi cercare un db e puoi scegliere di utilizzare Lucene, immagino anche che tu possa controllare quando i dati vengono inseriti nel database.Se è così, non c'è motivo di interrogare il db per scoprire se è necessario reindicizzare, basta indicizzarlo mentre si inserisce o creare una tabella di coda che può essere utilizzata per dire a lucene cosa indicizzare.

Penso che non abbiamo bisogno di un altro indicizzatore che ignora ciò che sta facendo e lo reindicizza ogni volta o utilizza le risorse in modo dispendioso.

Ho usato lucene.net anche come motore di archiviazione, perché è più semplice distribuire e configurare macchine alternative con un indice piuttosto che un database, è solo una copia del filesystem, puoi indicizzare su una macchina e copiare semplicemente i nuovi file sulle altre macchine per distribuire l'indice.Tutte le ricerche e i dettagli vengono mostrati dall'indice lucene e il database viene utilizzato solo per la modifica.Questa configurazione si è rivelata una soluzione molto scalabile per le nostre esigenze.

Per quanto riguarda le differenze tra SQL Server e Lucene, il problema principale con la ricerca full-text di SQL Server 2005 è che il servizio è disaccoppiato dal motore relazionale, quindi join, ordini, aggregazioni e filtri tra i risultati full-text e le colonne relazionali sono molto costosi in termini di prestazioni, Microsoft afferma che questo problema è stato risolto in sql server 2008, integrando la ricerca full text all'interno del motore relazionale, ma non l'ho testato.Hanno anche reso l'intera ricerca del testo completo molto più trasparente, nelle versioni precedenti gli stemmer, le stopword e molte altre parti dell'indicizzazione erano come una scatola nera e difficili da capire, mentre nella nuova versione è più facile vedere come funzionano.

Con la mia esperienza, se SQL Server soddisfa le tue esigenze, sarà il modo più semplice, se ti aspetti molta crescita, query complesse o hai bisogno di un grande controllo della ricerca a testo completo, potresti prendere in considerazione l'idea di lavorare con lucene dall'inizio perché sarà più facile da scalare e personalizzare.

Ho usato Lucene.NET insieme a MySQL.Il mio approccio consisteva nel memorizzare la chiave primaria del record db nel documento Lucene insieme al testo indicizzato.In pseudo codice appare così:

  • Registro del negozio:

    inserire testo e altri dati nella tabella
    ottenere l'ultimo ID inserito
    creare un documento lucene
    Metti (id, testo) in Lucene Document Update Lucene Index

  • Interrogando
    ricerca indice lucene
    per ogni documento Lucene nel set di risultati carica i dati dal DB in base all'ID del record memorizzato

Giusto per notare, sono passato da Lucene a Sfinge grazie alle sue prestazioni eccezionali

Penso che questo articolo sia un buon punto di partenza:

http://www.aspfree.com/c/a/braindump/working-with-lucene-net/

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top