Wie mit sehr häufigen updates zu einem Lucene-index
Ich versuche, einen Prototyp für eine Indizierung/Suche-Anwendung, die sehr volatil die Indizierung der Daten-Quellen (Foren, soziale Netzwerke etc.), hier sind einige der performance-Anforderungen,
-
Sehr schnelle turn-around-Zeit (damit meine ich, dass keine neuen Daten (z.B. eine neue Nachricht in einem forum) sollte in den Suchergebnissen sehr schnell (weniger als eine minute))
-
Muss ich das verwerfen von alten Dokumenten auf einer ziemlich regelmäßigen basis, um sicherzustellen, dass die Ergebnisse der Suche sind nicht datiert.
-
Nicht zuletzt die Suche der Anwendung Bedürfnisse zu reagieren. (Latenz in der Größenordnung von 100 Millisekunden, und sollte mindestens 10 qps)
Alle Anforderungen, die ich habe, die derzeit erfüllt werden können w/o using Lucene (und das würde mir genügen alle 1,2 und 3), aber ich bin Antizipation andere Anforderungen in der Zukunft (wie Suche, Relevanz etc.), die Lucene erleichtert die Umsetzung. Jedoch, da Lucene ist konzipiert für den Einsatz Fällen weitaus komplexer ist, als die, die ich gerade auf Arbeit bin, bin ich eine harte Zeit, befriedigend, meine Leistung Anforderungen.
Hier sind einige Fragen,
ein. Ich habe gelesen, dass die optimize () - Methode in der IndexWriter-Klasse ist teuer, und sollte nicht verwendet werden, die von Anwendungen, die häufigen updates, was sind die alternativen?
b. Um inkrementelle updates, die ich brauche zu halten, Begehen die neuen Daten, und halten die Aktualisierung der index-reader, um sicherzustellen, dass es die neuen Daten zur Verfügung. Diese sind auf 1 und 3 oben. Sollte ich versuchen, doppelte Indizes? Was sind einige gemeinsame Ansätze zur Lösung dieses Problems?
c. Ich weiß, dass Lucene bietet eine delete-Methode, die es erlaubt, Sie zu löschen Sie alle Dokumente, die die übereinstimmung eines bestimmten Abfrage, in meinem Fall, ich brauche, um zu löschen Sie alle Dokumente, die älter als ein bestimmtes Alter, jetzt eine option ist das hinzufügen von ein Datum-Feld für jedes Dokument, und verwenden, löschen Sie die Dokumente später. Ist es möglich zu tun range-queries auf Dokumenten-ids (ich kann mein eigenes id-Feld, da ich denke, dass bei lucene hält zu ändern), Dokumente zu löschen? Ist es nicht schneller, als Vergleich von Datumsangaben als Zeichenketten?
Ich weiß, das sind sehr offene Fragen, also ich bin nicht auf der Suche für eine ausführliche Antwort, ich werde versuchen, behandeln Sie alle Ihre Antworten, Anregungen und nutzen Sie, um zu informieren, mein design. Danke! Bitte lassen Sie mich wissen, wenn Sie weitere Informationen benötigen.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Lucene unterstützt jetzt In Der Nähe Von Echtzeit-Suche. Im wesentlichen, erhalten Sie einen Reader von IndexWriter jedes mal, wenn Sie tun, eine Suche. Die in-memory-änderungen gehen nicht auf der Festplatte, bis die RAM-Puffergröße erreicht ist oder eine ausdrückliche
commitgenannt wird, auf die Schriftsteller. Als disk-IO vermieden durch überspringencommit, der sucht schnell zurück, auch mit den neuen Daten.Eines der Probleme mit der Lucene-s NRT ist der Logarithmus die index-merging-Algorithmus. Ein merge ist auslöste nach 10 Dokumente Hinzugefügt werden, um ein segment. Weiter, wie 10 Segmente zusammengeführt werden, um ein segment anzulegen mit 100 Dokumenten und so weiter. Nun, wenn Sie haben 999,999 Dokumente und Seriendruck ausgelöst wird, wird es einige Zeit dauern, um zurückzukehren, brechen Sie Ihr "real-time" Versprechen.
LinkedIn veröffentlicht hat Zoie, eine Bibliothek oben auf Lucene, der dieses Problem behebt. Dies ist eine live in der Produktion Umgang mit Millionen von updates und sucht Alltag.
Meist, Lucene unterstützt alle Ihre Anforderungen, wie Sie sind, verwerfen alte updates und das bewegliche Fenster ist ungefähr konstanter Größe. Falls es nicht funktioniert, müssen Sie möglicherweise versuchen, Zoie, die nachweislich auf dem Schlachtfeld.
Möchten Sie vielleicht zu prüfen, mit Solr eher als straight-up Lucene. Solr bewältigt alle Anforderungen, die Sie erwähnt (near-realtime-updates, löschen von Dokumenten -, performance - /Splitter -, range-queries), und er werde es besser machen als Ihre eigenen hand-gerollt-code. Sie nicht haben, um sich mit Fragen in der IndexReader-Ebene, d.h. beim aktualisieren der IndexReader nach einem update.
Soweit Bereichsabfragen gehen, Solr hat TrieField Fähigkeiten, die macht numerischen Bereich Anfragen super schnell. Sehen http://www.lucidimagination.com/blog/2009/05/13/exploring-lucene-and-solrs-trierange-capabilities/
A: ich denke, mit den neuesten Versionen von Lucene, der optimize-Methode ist nicht wirklich nötig und mit meinen Vorschlag für Element C, es sollte wirklich nicht nötig sein.
B: noch einmal: ich denke, mit der neuesten version von Lucene, die Forscher sind sich bewusst, wenn die updates fertig sind und damit umgehen kann, ohne Sie zu brauchen, etwas besonderes zu tun.
C: ich möchte vermeiden, löschen und erstellen Sie einen neuen index täglich. Wenn Sie speichern Sie das Alter des Dokuments in den index, dann können Sie den vorhandenen index zu erstellen, der neue. Während Ihres index schreiben Holen sich alle Jungen Dokumente, durch Sie gehen, und fügen Sie Sie zu Ihrer neuen index. Eine öffentliche util-Methode genannt getCurrentIndex, die verwendet wird, von den searchers zu greifen, die neuesten live-index. Halten Sie 1 oder 2 alte Indizes rund um den Fall der Fälle und Sie sollten gut zu gehen.
Können Sie cache-index-searcher für eine kurze Zeit, und öffnen Sie es erneut. Wir verwenden für diesen Zweck asp.net WebCache-die CacheItemUpdateCallback, die aufgerufen wird, direkt vor chached Element abläuft.