<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div dir="auto">Liebe Kollegen, <br>
<br>
</div>
<div dir="auto">ein bisschen Hintergrund zur Solr-Suche in Presentation:<br>
</div>
<div dir="auto">- 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.
<br>
</div>
<div dir="auto">- 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. <br>
</div>
<div dir="auto">- 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.
<br>
</div>
<div dir="auto">- 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.
<br>
</div>
<div dir="auto">- 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.
<br>
</div>
<div dir="auto">- 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.
<br>
<br>
</div>
<div dir="auto">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.
<br>
<br>
</div>
<div dir="auto">Viele Grüße <br>
</div>
<div dir="auto">Sebastian <br>
<br>
<br>
<br>
</div>
<div dir="auto"><b>Von:</b> David Maus <br>
</div>
<div dir="auto"><b>Gesendet:</b> Thu Jul 06 08:12:27 GMT+02:00 2017<br>
</div>
<div dir="auto"><b>An:</b> kitodo-verein@kitodo.org<br>
</div>
<div dir="auto"><b>Betreff:</b> Re: [Kitodo-Verein] Entwicklungsauftrag<br>
<br>
</div>
<div dir="auto">On Thu, 06 Jul 2017 07:56:53 +0200,<br>
</div>
<div dir="auto">Stefan Weil wrote:<br>
<br>
<br>
</div>
<div dir="auto">Am 06.07.2017 um 07:10 schrieb David Maus:<br>
<br>
<br>
</div>
<div dir="auto">Der Fehler liegt meiner Einschätzung nach hier:<br>
<br>
</div>
<div dir="auto"><a href="https://github.com/kitodo/kitodo-presentation/blob/master/dlf/common/class.tx_dlf_solr.php#L347"></a><a href="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</a><br>
<br>
</div>
<div dir="auto">Die Vermutung von Herrn Mödinger ist demnach korrekt. Kitodo ruft<br>
</div>
<div dir="auto">immer die gesamte Treffermenge ab und wählt dann die anzuzeigenden<br>
</div>
<div dir="auto">Ausschnitt aus. Das ist nicht sinnvoll. Die Auswahl der anzuzeigenden<br>
</div>
<div dir="auto">Teilmenge sollte besser durch Solr erfolgen.<br>
<br>
</div>
<div dir="auto">Im o.g. Funktionsaufruf ist es das zweite (offset = start) und dritte<br>
</div>
<div dir="auto">Argument (limit = rows).<br>
<br>
</div>
<div dir="auto">Die Berechnung:<br>
<br>
</div>
<div dir="auto">start = (Ausgewählte Seite - 1) * Treffer pro Seite<br>
</div>
<div dir="auto">rows = Treffer pro Seite<br>
<br>
</div>
<div dir="auto">HTH,<br>
</div>
<div dir="auto">-- David Maus<br>
<br>
<br>
</div>
<div dir="auto">Zu klären wäre auch noch, wie lange die Abfrage nach der Trefferzahl<br>
</div>
<div dir="auto">dauert (die braucht man für die Anzeige, wie viele Treffer in<br>
</div>
<div dir="auto">wie vielen Dokumenten es gibt, und auch für die Berechnung der<br>
</div>
<div dir="auto">benötigten Ergebnisseiten). Dabei sind ja nur zwei Zahlenwerte<br>
</div>
<div dir="auto">zu übertragen.<br>
<br>
<br>
</div>
<div dir="auto">Die Gesamtzahl der Treffer wird in der Solr-Antwort unter dem<br>
</div>
<div dir="auto">Schlüssel "response"/"numFound" geliefert.<br>
<br>
</div>
<div dir="auto">Bspw. hier ein Solr für eines unserer Portale:<br>
<br>
</div>
<div dir="auto">{<br>
</div>
<div dir="auto">"responseHeader":{ … },<br>
</div>
<div dir="auto">"response":{"numFound":91764,"start":0,"docs":[ … ]}<br>
</div>
<div dir="auto">}<br>
<br>
</div>
<div dir="auto">HTH,<br>
</div>
<div dir="auto">-- David Maus</div>
</body>
</html>