In der Entwicklung unserer Apache Lucene basierenten Suchmaschine SEBOL konzeptionierten wir eine komplexe Warteschlange für den Index-Server, da zu Peek-Zeiten nicht alles „on the fly“ indiziert werden kann und sich die Verteilung auf mehrerer Server mittels einer Queue einfacher gestaltet. Zusätzlich sind wir in der Lage über eine Priorisierung Indizieranfragen „dazwischen“ zu schieben.

Aufgrund der anzunehmenden Größe der Indizes war die Backup-Fähigkeit immer ein großes Thema. Die Sicherung eines Suchindex macht dann Sinn, wenn die Wiederherstellungszeit länger als die erlaubte Down-Zeit ist. Die Datensicherung eines Lucene-Index ist unproblematisch, denn Lucene selbst speichert (viele) Dateien in ein Verzeichnis und damit ist die Sache erst einmal erledigt. In SEBOL nutzen wir zusätzlich eine dateibasierte JDerby Datenbank, die beim Backup synchron gehalten werden muss. Dies erreichen wir in dem zum Sicherungstermin die Indizierung kurzzeitig angehalten wird. Währendessen füllt sich die Queue mit den Index-Anfragen, die nach dem Backup abgearbeitet werden.

[caption id=”attachment_725” align=”aligncenter” width=”576”] Grobe Skizze der Queue für den SEBOL Index Server Grobe Skizze der Queue für den SEBOL Index Server[/caption]

Zum eigentlichen Thema des Journals. Wenn ein Unternehmen einen Suchindex nachts sichert und der K-Fall erst Stunden später eintritt, so existiert eine Differenz zwischen der Sicherung und dem tatsächlichen Index. Also muss man sich zwei Sachen merken, um einen möglichst zeitnahen Aufsetzpunkt zu finden.

Erstens muss man alle seit der Sicherung abgearbeiteten Request als erledigt in einem persistenten Journal ablegen.

Zweitens muss die Queue der nicht abgearbeiteten Anfragen ebenfalls persistent sein. Das Handshake für den Indizier-Client darf erst nach Speicherung in der Warteschlange erfolgen.

Ist dieses durchgängige Journaling implementiert, kann man im K-Fall das Backup zurückspielen (Restore), den SEBOL Index Server neu starten und über die Parameter den Aufsetzpunkt mitteilen. Das Queue-Management füllt die Warteschlange in der richtigen Reihenfolge mit allen Anfragen seit dem letzten Backup. Somit ist auch im K-Fall der ursprünglich gesicherte Index annähernd sofort wieder aktiv. Je nach Mengengerüst ist die Warteschlange nach einiger Zeit abgearbeitet und der Lucene Index ist auf dem aktuellen Stand.

Weitere Informationen zur Suchtechnologie

Die Skizze wurde mit Gliffy erstellt, das ist unser webbasierter Diagrammeditor im Enterprise Wiki