Solr-gestützte ISFDB – Teil #4: Mehrere Dokumenttypen

Dies ist Teil 4 einer (nicht enden wollenden?) Artikelserie über das Indizieren und Durchsuchen der ISFDB.org-Daten mit Solr.

Als wir uns das letzte Mal trennten, hatte ich einen schönen Index von „titelzentrierten“ Dokumenten – ein Dokument für jeden Titel in der ISFDB, mit mehrwertigen Feldern, die die grundlegenden Daten über jeden Autor enthalten, der an einem Titel gearbeitet hat. Dies ist die erste Woche, in der ich am Freitag keine Zeit hatte, an dem Projekt zu arbeiten. Also habe ich heute (Samstag) ein wenig Arbeit dazwischengeschoben, um die Grundlagen für die autorenzentrierten Dokumente zu schaffen.

(Wenn Sie zu Hause mitarbeiten möchten, können Sie den Code auf github auschecken. Ich beginne mit dem blog_3-Tag und werde im weiteren Verlauf des Artikels auf bestimmte Commits verweisen, in denen ich etwas geändert habe, bis hin zum blog_4-Tag, der das Endergebnis dieses Artikels enthält).

Warum nicht mehrere Indizes verwenden?

Eine kurze Abschweifung: Heute werde ich damit beginnen, mehrere verschiedene Arten von Dokumenten in einem Index zusammenzufassen. Sie werden sich vielleicht fragen (und das zu Recht) „Warum nicht einfach mehrere Indizes verwenden? Wäre es nicht sinnvoll, dafür mehrere SolrCores zu verwenden?“ Die Antwort lautet: „Es kommt darauf an“. Wenn ich völlig unterschiedliche Anwendungsfälle für die Titelsuche und die Autorensuche hätte, dann wäre es sicherlich sinnvoll, verschiedene Kerne mit unterschiedlichen Schemata zu verwenden – aber letztendlich möchte ich in der Lage sein, ein einziges einfaches Suchfeld zu unterstützen, in das Sie einfach irgendetwas eingeben können (einen Namen, einen Titel, ein Schlüsselwort) und „gute“ Ergebnisse erhalten, wobei Autoren und Titel in einem Satz von Ergebnissen vermischt werden. An diesem Punkt kann die Facettierung verwendet werden, um zu sagen: „Nein, ich wollte eigentlich nur nach Titeln suchen…“ oder „Eigentlich will ich nur Autoren…“.

Nun, da wir das geklärt haben…

Unterstützung für mehrere Dokumenttypen

Um mehrere Dokumenttypen in einem einzigen Index zu unterstützen, müssen wir zunächst unseren uniqueKey so gestalten, dass er für alle Dokumenttypen eindeutig ist, damit wir keine Kollisionen riskieren. Ich habe also ein Feld „doc_id“ zu meinem Schema hinzugefügt und es zum Feld uniqueKey gemacht. Um dieses Feld für jedes meiner Dokumente zu füllen, verwende ich den „TemplateTransformer“, um ein künstliches Feld aus dem Feld „title_id“ zu erstellen, wobei jedem Wert ein „TITLE_“-Präfix vorangestellt wird, um sie eindeutig zu machen (so dass title_id #4321 und author_id #4321 sich im Index nicht gegenseitig überschreiben.

Dies ist das erste Mal, dass ich explizit die <field …> Syntax von DIH verwenden muss, um ein Feld zu deklarieren (weil der Feldname nicht genau mit dem Spaltennamen aus der DB übereinstimmt und ich ihn mit einem Transformer generieren muss) und es zeigt eine Eigenart auf, wie DIH mit Feldern umgeht: Es bezieht sich auf den Feldnamen, den Sie in Solr als „Spalte“ verwenden wollen…


<field column="doc_id" template="TITLE_${title.title_id}" />


Das hat mich sehr verwirrt, als ich mir die Beispiele angesehen habe. Ich wollte eigentlich so etwas schreiben…


<field name="doc_id" template="TITLE_${title.title_id}" />


…aber wie Sie an anderen Beispielen in den DIH-Dokumenten sehen können, wird das <Feld …> Tag auf diese Weise verwendet, auch wenn die Quelle der Daten keine DB ist. (Das ergibt für mich nicht viel Sinn, aber es ist, wie es ist).

Da wir nun ein neues uniqueKey-Feld mit einem generierten Wert für alle unsere Titeldokumente haben, benötigen wir auch ein „doc_type“-Feld, das (Überraschung!) den Typ des Dokuments festhält, mit dem wir es zu tun haben. Wie in der DIH-FAQ erwähnt, ist dies mit Hilfe des Template Transformer ganz einfach zu bewerkstelligen…

<field column="doc_type" template="TITLE" />


Autoren hinzufügen

Wenn die Grundlage geschaffen ist, müssen Sie nur noch eine neue Entität auf oberster Ebene in unserer DIH-Konfiguration hinzufügen. Im Moment verwende ich nur einfache Felder aus der Tabelle Autor, die ich später erweitern kann. Ich verwende auch überlappende Felder im Schema für Eigenschaften eines Autors, die bereits in meinen titelzentrierten Dokumenten enthalten sind. Dies ist eine Abkürzung, um Zeit zu sparen, aber letztendlich werde ich diese Felder aus zwei Gründen besser unterscheiden wollen:

• Schema-Eigenschaften: Auch wenn es wahrscheinlich sinnvoll ist, für diese Felder in den Autorendokumenten und den Titeldokumenten denselben Feldtyp zu verwenden, sollten in einem guten Dokumentenmodell Eigenschaften wie „multiValued“ zwischen ihnen unterschiedlich sein – denn ein Titel kann mehrere Autorennamen haben, aber ein Autor kann nur einen kanonischen Namen haben.
• Feldstatistiken: Dinge wie die IDF eines Feldes erstrecken sich über den gesamten Index – sie wissen nichts über „doc_type“, so dass Felder wie „author_canonical“ bei der Art und Weise, wie ich sie wiederverwende, völlig aus dem Gleichgewicht geraten. (z.B.: nicht viele Autoren haben „asimov“ in ihrem Namen, aber viele Titeldokumente schon).

Fazit (vorläufig)

Und damit ist diese letzte Folge des blog_4-Tags abgeschlossen. Jetzt können wir nicht nur nach„Büchern von Personen namens Asimov“ suchen, sondern auch nach„Personen namens Asimov„.

Entschuldigen Sie, dass dieser Beitrag so kurz war. Schauen Sie Ende dieser Woche wieder vorbei, wenn ich hoffentlich etwas mehr Zeit habe, um das Schema etwas aufzuräumen und die Modellierung der „autorenzentrierten“ Dokumente zu verbessern.