Echtzeit-Suche mit Lucene
Echtzeitsuche ist ein etwas unscharfes Konzept, aber im Grunde bedeutet es, dass die Zeit, die eine Änderung an einem Index braucht, um von den Benutzern gesehen zu werden, auf eine nahezu vernachlässigbare Größe reduziert wird – oder auf eine Zeitdifferenz, die klein genug ist, um für eine bestimmte Echtzeitanwendung akzeptabel zu sein. Nicht alle Anwendungen benötigen eine Echtzeitsuche, aber die Art von Anwendung, die sie benötigt, ist heutzutage sehr beliebt – soziale Netzwerke. Die durchschnittliche Social-Networking-Site möchte, dass die Änderungen der Benutzer fast sofort durchsuchbar sind. Wenn es um Lucene geht, mussten Sie für diese Art von Anwendungen, die schnell aktualisiert werden sollen, einige Hürden überwinden und mehr als nur ein paar Kompromisse eingehen. Die Zukunft sieht jedoch etwas rosiger aus.
Die längerfristige Hoffnung für eine Echtzeitsuche in Lucene bestand darin, einen IndexReader zu entwickeln, der den nicht geleerten Status des IndexWriters im RAM lesen kann. Das ist allerdings leichter gesagt als getan. Derzeit wird ein etwas anderer Ansatz verfolgt – sobald Lucene 2.9 verfügbar ist, werden Sie in der Lage sein, einen IndexReader von einem aktiven IndexWriter anzufordern. Einer derjenigen, die daran arbeiten (Lucene-Guru Mike McCandless), nennt dies eine „echtzeitnahe“ Suche. Kurz gesagt funktioniert das so (Anmerkung: Ich arbeite nicht an diesem Thema und kenne es nicht im Detail – ich verfolge es nur):
Wenn Sie den IndexReader vom IndexWriter anfordern, wird der IndexWriter geflusht (die im RAM angesammelten Dokumente werden auf die Festplatte geschrieben), aber nicht committed (fsync-Dateien, neue Segmente in die Datei schreiben, usw.). Der zurückgegebene IndexReader durchsucht sowohl die zuvor übertragenen Segmente als auch das neue, geleerte, aber nicht übertragene Segment. Da das Flushen wahrscheinlich eher an den Prozessor als an die IO gebunden ist, sollte dies ein Prozess sein, der mit mehr Prozessorleistung angegriffen werden kann, wenn er sich als zu langsam erweist. Außerdem werden Löschvorgänge im RAM gespeichert und nicht auf die Festplatte übertragen, was zu einer weiteren Geschwindigkeitssteigerung führen kann. Das Ergebnis ist, dass Sie Dokumente nahezu in Echtzeit zu einem Lucene-Index hinzufügen und aus ihm entfernen können, indem Sie alle paar Sekunden einen neuen Reader vom IndexWriter anfordern. Ich habe noch keinen nicht-synthetischen Test gesehen, aber es sieht so aus, als ob es bei etwa 50 Dokumentenaktualisierungen pro Sekunde ohne starke Verlangsamung getestet wurde (z.B. sind die Ergebnisse jede Sekunde sichtbar). Der Patch macht sich LUCENE-1483 zunutze, der FieldCaches und Filter auf der Ebene einzelner Segmente und nicht auf Indexebene schlüsselt. Dadurch können Sie Caches nur pro Segment und nicht pro Index neu laden, was für die Echtzeitsuche mit Filter/Cache-Nutzung unerlässlich ist.
Ich kann es kaum erwarten, dass diese Arbeit in Solr Einzug hält.