[Kitodo] [Kitodo-Verein] Entwicklungsauftrag

[Meyer, Sebastian]

Liebe Kollegen,

ein bisschen Hintergrund zur Solr-Suche in Presentation:
- Aktuell wird die gesamte Trefferliste abgerufen und in ein internes Listenobjekt umgewandelt. Diese Liste wird dann paginiert, mit DB-Informationen angereichert und schließlich ausgegeben.
- Die langen Laufzeiten ergeben sich aus dem Parsing des Solr-Ergebnisses (mitunter sehr große XML-Dokumente) sowie dem anschließenden Processing, bei dem Über- und Unterordnungen bzw. mehrere Treffer im selben Werk erkannt und die Objekte entsprechend aggregiert werden.
- Presentation zeigt in der Trefferliste immer die Werkebene an und aggregiert Treffer innerhalb eines Werks darunter. Solr liefert dagegen Solr-Objekte als Treffer, was grundsätzlich Strukturelemente oder sogar (bei der Volltextsuche) Einzelseiten sind. Um eine Trefferliste mit z. B. 20 Treffern (= Werken) darzustellen, müssen also in der Regel mehr als 20 Solr-Dokumente abgerufen. "start=0" und "rows=20" würde hier nicht das gewünschte Ergebnis liefern.
- Man könnte zwar durch zusätzliche Abfragen jeweils zu jedem Solr-Treffer die Werkeebene ermitteln, möchte aber ja außerdem ALLE Treffer innerhalb dieses Werks darunter gruppieren und nicht nur diejenigen, die das Solr-Relevanzranking in das aktuelle Trefferset gesteckt hat. Auch das ließe sich noch über zusätzliche Abfragen lösen. Schwierig wird es dann, wenn man auf einer späteren Trefferseite wieder auf einen Treffer aus einem Werk stößt, dass man auf einer vorherigen Seite bereits dargestellt hat (weil es auch höher gerankte Treffer enthält). In diesem Fall will man das Werk ja nicht nochmal aufführen, müsste also irgendwie ermitteln oder speichern, ob das Werk schon einmal in der Trefferliste war.
- Letzteres ist auch der Grund, weshalb eine reine Umstellung auf eine Paginierung seitens Solr (Parameter "start" und "rows") nicht ausreicht, um das Problem zu lösen. Die resultierende Trefferliste würde dann nämlich keine Informationen mehr darüber enthalten, wie viele Treffer innerhalb eines Werks insgesamt gefunden wurden.
- Besonders prekär ist diese Aggregation übrigens bei Zeitungen, wo sich sehr viele Ausgaben unterhalb eines Werks gruppieren, so dass schon eine Trefferliste mit 10 Werken mehrere 1000 aggregierte "Untertreffer" enthalten kann. An der SLUB führt das sogar dazu, dass manche Suchen in den Zeitungskollektionen gar kein Ergebnis mehr liefern, weil dem Prozess der Speicher ausgeht.

Ich stimme demnach zu, dass dringend etwas getan werden müsste, wollte aber darauf hinweisen, dass die Lösung leider nicht ganz so einfach ist wie sie anfangs erscheint. In der Suche steckt mehr Logik als allein mit Solr abgebildet werden kann.

Viele Grüße
Sebastian



Von: David Maus
Gesendet: Thu Jul 06 08:12:27 GMT+02:00 2017
An: kitodo-verein at kitodo.org
Betreff: Re: [Kitodo-Verein] Entwicklungsauftrag

On Thu, 06 Jul 2017 07:56:53 +0200,
Stefan Weil wrote:


Am 06.07.2017 um 07:10 schrieb David Maus:


Der Fehler liegt meiner Einschätzung nach hier:

<https://github.com/kitodo/kitodo-presentation/blob/master/dlf/common/class.tx_dlf_solr.php#L347>https://github.com/kitodo/kitodo-presentation/blob/master/dlf/common/class.tx_dlf_solr.php#L347

Die Vermutung von Herrn Mödinger ist demnach korrekt. Kitodo ruft
immer die gesamte Treffermenge ab und wählt dann die anzuzeigenden
Ausschnitt aus. Das ist nicht sinnvoll. Die Auswahl der anzuzeigenden
Teilmenge sollte besser durch Solr erfolgen.

Im o.g. Funktionsaufruf ist es das zweite (offset = start) und dritte
Argument (limit = rows).

Die Berechnung:

start = (Ausgewählte Seite - 1) * Treffer pro Seite
rows = Treffer pro Seite

HTH,
-- David Maus


Zu klären wäre auch noch, wie lange die Abfrage nach der Trefferzahl
dauert (die braucht man für die Anzeige, wie viele Treffer in
wie vielen Dokumenten es gibt, und auch für die Berechnung der
benötigten Ergebnisseiten). Dabei sind ja nur zwei Zahlenwerte
zu übertragen.


Die Gesamtzahl der Treffer wird in der Solr-Antwort unter dem
Schlüssel "response"/"numFound" geliefert.

Bspw. hier ein Solr für eines unserer Portale:

{
"responseHeader":{ … },
"response":{"numFound":91764,"start":0,"docs":[ … ]}
}

HTH,
-- David Maus
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://bibservices.biblio.etc.tu-bs.de/pipermail/kitodo/attachments/20170706/da70166e/attachment.html>
-------------- nächster Teil --------------
_______________________________________________
Kitodo-Verein mailing list
Kitodo-Verein at kitodo.org
https://maillist.slub-dresden.de/cgi-bin/mailman/listinfo/kitodo-verein