Frage

Hat jemand Lucene.NET verwendet, anstatt die Volltextsuche zu verwenden, die mit SQL Server geliefert wird?

Wenn ja, würde mich interessieren, wie Sie es umgesetzt haben.

Haben Sie beispielsweise einen Windows-Dienst geschrieben, der die Datenbank stündlich abfragt und die Ergebnisse dann im lucene.net-Index speichert?

War es hilfreich?

Lösung

Ja, ich habe es genau für das verwendet, was Sie beschreiben.Wir hatten zwei Dienste – einen zum Lesen und einen zum Schreiben, aber nur, weil wir mehrere Leser hatten.Ich bin sicher, wir hätten es mit nur einem Dienst (dem Autor) schaffen und den Leser in die Web-App und die Dienste einbetten können.

Ich habe lucene.net als allgemeinen Datenbankindexer verwendet, also habe ich im Wesentlichen DB-IDs (für indizierte E-Mail-Nachrichten) zurückbekommen, und ich habe es auch verwendet, um genug Informationen zurückzubekommen, um Suchergebnisse oder ähnliches zu füllen, ohne die zu berühren Datenbank.Es hat in beiden Fällen großartig funktioniert, allerdings kann die SQL etwas langsam werden, da man praktisch eine ID besorgen, eine ID auswählen usw. muss.Wir haben dies umgangen, indem wir eine temporäre Tabelle erstellt haben (nur mit der ID-Zeile darin) und diese in großen Mengen aus einer Datei (die die Ausgabe von Lucene war) eingefügt und dann mit der Nachrichtentabelle verknüpft haben.War viel schneller.

Lucene ist nicht perfekt, und Sie müssen ein wenig über den Tellerrand einer relationalen Datenbank hinausdenken, denn es ist NICHT VOLLSTÄNDIG keine perfekte Datenbank, aber es ist sehr, sehr gut darin, was es kann.Es ist einen Blick wert und hat, wie mir gesagt wurde, nicht die „Ups, tut mir leid, Sie müssen Ihren Index noch einmal neu erstellen“-Probleme, die FTI von MS SQL verursacht.

Übrigens hatten wir es mit 20–50 Millionen E-Mails (und etwa 1 Million eindeutigen Anhängen) zu tun, was meiner Meinung nach insgesamt etwa 20 GB Lucene-Index und mehr als 250 GB SQL-Datenbank + Anhänge umfasste.

Die Leistung war, gelinde gesagt, fantastisch – denken Sie einfach über Ihre Zusammenführungsfaktoren nach und optimieren Sie sie (wenn Indexsegmente zusammengeführt werden).Es ist kein Problem, mehr als ein Segment zu haben, aber es kann ein GROSSES Problem sein, wenn Sie versuchen, zwei Segmente zusammenzuführen, die jeweils 1 Million Elemente enthalten, und Sie einen Watcher-Thread haben, der den Prozess abbricht, wenn er zu lange dauert ... ..(Ja, das hat uns eine Zeit lang in den Arsch getreten).Halten Sie also die maximale Anzahl an Dokumenten pro Ding NIEDRIG (d. h. setzen Sie sie nicht auf „maxint“, wie wir es getan haben!)

BEARBEITEN Corey Trager hat dokumentiert, wie Lucene.NET in BugTracker.NET verwendet wird Hier.

Andere Tipps

Ich habe es noch nicht mit der Datenbank gemacht, Ihre Frage ist irgendwie offen.

Wenn Sie eine Datenbank durchsuchen möchten und Lucene verwenden können, können Sie meiner Meinung nach auch steuern, wann Daten in die Datenbank eingefügt werden.Wenn ja, gibt es kaum einen Grund, die Datenbank abzufragen, um herauszufinden, ob eine Neuindizierung erforderlich ist. Indizieren Sie einfach beim Einfügen oder erstellen Sie eine Warteschlangentabelle, die verwendet werden kann, um Lucene mitzuteilen, was indiziert werden soll.

Ich denke, wir brauchen keinen weiteren Indexer, der nicht weiß, was er tut, und jedes Mal neu indiziert oder Ressourcen verschwenderisch verwendet.

Ich habe lucene.net auch als Speicher-Engine verwendet, da es einfacher ist, alternative Maschinen mit einem Index zu verteilen und einzurichten als mit einer Datenbank. Es handelt sich lediglich um eine Kopie des Dateisystems. Sie können auf einer Maschine indizieren und die neuen Dateien einfach auf die anderen Maschinen kopieren um den Index zu verteilen.Alle Suchanfragen und Details werden aus dem Lucene-Index angezeigt und die Datenbank wird nur zur Bearbeitung verwendet.Dieses Setup hat sich als sehr skalierbare Lösung für unsere Anforderungen erwiesen.

Was die Unterschiede zwischen SQL Server und Lucene betrifft, besteht das Hauptproblem bei der Volltextsuche von SQL Server 2005 darin, dass der Dienst von der relationalen Engine entkoppelt ist, sodass Verknüpfungen, Reihenfolgen, Aggregationen und Filter zwischen den Volltextergebnissen und den relationalen Spalten sehr teuer sind In Bezug auf die Leistung behauptet Microsoft, dass diese Probleme in SQL Server 2008 behoben wurden, indem die Volltextsuche in die relationale Engine integriert wurde, ich habe sie jedoch nicht getestet.Sie haben auch die gesamte Volltextsuche viel transparenter gemacht. In früheren Versionen waren die Stammwörter, Stoppwörter und mehrere andere Teile der Indexierung wie eine Blackbox und schwer zu verstehen, und in der neuen Version ist ihre Funktionsweise einfacher zu erkennen.

Wenn SQL Server Ihren Anforderungen entspricht, ist dies meiner Erfahrung nach der einfachste Weg. Wenn Sie viel Wachstum oder komplexe Abfragen erwarten oder eine umfassende Kontrolle über die Volltextsuche benötigen, sollten Sie die Arbeit mit Lucene von Anfang an in Betracht ziehen, da dies der Fall ist wird einfacher zu skalieren und zu personalisieren sein.

Ich habe Lucene.NET zusammen mit MySQL verwendet.Mein Ansatz bestand darin, den Primärschlüssel des Datenbankeintrags zusammen mit dem indizierten Text im Lucene-Dokument zu speichern.Im Pseudocode sieht es so aus:

  • Eintrag speichern:

    Fügen Sie Text und andere Daten in die Tabelle ein
    Holen Sie sich die zuletzt eingegebene ID
    Erstellen Sie ein Lucene-Dokument
    Put (ID, Text) in Lucene Dokument aktualisieren Lucene Index

  • Abfragen
    Lucene-Index durchsuchen
    Laden Sie für jedes Lucene-Dokument im Ergebnissatz Daten aus der Datenbank anhand der ID des gespeicherten Datensatzes

Nur zur Anmerkung: Ich bin von Lucene auf umgestiegen Sphinx aufgrund seiner hervorragenden Leistung

Ich denke, dieser Artikel ist ein guter Ausgangspunkt:

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

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top