So che ci sono state domande in passato su SQL 2005 rispetto a Lucene.NET ma dal 2008 è uscito e hanno apportato molte modifiche e si chiedeva se chiunque può darmi pro/contro (o link ad un articolo).SQL Server 2008 Ricerca testo completo (FTS) rispetto a Lucene.NET
Ho costruito una knowledge base di medie dimensioni (forse 2 GB di testo indicizzato) sopra l'FTS di SQL Server 2005 nel 2006 e ora l'ho spostato nell'iFTS del 2008. Entrambe le situazioni hanno funzionato bene per me, ma il passaggio dal 2005 al 2008 è stato in realtà un miglioramento per me.
La mia situazione NON era simile a StackOverflow, nel senso che stavo indicizzando i dati che venivano aggiornati solo di notte, tuttavia stavo cercando di unire i risultati di ricerca di più istruzioni CONTAINSTABLE tra loro e alle tabelle relazionali.
Nell'FTS del 2005, questo significava che ogni CONTAINSTABLE avrebbe dovuto eseguire la ricerca sull'indice, restituire i risultati completi e quindi avere il motore DB unire questi risultati alle tabelle relazionali (questo era tutto trasparente per me, ma era accadendo ed era costoso per le domande). L'iFTS del 2008 ha migliorato questa situazione perché l'integrazione del database consente ai molteplici risultati CONTAINSTABLE di diventare parte del piano di query che ha reso più efficienti le ricerche.
Penso che sia i motori FTS del 2005 e del 2008, sia Lucene.NET, ha dei compromessi architettonici che si allineano meglio o peggiorano a un sacco di circostanze del progetto - ho avuto la fortuna che l'aggiornamento abbia funzionato a mio favore. Posso capire completamente perché l'iFTS del 2008 non avrebbe funzionato nella stessa configurazione del 2005 per la natura altamente OLTP di un caso d'uso come StackOverflow.com. Tuttavia, non escluderei la possibilità che l'iFTS 2008 potesse essere isolato dal pesante carico della transazione dell'inserto ... ma sembra anche che potrebbe essere tanto lavoro da compiere quanto spostarsi su Lucene.NET ... e il bello il fattore di Lucene.NET è difficile da ignorare;)
In ogni caso, per me, la facilità e l'efficienza di iFTS di SQL 2008 nella maggior parte delle situazioni probabilmente rende il fattore "cool" di Lucene (sebbene sia facile da usare, non l'ho mai usato in un sistema di produzione, quindi mi sto riservando un commento su questo). Sarei interessante sapere quanto è più efficiente Lucene (è risultato essere? È implementato ora?) In StackOverflow o situazioni simili.
Questo potrebbe aiutare: http://blog.stackoverflow.com/2008/11/sql-2008-full-text-search-problems/
non hanno utilizzato SQL Server 2008 personalmente, anche se sulla base di tale voce del blog, sembra che la funzionalità di ricerca full-text è più lento di quanto non fosse nel 2005.
utilizziamo entrambe le possibilità di ricerca full-text, ma secondo me dipende dai dati stessi e dalle vostre esigenze.
scaliamo con i server Web, e quindi mi piace lucene, perché non ho così tanto carico sul server sql.
per iniziare da null e voler avere una ricerca full-texts preferirei la soluzione sql-server, perché penso che sia davvero veloce per ottenere risultati, se vuoi lucene devi implementarne di più all'inizio (e anche avere un po 'di know-how).
SQL Server FTS sarà più facile da gestire per una piccola distribuzione. Poiché FTS è integrato con il DB, RDBMS gestisce l'aggiornamento automatico dell'indice. Il problema è che non si dispone di una soluzione di ridimensionamento ovvia per la replica dei DB. Quindi, se non è necessario ridimensionare, SQL Server FTS è probabilmente "più sicuro". Politicamente, la maggior parte dei negozi si sentirà più a suo agio con una pura soluzione SQL Server.
Per quanto riguarda Lucene, preferirei SOLR a Lucene. Con entrambe le soluzioni è necessario fare più lavoro da soli aggiornando l'indice quando i dati cambiano, così come mappare i dati personalmente all'indice SOLR/Lucene. I pro sono che puoi facilmente scalare aggiungendo altri indici. È possibile eseguire questi indici su server Linux molto snelli, il che elimina alcuni costi di licenza. Se si prende la rotta Lucene/SOLR, punterei a mettere TUTTI i dati necessari direttamente nell'indice, piuttosto che riportare i puntatori al DB nell'indice. È possibile includere dati nell'indice che non sono ricercabili, quindi ad esempio si potrebbe avere un HTML o XML precostruito memorizzato nell'indice e servirlo come risultato della ricerca. Con questo approccio il tuo DB potrebbe essere inattivo ma puoi ancora pubblicare i risultati della ricerca in modalità disconnessa.
Non ho mai visto un confronto di prestazioni testa a testa tra SQL Server 2008 e Lucene, ma mi piacerebbe vederne uno.
Una considerazione da tenere a mente è quale tipo di vincoli di ricerca si hanno in aggiunta al vincolo full-text. Se stai facendo dei limiti che Lucene non può fornire, allora quasi sicuramente vorrai usare FTS. Una delle cose positive del 2008 è che hanno migliorato l'integrazione di FTS con query SQL standard del server, quindi le prestazioni dovrebbero essere migliori con vincoli di database e FT misti rispetto al 2005.