Searching for tens of thousands of hits yields incomplete results

[matthias-ronge]

Searching with a keyword in the index only returns ten thousand results, not all of them. And if all results were available, the ID list would have to be passed into the database for filtering with other conditions. This is not a text search for users, and using a search engine for this purpose misses the mark. This is inefficient in terms of performance and memory usage, even on powerful servers.

Some metadata is used as a filter keyword; this applies to selection criteria such as service provider, scanner, or subproject. A metadata keyword is assigned to tens of thousands of processes, and then the search, especially for statistical purposes, must retrieve all hits.

To Reproduce

1. Steps to reproduce the behavior:
2. Create a database containing tens of thousands of processes, more than ten thousand of which share the same metadata value.
3. Search for the metadata.
4. The results list is incomplete.

Expected behavior
The query result must be complete.

Release
Kitodo.Production 3.9

Cf. #6549 #6719

[matthias-ronge]

Unfortunately, it seems to me that the only answer to this is that such specific metadata values ​​must be stored in the database. Hibernate can automate this for us:

public class Process {

    // ...

    @ElementCollection
    @CollectionTable(
        name = "process_x_tag",
        joinColumns = @JoinColumn(name = "process_id")
    )
    @Column(name = "tag")
    private Set<String> tags;

    // ...
}

This can be generated from IndexingKeyworder and updated on save. The search must be performed with a JOIN clause, for example:

FROM Process process JOIN process.tags tag WHERE tag = :tag

The BeanQuery can already do this. Let's elaborate on the details here in this ticket.

The questions are:

• How best to mark this in the ruleset?
• Is it sufficient to implement a special search field tag:, or does it need to be recognized and handled during free metadata searches? Or are these details unimportant to you, and just keep it as simple as possible for now?

[henning-gerhardt]

Should it not be a better way to move the discussion how to solve the issue to the https://github.com/kitodo/kitodo-production/discussions itself?

[matthias-ronge]

Okay, the question is perhaps broader than I initially thought. Yes, I started a discussion about it. I created that in German for the others; it's better than converting. And here's just the technical implementation. The question is, is this approach with the field and the database tables feasible for you?

[henning-gerhardt]

My answer or more questions in German:

1. Warum zwei Diskussionen über ein Thema? Bedingen sich nicht die technische als auch die Benutzer-Sicht sich nicht zwangsläufig?
2. Deine Idee, ist doch das gleiche, was wir aktuell schon über die "property" Tabellen haben. Was passiert mit diesen überhaupt?
3. Warum müssen die Metadaten in einzelne "tags" aufgeteilt werden? Mit dem SQL Funktionalität match (siehe bspw. MariaDB-Beschreibung müsste man dies überhaupt nicht machen, wenn man die Metadaten als FULLTEXT Spalte (oder mehrere) in der Tabelle ablegt und darüber eine Suche durchführt.

[BartChris]

Wenn es für Matthias ok ist, können wir auch einfach diesen Issue automatisch in eine Github-Diskussion umwandeln.

Warum müssen die Metadaten in einzelne "tags" aufgeteilt werden? Mit dem SQL Funktionalität match (siehe bspw. MariaDB-Beschreibung müsste man dies überhaupt nicht machen, wenn man die Metadaten als FULLTEXT Spalte (oder mehrere) in der Tabelle ablegt und darüber eine Suche durchführt.

Ich sehe es genauso. Ergänzend würde ich auch fragen, warum man denn die Elemente die nicht als Tag markiert sind weiterhin in Elasticsearch vorhalten muss (so verstehe ich deinen Vorschlag); denn wir nutzen auch dafür die Feature von Elasticsearch nicht.

Aus meiner Sicht hast du durch deine Imlementierungen bereits wesentliche Schritte getan: Wir tokenisieren die Wörter außerhalb von Elasticsearch und manipulieren sie zum Zweck der Metadatensuche (titleDocMainqRhein). Und wir wollen von den bereits durch uns tokenisierten Tokens nur wissen, in welchen Dokumenten sie enthalten sind. Das ist aus meiner Sicht gerade der idealtypische Use Case für eine datenbankgestützte Volltextsuche.

Man müssten natürlich evaluieren wie man Hibernate und MATCH-queries zusammenbekommt; aber bevor wir durch weitere Annotationen in den rulesets alles noch weiter verkomplizieren, wäre meine Ideallösung eine durchgreifende: Der Verzicht auf Elasticsearch und die vollständige Ersetzung auch der Properties durch eine datenbankgestützte Suche in Volltextfeldern.

[matthias-ronge]

Warum zwei Diskussionen über ein Thema? Bedingen sich nicht die technische als auch die Benutzer-Sicht sich nicht zwangsläufig?

Auf dem Praxistreffen hatten wir ein Barcamp-Thema dazu, dass vielen von unseren Benutzenden die Issues zu technisch sind. Die fühlen sich erschlagen, wenn ihnen @CollectionTable joinColumns entgegen fliegen. Außerdem war dieses Issue auf Englisch und ich wollte das bewusst trennen.

Deine Idee, ist doch das gleiche, was wir aktuell schon über die "property" Tabellen haben.

Nicht genau. Es ist viel einfacher. Property ist eine komplexe Klasse:

Property {
    title : String
    value : String
    obligatory : Boolean
    dataType : { UNKNOWN | MESSAGE_IMPORTANT | MESSAGE_ERROR | STRING }
    choice : String
    creationDate : Date
    processes : List<Process>
    templates : List<Process>
    workpieces : List<Process>    
}

Jede Property wird über drei Kreuztabellen Vorgängen zugeordnet, wahlweise als Vorgangs-, Vorlagen- oder Werkstückeigenschaft. Das ist ein Erbe von ganz ganz früher und völlig überverkompliziert.

Was passiert mit diesen überhaupt?

Die sollen zumindest so weit wie möglich zurückgebaut werden: #3335. Am liebsten hätte ich sie ganz raus, aber die Schweizer Variante benötigt sie noch irgendwofür. “Offiziell” soll es sie in der Community Edition trotzdem nicht mehr geben.

Warum müssen die Metadaten in einzelne "tags" aufgeteilt werden?

Müssen vielleicht nicht, aber, ich habe ein bisschen recherchiert und der Vorschlag, den ich fand, hieß, man solle die lange ID-Liste in eine temporäre Tabelle in der Datenbank laden und dann mit einem JOIN suchen. Auf die Idee habe ich aufgebaut. Bei der Suche kann die Datenbank dann anhand des Tags dessen ID holen und hat damit über process_x_tag alle Vorgänge dazu.

Ein Vorgang hat sowieso nur dann mehrere Tags, wenn mehrere Metadaten als Tag definiert wurden, was wohl eh eher selten sein wird. Nach deinem Vorschlag müsste man die Metadaten dann in einen String konkatenieren. Und bei der Suche müsste man dann noch mit möglichen Leerzeichen umgehen und jeder dieser String müsste geparst werden? Erscheint mir für diesen Zweck nicht die bessere Lösung.

Ergänzend würde ich auch fragen, warum man denn die Elemente die nicht als Tag markiert sind weiterhin in Elasticsearch vorhalten muss

Das könnte auch anders gelöst sein, aber es wurde seinerzeit so entschieden: die Metadaten stehen in der Mets-Datei. Es hat Nachteile, einer davon ist, das man die Datei sperren muss, wenn sie von einem Benutzer bearbeitet wird, ein andere ist der Index. Die Vorteile sind, dass man die Dateien getrennt von der Datenbank erstellen, kopieren, sichern, wiederherstellen usw. kann und mit Skripten darin herumwerkeln kann, ohne die Datenbank kaputt machen zu können. Ein Scanner kann eine rudimentäre Mets-Datei erstellen, wenn beim Scannen bereits strukturiert wird, ohne in der produktiven Datenbank herumschreiben zu müssen. Die Metadaten sind ja auch im Mets-Format, obwohl die Anwendung intern ein ganz anderes Datenmodell hat, um damit einen niederschwelligeren Zugang für Systembibliothekare zu geben. Es ist so gedacht, dass man die Daten anfassen kann.

Aus meiner Sicht hast du durch deine Imlementierungen bereits wesentliche Schritte getan: Wir tokenisieren die Wörter außerhalb von Elasticsearch und manipulieren sie zum Zweck der Metadatensuche (titleDocMainqRhein). Und wir wollen von den bereits durch uns tokenisierten Tokens nur wissen, in welchen Dokumenten sie enthalten sind. Das ist aus meiner Sicht gerade der idealtypische Use Case für eine datenbankgestützte Volltextsuche.

Ich glaube, es gab da noch ein Problem: InnoDB unterstützt(e zumindest bislang) keine Volltextsuche, und MyIsam nicht alle Abhängigkeitsüberprüfungen, oder so. Deswegen hatten wir uns für InnoDB entschieden.

[BartChris]

Ich glaube, es gab da noch ein Problem: InnoDB unterstützt(e zumindest bislang) keine Volltextsuche, und MyIsam nicht alle Abhängigkeitsüberprüfungen, oder so. Deswegen hatten wir uns für InnoDB entschieden.

Da wir mittlerweile von Java 17 und 21 als Dependency ausgehen, sollte eigentlich auch Mysql8.0 zwingend vorausgesetzt werden: https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/innodb-fulltext-index.html

[henning-gerhardt]

Warum zwei Diskussionen über ein Thema? Bedingen sich nicht die technische als auch die Benutzer-Sicht sich nicht zwangsläufig?

Auf dem Praxistreffen hatten wir ein Barcamp-Thema dazu, dass vielen von unseren Benutzenden die Issues zu technisch sind. Die fühlen sich erschlagen, wenn ihnen @CollectionTable joinColumns entgegen fliegen. Außerdem war dieses Issue auf Englisch und ich wollte das bewusst trennen.

Dies führt nun dazu, dass es 2 recht unabhängige Diskussionen geführt werden, die noch dazu auf unterschiedlichen Ebenen besprochen werden. Das viele Issues auf Englisch geführt werden, liegt ja eher daran, dass man internationaler auftreten will, wenn auch der sehr große Teil der Anwender und Entwickler im DACH-Raum ist. Aber das ist keine Entscheidung oder Diskussion, die hier weiter geführt werden soll.

Deine Idee, ist doch das gleiche, was wir aktuell schon über die "property" Tabellen haben.

Nicht genau. Es ist viel einfacher. Property ist eine komplexe Klasse:

Mir sind die Property bzw. früheren Eigenschaften-Tabellen sehr gut bekannt und diese waren ja ebenfalls ein Versuch, wie man nach Metadaten suchen kann. Dies hat nie richtig funktioniert und war darüber hinaus sehr fehleranfällig weswegen man nach einer anderen Lösung (ElasticSearch) geschaut hat. Aber bei der neuen Lösung kommen auch neue Probleme, die man anfänglich nicht gesehen hat.

Warum müssen die Metadaten in einzelne "tags" aufgeteilt werden?

Müssen vielleicht nicht, aber, ich habe ein bisschen recherchiert und der Vorschlag, den ich fand, hieß, man solle die lange ID-Liste in eine temporäre Tabelle in der Datenbank laden und dann mit einem JOIN suchen. Auf die Idee habe ich aufgebaut. Bei der Suche kann die Datenbank dann anhand des Tags dessen ID holen und hat damit über process_x_tag alle Vorgänge dazu.

Ganz verstehe ich die Idee noch nicht. Du erwähnst einen Vorschlag. Kann man diesen irgendwo nachlesen?

Ein Vorgang hat sowieso nur dann mehrere Tags, wenn mehrere Metadaten als Tag definiert wurden, was wohl eh eher selten sein wird. Nach deinem Vorschlag müsste man die Metadaten dann in einen String konkatenieren. Und bei der Suche müsste man dann noch mit möglichen Leerzeichen umgehen und jeder dieser String müsste geparst werden? Erscheint mir für diesen Zweck nicht die bessere Lösung.

Ich denke eher, dass man nach allen Metadaten suchen können sollte und nicht nur nach spezifischen, die man - nach Vorschlag in der Diskussion - im Regelsatz definiert. Sobald im Regelsatz neue Metadaten dazu kommen oder andere nicht mehr "durchsuchbar" sein sollten, müsste immer wieder alles in dieser "Tag-Tabelle" neu gemacht werden. Bei knapp 1 Mio Datensätzen, die wir an der SLUB jetzt fast haben und in vielen Datensätzen nicht nur ein, zwei Metadaten sondern sehr viele durchsuchbar sein sollen, wird dies eine riesige und vermutlich nicht mehr wartbare Tabelle. Auch sehe ich nicht, dass man über die Tag-Tabelle nicht nach bestimmten Metadaten-Feldern suchen kann. Aber auch bei den Inhalten muss dies berücksichtigt werden, da die Inhalte ggf. auch nicht jeden Benutzer direkt bekannt sind (bspw. wenn die Dokumtensprache als Deutsch über eine Drop-Down-Liste aufgeführt wird und intern als ger gespeichert wird, dann werden die wenigsten nach tag:ger suchen sondern eher nach tag:deutsch oder bei der Schriftfamilie die als Antiqua oder Fraktur angegeben ist, aber intern als Latf oder Latngespeichert wird).

Ergänzend würde ich auch fragen, warum man denn die Elemente die nicht als Tag markiert sind weiterhin in Elasticsearch vorhalten muss

Das könnte auch anders gelöst sein, aber es wurde seinerzeit so entschieden: die Metadaten stehen in der Mets-Datei.

Wo die Metadaten gespeichert werden, sollte jetzt nicht wieder aufgewärmt werden, da wir dann wieder in andere Diskussionen verfallen und das eigentliche Ziel aus den Augen verlieren. Wenn dies ein Thema ist, sollte dieses separat behandelt werden.

Ich glaube, es gab da noch ein Problem: InnoDB unterstützt(e zumindest bislang) keine Volltextsuche, und MyIsam nicht alle Abhängigkeitsüberprüfungen, oder so. Deswegen hatten wir uns für InnoDB entschieden.

Leider weiß ich nicht, woher diese Information kommt, aber seit Jahren sind in Oracle MySQL und MariaDB Volltextsuchen enthalten. Diese waren früher einmal nicht so gut und ineffektiv, weswegen man sie vielleicht nicht angewandt hat, aber dies hat sich geändert. Wie effektiv und performant diese für die Anwendung und die gewünschten Anwendungsszenarien sind, müsste sich zeigen.

[BartChris]

Ergänzend würde ich auch fragen, warum man denn die Elemente die nicht als Tag markiert sind weiterhin in Elasticsearch vorhalten muss
Das könnte auch anders gelöst sein, aber es wurde seinerzeit so entschieden: die Metadaten stehen in der Mets-Datei.

Wo die Metadaten gespeichert werden, sollte jetzt nicht wieder aufgewärmt werden, da wir dann wieder in andere Diskussionen verfallen und das eigentliche Ziel aus den Augen verlieren. Wenn dies ein Thema ist, sollte dieses separat behandelt werden.

Um das auch nochmal klarzustellen: an der Frage, wo die Metadaten gepeichert sind wollte ich gar nicht rühren. Mir ging es nur um die Frage, wo sie indexiert werden, also nur um den Ort der Indexierung. Das alles sollte die METS-Datei überhaupt nicht berühren.

[tboenig]

Zwar ist die Diskussion noch nicht abgeschlossen.
Aus diesem Grund erinnere ich, dass neben den Fragen zur Funktionalität der Datenbank, Indizierung..., hier wieder eine Veränderung der Rulesets vorgenommen wird, die im verwendeten Ruleset-Schema nachzupflegen ist.