Configurer Lucene.Net avec SQL Server

Oui, je l'ai utilisé exactement pour ce que vous décrivez. Nous avions deux services – un pour la lecture et un pour l'écriture, mais seulement parce que nous avions plusieurs lecteurs. Je suis sûr que nous aurions pu le faire avec un seul service (l'écrivain) et embedded le lecteur dans l'application Web et les services.

J'ai utilisé lucene.net comme indexeur de database général, donc ce que j'ai récupéré était essentiellement un identifiant de database (pour les messages électroniques indexés), et je l'utilise également pour récupérer suffisamment d'informations pour remplir les résultats de search sans toucher le database. Cela fonctionne très bien dans les deux cas, le SQL peut être un peu lent, car vous devez get un identifiant, sélectionner un identifiant, etc. Nous avons contourné cela en créant une table temporaire (avec juste la ligne ID) et insertion en masse à partir d'un file (qui était la sortie de lucene) puis se joindre à la table des messages. Était beaucoup plus rapide.

Lucene n'est pas parfaite, et vous devez penser un peu en dehors de la boîte de database relationnelle, parce que TOTALEMENT n'en est pas un, mais c'est très très bon à ce qu'il fait. Ça vaut le coup d'oeil, et, m'a-t-on dit, il n'y a pas le "oups, désolé, vous avez besoin de rebuild votre index à nouveau" des problèmes que FTI de MS SQL fait.

BTW, nous avons eu affaire à 20-50 millions de courriels (et environ 1 million de pièces jointes uniques), totalisant environ 20 Go d'index lucene je pense, et 250 + Go de database SQL + pièces jointes.

Les performances ont été fantastiques, c'est le less que l'on puisse dire: assurez-vous de penser et de modifier vos facteurs de fusion (lorsque vous fusionnez des segments d'index). Il n'y a aucun problème à avoir plus d'un segment, mais il peut y avoir un gros problème si vous essayez de merge deux segments qui ont 1mil d'éléments dans chacun, et vous avez un thread observateur qui tue le process si cela prend trop de time … .. (oui, ça nous a donné un coup de pied pendant un moment). Alors gardez le nombre maximum de documents par thinggie LOW (c'est-à-dire, ne le mettez pas à maxint comme nous l'avons fait!)

EDIT Corey Trager a documenté comment utiliser Lucene.NET dans BugTracker.NET ici .

Je ne l'ai pas encore fait contre la database, votre question est un peu ouverte.

Si vous voulez searchr une database, et que vous pouvez choisir d'utiliser Lucene, je suppose également que vous pouvez contrôler quand datatables sont insérées dans la database. Si c'est le cas, il y a peu de raison d'interroger la database pour savoir si vous avez besoin de réindexer, d'indexer comme vous insérez ou de créer une table de queue qui peut être utilisée pour indiquer à indexer.

Je pense que nous n'avons pas besoin d'un autre indexeur qui ignore ce qu'il fait, et qui se réindexe à chaque fois, ou qui utilise des ressources inutiles.

J'ai aussi utilisé lucene.net comme moteur de stockage, car il est plus facile de dissortingbuer et de configurer des machines alternatives avec un index qu'une database, une copy de système de files, un index sur une machine et de copyr les nouveaux files sur les autres machines pour dissortingbuer l'index. Toutes les searchs et les détails sont affichés à partir de l'index lucene, et la database est simplement utilisée pour l'édition. Cette configuration a été prouvée comme une solution très évolutive pour nos besoins.

En ce qui concerne les différences entre sql server et lucene, le principal problème avec sql server 2005 search plein text est que le service est découplé du moteur relationnel, donc joint, ordonne, agrège et filter entre les résultats en text intégral et les colonnes relationnelles sont très chers en termes de performances, Microsoft affirme que ces problèmes ont été résolus dans SQL Server 2008, en intégrant la search de text intégral dans le moteur relationnel, mais je ne l'ai pas testé. Ils ont également rendu l'set de la search en text intégral beaucoup plus transparente, dans les versions précédentes les mots, mots vides et plusieurs autres parties de l'indexing étaient comme une boîte noire et difficiles à comprendre, et dans la nouvelle version sont plus faciles à voir.

Avec mon expérience, si le server sql répond à vos exigences, ce sera le moyen le plus simple, si vous attendez beaucoup de croissance, des requêtes complexes ou besoin d'un grand contrôle de la search plein text, vous pourriez envisager de travailler avec lucene dès le début sera plus facile à mettre à l'échelle et à personnaliser.

J'ai utilisé Lucene.NET avec MySQL. Mon approche était de stocker la key primaire de l'logging db dans le document Lucene avec le text indexé. En pseudo-code, cela ressemble à:

• Enregistrement du magasin:

  insert du text, d'autres données dans la table
  get le dernier identifiant inséré
  créer un document lucene
  mettre (ID, text) dans la mise à jour du document lucene index lucene

• Interroger
  searchr index lucene
  pour chaque document Lucene dans l'set de résultats, chargez datatables de la database par l'ID de l'logging stocké

Juste pour noter, je suis passé de Lucene à Sphinx en raison de sa superbe performance

Je pense que cet article est un bon sharepoint départ:

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