Configurare Lucene.Net con SQL Server

Question

Qualcuno ha utilizzato Lucene.NET anziché utilizzare la ricerca di testo completo fornita con SQL Server?

Se così fosse, sarei interessato a come l'hai implementato.

Hai ad esempio scritto un servizio Windows che ha interrogato il database ogni ora, quindi salvato i risultati nell'indice lucene.net?

Answer 1

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 incorporato il lettore nell'app e nei servizi web.

Ho usato lucene.net come indicizzatore di database generale, quindi quello che ho recuperato era fondamentalmente DB id (a messaggi di posta elettronica indicizzati) e l'ho usato anche per recuperare informazioni sufficienti per popolare i risultati di ricerca o tale senza toccare il database. Ha funzionato benissimo in entrambi i casi, anche se l'SQL può essere un po 'lento, dato che è necessario avere un ID, selezionare un ID, ecc. Abbiamo risolto questo problema creando una tabella temporanea (con solo la riga ID in essa contenuta) e inserimento di massa da un file (che era l'output di lucene) per poi unirsi alla tabella dei messaggi. È stato molto più veloce.

Lucene non è perfetto, e devi pensare un po 'al di fuori del box di database relazionale, perché in realtà non lo è, ma è molto molto bravo in quello che fa. Vale la pena dare un'occhiata, e, mi è stato detto, non ha il "oops, mi dispiace, è necessario ricostruire nuovamente il tuo indice" problemi che fa FTI di MS SQL.

BTW, avevamo a che fare con 20-50 milioni di email (e circa 1 milione di allegati unici), per un totale di circa 20 GB di indice di lucene credo e 250 + GB di database SQL + allegati.

Le prestazioni sono state fantastiche, per non dire altro - assicuratevi solo di pensare e modificare i vostri fattori di fusione (quando unisce i segmenti dell'indice). Non vi è alcun problema nell'avere più di un segmento, ma ci può essere un GRANDE problema se si tenta di unire due segmenti che contengono 1 milione di elementi ciascuno, e si ha un thread watcher che uccide il processo se ci vuole troppo tempo ... .. (sì, quello ci ha preso a calci in culo per un po '). Quindi mantieni il numero massimo di documenti per thinggie LOW (cioè, non impostarlo su maxint come abbiamo fatto!)

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

Answer 2

penso che questo articolo è un buon punto di partenza:

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

Answer 3

non l'ho ancora fatto contro la base di dati, la sua domanda è un pò aperto.

Se si desidera cercare un db e si può scegliere di utilizzare Lucene, suppongo anche che sia possibile controllare quando i dati vengono inseriti nel database. Se è così, ci sono pochi motivi per interrogare il db per scoprire se è necessario reindicizzare, basta indicizzare mentre si inserisce, o creare una tabella di code che può essere usata per dire a lucene cosa indicizzare.

Penso che non abbiamo bisogno di un altro indicizzatore che ignori ciò che sta facendo, e che reindicizzi ogni volta, o utilizzi risorse inutili.

Answer 4

Ho usato Lucene.NET insieme a MySQL. Il mio approccio era quello di memorizzare la chiave primaria del record db nel documento di Lucene insieme al testo indicizzato.In pseudo codice assomiglia:

• Record Store:

  inserire il testo, gli altri dati alla tabella
  troverete le ultime ID inserito
  Crea documento Lucene
  put (ID, testo) in Lucene documento aggiornamento dell'indice Lucene

• Interrogazione
  ricerca indice Lucene
  012.per ogni doc Lucene nei dati di carico insieme di risultati di DB con l'ID del record memorizzato

Solo per notare, sono passato da Lucene a Sphinx a causa di essa prestazione superba

Answer 5

ho usato anche come lucene.net motore di archiviazione, perché è più semplice distribuire e configurare macchine alternative con un indice rispetto a un database, è solo una copia del file system, è possibile indicizzare su una macchina e copiare semplicemente i nuovi file sulle altre macchine per distribuire l'indice. Tutte le ricerche e i dettagli sono mostrati dall'indice di lucene e il database è usato solo per la modifica. Questa configurazione è stata dimostrata come 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 unisce, ordina, aggrega e filtra tra i risultati del testo completo e il relazionale le colonne sono molto costose in termini di prestazioni, Microsoft afferma che questi problemi sono stati risolti in SQL Server 2008, integrando la ricerca di testo completo all'interno del motore relazionale, ma non l'ho testato. Hanno anche reso l'intera ricerca full-text molto più trasparente, nelle versioni precedenti i stemmer, le stopword e molte altre parti dell'indicizzazione dove erano simili a una scatola nera e difficili da comprendere e nella nuova versione sono più facili da vedere come funzionano.

Con la mia esperienza, se sql server soddisfa le tue esigenze, sarà il modo più semplice, se ti aspetti un sacco di crescita, query complesse o hai bisogno di un grande controllo della ricerca di testo completo, potresti considerare di lavorare con lucene da l'inizio perché sarà più facile scalare e personalizzare.