Umstellung Hibernate Search − weitere Fragen #6095
Replies: 7 comments 12 replies
-
|
Vielen Dank für diesen Überblick über den aktuellen Entwicklungsstand.
Wenn ich die Arbeitsschritte in Issue #5760 richtig verstehe, wird es in jedem Fall eine Suche nach den Metadaten der meta.xml im Index geben. Die Tatsache, dass die zwei Funktionalitäten nicht zur Verfügung stehen, ist also auch dadurch bedingt, dass die Metadatensuche noch nicht implementiert ist, richtig? Grundsätzlich halte ich es für recht hilfreich die Werte in der Datenbank zu speichern; wir haben im Fall der PPN bei der Erarbeitung der Spezifikation für den Re-Import bereits darüber nachgedacht (#5904), dies aber erstmal verworfen, da Altdaten entsprechend migriert werden müssten. Daher stellt sich die Frage: Macht eine Umstellung dieser Werte vom Index auf die Datenbank nicht eine Migration der Altdaten nötig? Wären für letztere - bzw. für die Bereitstellung eines Migrations-Werkzeugs - weitere Entwicklungsarbeit nötig? |
Beta Was this translation helpful? Give feedback.
-
|
Nein, es ist eben nicht zwingend, dass die Werte in der Datenbank gespeichert werden, deswegen möchte ich auch zuerst fragen, bevor ich das einfach verändere. Aber, es würde ermöglichen, dass die gesamte Anwendung selbst dann genutzt werden kann, wenn der Suchindex gerade nicht zur Verfügung steht. Das ist im Dienstleistungsbetrieb ein echtes Problem, wenn der Server ganz ausfällt, weil der Index gestört ist und dann mehrere Mitarbeiter nicht mehr ihre reguläre Arbeit machen können, bis der Indexaufbau (der ggf. ein paar Stunden dauert, je nach Umfang der Daten) abgeschlossen ist. Ja, die Altdaten müssten migriert werden, das heißt, ein Hintergrundtask müsste einmal für alle Vorgänge in die Mets-Datei gucken, die Informationen auslesen und in die Datenbank speichern. Das muss dann nur angeklickt werden und passiert dann automatisch. Die hier erwähnten Funktionen würden erst dann wieder funktionieren, wenn das durchgelaufen ist, ansonsten kann die Funktion aber im laufenden Betrieb erfolgen und verursacht so wie ich das sehe keine Verzögerung unmittelbar beim Update. Das „Migrationswerkzeug“ ist ein Thread von vielleicht 10 Zeilen und schnell erstellt. |
Beta Was this translation helpful? Give feedback.
-
|
Man kann solche Daten redundant in der Datenbank und dem Suchindex vorhalten, so dass man grundlegende Suchmechaniken (wer bestimmt diese? und wie verhält sich die Anwendung, wenn die Suchen mit komplexeren Anfragen so nicht durchführbar sind?) auch dann hat, wenn der Suchindex nicht zu Verfügung steht. Jedoch müssen diese Daten dann absolut synchron gehalten werden. |
Beta Was this translation helpful? Give feedback.
-
|
Mit Hibernate Search werden − wenn ich es richtig verstanden habe − keine Daten mehr im Suchindex vorgehalten oder daraus gelesen. Der Index dient lediglich dazu, bestimmte Suchanfragen (auch an Felder, die es in der Datenbank nicht gibt, das ist wohl weiterhin möglich) zu ermöglichen bzw. deutlich performanter zu ermöglichen. Antwort des Index ist aber dann unter der Haube immer die ID, und das Objekt wird dann aus der Datenbank geholt, und das alles macht das Framework, davon bekommen wir weiter gar nichts mehr mit. Ist ja auch wichtig, damit das Objekt aktuell ist. Wenn die Anwendung selbst die Daten braucht, z.B. um zu entscheiden, ob der Papierkorb-Button ausgegraut werden soll, muss sie sich die klassisch aus der Datenbank holen. Die „Migration“ würde bedeuten, dass die zusätzlichen Felder, etwa “docType”, “recordIdentifier”, gefüllt werden müssen. Ich würde das dann zwar so implementieren, dass es unter der System−Migration-Seite einen Button dafür gibt, der das im laufenden Tomcat macht, aber rein technisch könnte man auch von außen mit z.B. mit einem Perl-Skript aus allen Mets-Dateien diese Infos raus greppen und in eine SQL-Datei schreiben, die man dann beim Update nur noch einspielen muss. |
Beta Was this translation helpful? Give feedback.
-
Wenn Felder als "projectable" annotiert sind, sollten sie im Index gespeichert und - falls angefordert - Teil der Antwort sein. |
Beta Was this translation helpful? Give feedback.
-
Nur um dies als Option in den Raum zu stellen: Falls sich Kitodo (und insbesondere eine datenbankgestützte Lösung) dadurch deutlich beschleunigen ließe, wäre evtl. zu diskutieren, ob der hohe Aufwand für die Ermittlung des Icon-Status überhaupt betrieben werden muss. Beispiel: Das Icon "Papierkorb" könnte auch immer aktiv geschaltet werden. Die Überprüfung, ob der Vorgang gelöscht werden kann, würde erst erfolgen, wenn ein Nutzer auf das Icon klickt. |
Beta Was this translation helpful? Give feedback.
-
|
Ja das wäre noch eine weitere Variante, die Bedingungen erst beim Anklicken des Icons abzuprüfen. |
Beta Was this translation helpful? Give feedback.
-
|
Ich habe das Thema mit @matthias-ronge besprochen.
Weiteres Vorgehen: @solth: Falls es Gründe gibt, die gegen dieses Vorgehen spricht, darfst/sollst Du natürlich hier gerne Dein "Veto" anmelden. |
Beta Was this translation helpful? Give feedback.
-
|
Vielleicht bin ich jetzt etwas pragmatisch unterwegs, aber ich würde gerne im CB die verschiedenen use cases mal kurz sammeln, um zu gucken, welche Bedarfe es überhaupt gibt. Danach können wir ja gucken was sich technisch wie umsetzen lässt. Wenn man schon alles neu baut und guckt wäre das eine gute Gelegenheit mal zu gucken was man tatsächlich braucht. Ich kann z. B. aus Halle berichten, dass ich wahrscheinlich durch die Erziehung mit Kitodo 2 im wesentlichen nach dem Prozessnamen suche und erst anfange die Vorteile des Indexes zu erkennen, aber da definitiv nicht alle Metadaten drin brauche. Ich vermute mal in den anderen größeren Häusern gibt es ähnliche Standardfälle und bevor wir gucken was technisch wie optimal umgesetzt werden kann, können wir ja mal gucken was tatsächlich mit welcher Prio nötig ist, bevor es Verschiebungen zw. Index und Datenbank gibt. |
Beta Was this translation helpful? Give feedback.
-
|
Von mir aus gerne auch Klärung im CB. |
Beta Was this translation helpful? Give feedback.
-
|
@matthias-ronge danke für das Update zum aktuellen Bearbeitungsstand des Projekts. Gut zu hören/lesen, dass es prinzipiell zu funktionieren scheint. Ein paar Anmerkungen von mir zu den von Dir erwähnten Punkten: zu 1.: ich wäre dafür, die Informationen, die benötigt werden, um bestimmte Icons zu deaktivieren, in der Datenbank abzuspeichern, wenn wir nur so die aktuelle Funktionalität behalten können, selbst, wenn es nicht so schön ist. Funktionalität muss meiner Meinung nach über "Schönheit" der Implementierung stehen. zu 2.: ich wäre dafür, nicht fest immer "PPN" als Spalte zur Vorgangs-Tabelle hinzuzufügen, sondern stattdessen explizit solche funktionalen Metadaten, die im Regelsatz mit zu 3.: gab es hier nicht eine Möglichkeit, solche Informationen einer Entität mit Hilfe der zu 4.: auf die Funktionalität gänzlich zu verzichten ist aus meiner Sicht keine Option, besonders, da Du ja schon zwei potentielle Lösungsvorschläge aufgezählt hast. Vielleicht können wir hier ähnlich verfahren wie mit dem zu 5.: ich glaube, dass es sehr wichtig ist, dass die Funktionalität des Filter-Schlitzes erhalten bleibt, daher bin ich dankbar, dass Du das explizit erwähnst. Das sollten wir nicht aus den Augen verlieren. |
Beta Was this translation helpful? Give feedback.
-
|
Führt die Einführung der Speicherung von funktionalen Metadaten (RecordIdentifier, DocType, ...) in einer Kreuztabelle nicht dazu, was schon einmal existierte und abgeschafft werden sollte, nämlich der Eigenschaften-Tabelle (früher Vorgangs-, Vorlangen- und Werkstückseigenschaften), nur neu benannt? Wie werden diese Daten aktuell / korrekt vorgehalten, wenn es zu Änderungen über den Metadateneditor an den funktionalen Metadaten kommt? Wie soll auch mit funktionalen Metadaten umgegangen werden, die später hinzu kommen (bspw. durch neue Features oder der Definition im Regelsatz) oder später entfernt werden? Wie werden diese nachträglich von bestehenden Daten hinzugefügt oder entfernt? |
Beta Was this translation helpful? Give feedback.
-
|
Wir (@solth , @matthias-ronge , @stefanCCS ) hatten noch ein weiteres Abstimmungsmeeting mit folgendem Ergebnis zu den oben genannten Punkten:
==> Dass heißt: Es gibt aus Anwendersicht keine Änderung zur bisherigen Version: Somit die Frage an @apiller , @BartChris: Brauchen wir noch das Meeting mit dem CB? |
Beta Was this translation helpful? Give feedback.
-
|
@stefanCCS Vielen Dank für die Info! Nur um nochmal nachzufragen: Bedeutet das jetzt, dass es einen optionalen Betriebsmodus ohne Index (wie oben angedeutet) nicht geben wird? Die Suche nach der PPN der Überordnung ist ein ziemlich zentrales Feature und wenn letztere nur mit Index funktioniert, muss der Index vermutlich immer laufen, richtig? Oder wird weiterhin an einen reinen Datenbank-Modus gedacht in dem bestimmte Features nicht zur Verfügung stehen? Abgesehen davon: Damit die Entwicklung vorangeht, kann die technische Umsetzung jetzt erstmal angegangen werden. Sobald eine lauffähige Version mit den angesprochenen Punkten steht, sollte es aber ein Meeting zur Umsetzung der Suche in den Metadaten auf Basis von Hibernate Search geben, um die Bedarfe zu klären. Sobald sich die obige Entwicklung dem Abschluss nähert und @matthias-ronge zeitliche Kapazitäten hat, kann ein Termin fixiert werden. |
Beta Was this translation helpful? Give feedback.
-
Nur als Idee: Wenn wir den Index ohnehin benötigen (s.o), und die Datenbank-gestützte Variante kompliziert umzusetzen ist: warum nicht diese Informationen in Elasticsearch/Opensearch ablegen und die Listen mit allen Informationen aus dem Index konstruieren. https://docs.jboss.org/hibernate/search/7.1/reference/en-US/html_single/#projections |
Beta Was this translation helpful? Give feedback.
-
|
Zusätzlich zu den von @BartChris erwähnten HibernateSearch "Projections" möchte ich auch nochmal die bei HibernateSearch verfügbaren Annotationen zum Speichern von Eigenschaften einer Entität in den Index-Objekten einer anderen Entität hinweisen:
Diese Annotationen könnten es ermöglichen, einige der von @matthias-ronge angesprochenen Herausforderungen anzugehen, ohne eigene Hilfsklassen als Erweiterung der Datenbank-Beans für Vorgänge und Projekte erzeugen zu müssen. Wichtig ist mir hierbei, das Rad nicht neu zu erfinden, sondern zunächst zu versuchen, die durch HibernateSearch bereitgestellten Funktionalitäten zu sondieren und zu nutzen, bevor eigene, kompliziertere und langfristig evtl. schwieriger wartbare Eigenentwicklungen vorgenommen werden. Ein erster, nicht fertiger Ansatz, HibernateSearch in Kitodo.Production einzubinden, kann unter hibernate-search...effective-webwork:kitodo-production:hibernate-search gefunden werden, bei dem die Verwendung der oben erwähnten Annotationen z.B. in der Klasse |
Beta Was this translation helpful? Give feedback.
-
Es wird im Rahmen der Umsetzung von der Hibernateserach-Beauftragung weiterhin immer nötig sein, einen Index laufen zu haben. |
Beta Was this translation helpful? Give feedback.
-
|
Ohne den neuesten Stand des Branch explizit getestet zu haben (https://github.com/matthias-ronge/kitodo-production/tree/5760_1c_3), einmal die Nachfrage nach dem funktionalen Stand und der konkreten Zielstellung der Implementierung. Dies insbesondere auch im Hinblick darauf, dass es in den Anwenderbibliotheken spezifische Hauptnutzungsszenarien für die Suche gibt, die auf dem aktuellen Stand getestet werden sollten. Wenn ich den Code richtig verstehe, wurde eine große Zahl von Anfragen (Tasks, Projekte) vom Index auf Datenbank-Queries verlagert. Die Re-Implementierung der erweiterten Suchmöglichkeiten ohne expliziten Zugriff auf Elasticsearch (die eigentliche Hibernate-Search-Implementierung) steht noch aus(?). Im Rahmen von Gesprächen im @kitodo/kitodo-community-board wurden die folgenden Aspekte als wesentlich identifiziert, bei denen es wichtig wäre, unabhängig von der technischen Implementierung Stand und Perspektiven der Entwicklung einordnen zu können:
|
Beta Was this translation helpful? Give feedback.
-
|
Soweit ich es überblicke, sind alle in #5546 genannten Probleme der Eigenentwicklung geschuldet und werden daher behoben, wenn die Anwendung auf der Datenbank basiert und ein stabiles Framework für Indizierungsaktivitäten eingeführt worden ist. Im aktuellen Entwicklungsstand sind die Filter noch nicht wieder vorhanden. Das ist beabsichtigt. Sie werden wieder zum Leben erweckt, nachdem das Hibernate-Search-Framework vorhanden und funktionsfähig ist. Die aktuelle Zwischenversion des Codes unterstützt nur die Suche nach Titel und ID. Bisher wurden folgende Entwicklungsschritte durchgeführt:
Folgende Schritte stehen bevor:
|
Beta Was this translation helpful? Give feedback.
-
Ich freue mich, Ihnen mitteilen zu können, dass die ElasticSearch-durch-Hibernate-Search-ersetzen-Entwicklung inzwischen so weit fortgeschritten ist, dass ich einen Branch zur Verfügung stellen kann, der kompiliert und startet und größtenteils funktioniert, ohne den ElasticSearch-Index aktiv zu verwenden. Der selbst geschriebene ElasticSearch-Code wurde noch nicht entfernt, das wird der nächste Schritt sein.
Die Zwischenversion hat jedoch einige Punkte aufgezeigt, die in Zukunft möglicherweise etwas anders behandelt werden müssen und der Diskussion bedürfen.
Um die Anwendung zum Laufen zu bringen, musste ich das Lazy Loading für Projekte und Vorgänge deaktivieren. Für Projekte werden Vorgänge und Vorlagen derzeit sofort mitgeladen. Für Vorgänge werden die Kommentare und untergeordneten Vorgänge derzeit mitgeladen. Dies ist für größere Datenbanken unmöglich. Ich denke, der einzige Grund, warum sie sofort geladen werden müssen, ist, um zu prüfen, ob einige Symbole (wie der Papierkorb) dargestellt werden sollen. Ich weiß noch nicht, ob dies überhaupt mit der Hibernate-Search-Integration gelöst werden kann, da es sich um ein Suchframework handelt. Wahrscheinlich wird die erforderliche Lösung darin bestehen, zusätzliche Datenbankspalten mit den redundanten aber erforderlichen Informationen hinzuzufügen. Dies hat den Vorteil, dass die Anwendung ohne laufenden Index verfügbar ist. Das Speichern redundanter Informationen in einer Datenbank ist jedoch immer unschön.
Suchen eines vorhandenen übergeordneten Vorgangs anhand seiner PPN während des Katalogimports. Die PPN war nur im Index für die Suche verfügbar. Sollte das so bleiben oder sollte die PPN im Prozessdatensatz in der Datenbank gespeichert werden? Da die PPN wichtig ist und auch beim erneuten Importieren der Metadaten eine Rolle spielen wird, könnte man argumentieren, sie in der Datenbank zu speichern. Man könnte sie dann auch in der Vorgangsliste anzeigen.
Das Sortieren der Vorgangsliste nach den auf die letzte bearbeitete Aufgabe bezogenen Spalten „Letzter Bearbeitungsbenutzer“, „Beginn der Bearbeitung der letzten Aufgabe“, „Beendigung der Bearbeitung der letzten Aufgabe“ und „Status des Korrekturkommentars“ ist derzeit nicht möglich. Dies erfordert wahrscheinlich ein explizites Feld zur Markierung der „letzten Aufgabe“ im Vorgang, um die ersten drei Probleme zu beheben. Das vierte Problem hängt mit Punkt 1, Status Korrekturkommentar im Vorgang, zusammen.
Beim manuellen Hinzufügen eines untergeordneten Vorgangs zu einem übergeordneten Vorgang im Metadateneditor vergleicht der Suchschlitz nicht mehr mit den zulässigen Doctypes. Die Möglichkeiten sind, auf die Funktionalität zu verzichten, den Dokumenttyp im Vorgang in der Datenbank zu speichern, oder die Funktionalität nur mit laufendem Index verfügbar zu haben.
Der Filter-Schlitz ist derzeit nicht implementiert, er erkennt nur IDs zur sofortigen Navigation oder unterstützt die Suche nach einem Titel-Teil. Dies ist in der Zwischenversion beabsichtigt und wird später auf dem Hibenate-Search-Framework umgesetzt.
Ich habe diese Diskussion eröffnet, um die Punkte 1-4 zu diskutieren.
Beta Was this translation helpful? Give feedback.
All reactions