Ich versuche, eine Indexierungs- / Suchanwendung zu erstellen, die sehr volatile Indexierungsdatenquellen (Foren, soziale Netzwerke usw.) verwendet, hier sind einige der Leistungsanforderungen,
Sehr schnelle Bearbeitungszeit (damit meine ich, dass neue Daten (wie eine neue Nachricht in einem Forum) sehr bald in den Suchergebnissen verfügbar sein sollten (weniger als eine Minute))
Ich muss alte Dokumente ziemlich regelmäßig verwerfen, um sicherzustellen, dass die Suchergebnisse nicht veraltet sind.
Zu guter Letzt muss die Suchanwendung reaktionsfähig sein. (Latenz in der Größenordnung von 100 Millisekunden und sollte mindestens 10 qps unterstützen)
Alle Anforderungen, die ich derzeit habe, können ohne Lucene erfüllt werden (und das würde mich alle 1,2 und 3 zufrieden stellen), aber ich erwarte andere Anforderungen in der Zukunft (wie Suchrelevanz etc), die Lucene erleichtert die Implementierung. Da Lucene jedoch für Anwendungsfälle konzipiert ist, die weitaus komplexer sind als die, an denen ich gerade arbeite, fällt es mir schwer, meine Leistungsanforderungen zu erfüllen.
Hier sind einige Fragen,
a. Ich habe gelesen, dass die optimize () - Methode in der IndexWriter-Klasse teuer ist und nicht von Anwendungen verwendet werden sollte, die häufige Aktualisierungen durchführen. Welche Alternativen gibt es?
b. Um inkrementelle Updates durchführen zu können, muss ich weiterhin neue Daten bereitstellen und den Index-Reader aktualisieren, um sicherzustellen, dass die neuen Daten verfügbar sind. Diese wirken sich auf 1 und 3 oben aus. Soll ich doppelte Indizes versuchen? Was sind einige gängige Ansätze zur Lösung dieses Problems?
c. Ich weiß, dass Lucene eine Löschmethode bietet, mit der Sie alle Dokumente löschen können, die einer bestimmten Abfrage entsprechen. In meinem Fall muss ich alle Dokumente löschen, die älter als ein bestimmtes Alter sind. Jetzt können Sie jedem Benutzer ein Datumsfeld hinzufügen dokumentieren und verwenden, um Dokumente später zu löschen. Ist es möglich, Bereichsabfragen für Dokument-IDs durchzuführen (ich kann ein eigenes ID-Feld erstellen, da ich glaube, dass das von Lucene erstellte Dokument ständig geändert wird), um Dokumente zu löschen? Ist es schneller als Daten, die als Strings dargestellt werden?
Ich weiß, dass dies sehr offene Fragen sind, daher suche ich nicht nach einer detaillierten Antwort. Ich werde versuchen, alle deine Antworten als Vorschläge zu behandeln und sie dazu zu benutzen, mein Design zu informieren. Vielen Dank! Bitte lassen Sie mich wissen, wenn Sie weitere Informationen benötigen.
Lucene unterstützt jetzt Near Real Time Search . Im Prinzip erhalten Sie bei jeder Suche einen Reader von IndexWriter. Die speicherinternen Änderungen werden erst dann auf den Datenträger übertragen, wenn die RAM-Puffergröße erreicht ist oder ein explizites commit für den Writer aufgerufen wird. Da Disk-IO vermieden wird, indem commit übersprungen wird, kehren die Suchvorgänge auch mit den neuen Daten schnell zurück.
Einer der Probleme mit der NRT von Lucene ist der Index-Logarithmus-Merging-Algorithmus. Eine Zusammenführung wird ausgelöst, nachdem 10 Dokumente zu einem Segment hinzugefügt wurden. Als Nächstes werden diese 10 Segmente zusammengeführt, um ein Segment mit 100 Dokumenten usw. zu erstellen. Jetzt, wenn Sie 999.999 Dokumente haben und eine Zusammenführung ausgelöst wird, wird es einige Zeit dauern, bis Sie zurückkehren, was Ihre "Echtzeit" -Versprechung unterbricht.
LinkedIn hat Zoie , eine Bibliothek über Lucene, die dieses Problem anspricht, veröffentlicht. Dies ist live in der Produktion und verarbeitet täglich Millionen von Updates und Suchen.
Meistens unterstützt Lucene alle Ihre Anforderungen, da Sie alte Updates verwerfen und das sich bewegende Fenster ungefähr von konstanter Größe ist. Falls nicht, musst du Zoie ausprobieren, was sich im Kampf bewährt hat.
Vielleicht solltest du lieber Solr anstelle von straight-up Lucene verwenden. Solr behandelt alle von Ihnen erwähnten Anforderungen (Fast-Echtzeit-Updates, Löschen von Dokumenten, Performance / Sharding, Bereichsabfragen) und ist besser als Ihr eigener handgenerierter Code. Sie müssen sich nicht mit Problemen auf der IndexReader-Ebene befassen, d. H. Wann Sie den IndexReader nach einer Aktualisierung aktualisieren müssen.
So weit wie Bereichsabfragen gehen, hat Solr TrieField-Fähigkeiten, die numerische Bereichsabfragen super schnell macht. Siehe Ссылка
A: Ich denke, mit den neuesten Versionen von Lucene wird die Optimierungsmethode nicht wirklich benötigt, und mit meinem Vorschlag für Punkt C sollte es wirklich nicht benötigt werden.
B: Ich denke, mit der neuesten Version von Lucene sind die Suchenden darüber informiert, wann Aktualisierungen durchgeführt werden und können damit umgehen, ohne dass Sie etwas Besonderes tun müssen.
C: Ich würde das Löschen vermeiden und einfach jeden Tag einen neuen Index erstellen. Wenn Sie das Alter des Dokuments im Index speichern, können Sie den vorhandenen Index verwenden, um den neuen zu erstellen. Während deines Indexschreibens holst du alle jungen Dokumente, gehst sie durch und fügst sie deinem neuen Index hinzu. Verwenden Sie eine öffentliche util-Methode namens getCurrentIndex, die von den Suchern verwendet wird, um den neuesten Live-Index abzurufen. Bewahre 1 oder 2 alte Indizes auf, nur für den Fall, und du solltest gut gehen.
Sie können Ihren Index-Sucher für kurze Zeit zwischenspeichern und wieder öffnen. Wir verwenden zu diesem Zweck asp.net WebCache, der CacheItemUpdateCallback hat, der kurz vor dem Ablauf des Chached-Elements aufgerufen wird.
Tags und Links performance indexing lucene