Solr Powered ISFDB – Teil #2: Grundlegende Schema-Verbesserungen

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

Als wir letzte Woche aufhörten, hatte ich Konfigurationen, die es mir ermöglichten, mit dem DataImportHandler einen sehr einfachen Index aller Titel+Autoren-Paare in der ISFDB zu erstellen, aber alles wird als roher String behandelt – was bedeutet, dass es für die Suche nicht sehr nützlich ist (wir haben keinerlei Tokenisierung oder Behandlung für numerische Felder). Unser heutiges Ziel ist es, das Schema zu verbessern, so dass wir damit einige interessante Abfragen durchführen können.

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

Der erste Schritt besteht darin, die vorhandenen Daten zu prüfen und zu überlegen, wie wir sie am besten in unserer schema.xml modellieren können. Für den Moment verzichte ich auf die Modellierung der ISFDB-Daten als Ganzes (Autoren, Titel, Veröffentlichungen usw.) und konzentriere mich nur auf die Felder, die ich mit meiner einfachen MySQL-Abfrage zurückbekomme. Es gibt mehrere Möglichkeiten, dies zu tun. Ich könnte damit beginnen, mir die Datenbank anzusehen, aber Solr bietet mir auch einige praktische Tools für diese Aufgabe.

(Hinweis: Wenn Sie mich schon einmal bei einer „Apache Solr: Out of the Box“-Demo gesehen haben, könnte sich das Lesen dieses Blogs überflüssig anfühlen)

Ich beginne damit, den Schema Browser zu laden. Auch wenn meine schema.xml-Datei sehr einfach ist und nur ein dynamisches Feld deklariert hat, kann mir der Schema-Browser alle möglichen interessanten Dinge über die konkreten Felder sagen, die aufgrund dieses dynamischen Feldes existieren.

Das erste, was mir auffällt, ist, dass zwei Felder „wikipedia“ in ihrem Namen enthalten: author_wikipedia und title_wikipedia. Wenn ich auf eines dieser Felder klicke, sehe ich Statistiken, die mir zeigen, in wie vielen Dokumenten Begriffe in diesem Feld indiziert sind, wie viele eindeutige Begriffe in diesem Feld existieren, was einige der Top-Begriffe sind, und ein Histogramm der Begriffshäufigkeiten im gesamten Index. In beiden Fällen ist es aus den Listen der Top-Begriffe ziemlich offensichtlich, dass diese Felder URLs von Wikipedia-Seiten über den Autor (bzw. den Titel) enthalten. Aus den Histogrammen (und den Häufigkeiten der Top-Begriffe) kann ich auch ersehen, dass die URL „title_wikipedia“ in der Regel pro Dokument einzigartig ist, während die URL „author_wikipedia“ sehr häufig vorkommt. Da jedes Dokument einem Titel+Autor-Paar entspricht, macht dies Sinn – denn Autoren schreiben viele Bücher, aber die meisten Bücher haben nicht mehrere Autoren. Da es sich um URL-Felder handelt und die einzigen Wörter in diesen URLs, die für meine Suche relevant sind, die Namen des Autors und des Titels sind (die, wie ich deutlich sehen kann, die Namen anderer Felder sind), brauche ich mich nicht um die „Indizierung“ dieser Felder zu kümmern (d.h. ich werde sie nicht durchsuchen, sortieren oder facettieren), aber ich werde sie weiterhin „speichern“, damit die Benutzer nach der Ausführung einer Suche auf diese Links zugreifen können.

Anstatt jedes Feld explizit als indexed=false aufzulisten, deklariere ich einen fieldType für den Umgang mit URLs (es ist immer noch als StrField implementiert) und lege die Eigenschaft dort fest. Das ist nur meine Vorliebe, da ich dieses Verhalten auch für alle anderen Felder vom Typ URL haben möchte, die ich später hinzufüge.

Sobald ich meine schema.xml ändere, gibt es eine Menge kleiner Tricks, die ich anwenden könnte, um sie spontan neu zu laden, aber ich bevorzuge den einfachsten Ansatz – Solr stoppen, die Datei ändern, Solr starten (das ist schnell und einfach). So wie ich das Github-Projekt eingerichtet habe, werden die Dateien, die Sie in src/ bearbeiten, automatisch kopiert und jedes Mal verwendet, wenn Sie „ant run-solr“ ausführen, so dass Sie DIH nur noch sagen müssen, dass es neu indizieren soll…

http://localhost:8983/solr/dataimport?command=full-import

Von hier aus iterieren wir und sehen uns weitere Felder im Schema-Browser an. Außerdem nehmen wir ein paar einfache Änderungen an unserer schema.xml vor und notieren uns Dinge, die später nützlich sein könnten, wenn wir unsere Suchfunktion überdenken wollen.

• author_imdb und author_image sind ebenfalls URL-Felder.
• Jedes Dokument im Index hat denselben Wert für title_ctl, also ignorieren wir ihn.
• author_id und title_id sind eindeutig die numerischen Bezeichner für den Autor und den Titel, die der aktuellen Zeile entsprechen, so dass wir sie vorerst ignorieren können. Aber es gibt auch Felder wie series_id, title_parent und title_synopsis, die numerisch sind und deren Histogramme darauf hindeuten, dass es sich wahrscheinlich um Fremdschlüssel zu anderen Tabellen in der Datenbank handelt, so dass wir auch sie vorerst ignorieren, aber wir sollten sie für die Zukunft im Auge behalten, wenn wir unser Domänenmodell verbessern.
• ca_status und author_marque sind ebenfalls numerische Werte, haben aber eine extrem niedrige Anzahl von unterschiedlichen Begriffen – sie sind also wahrscheinlich Codes für etwas und keine Fremdschlüssel. Sie könnten später für Facetten nützlich sein, sobald wir wissen, was sie bedeuten.
• title_ttype ist eine offensichtliche Aufzählung – vorerst als String belassen, aber für Facettierung berücksichtigen
• author_annualviews, author_views, title_views, title_annualviews und title_rating sind allesamt numerische Werte und lassen vermuten, dass sie für eine spätere „Gewichtung“ der Ergebnisse nützlich sein könnten (um die Relevanz zu beeinflussen).
• author_birthdate und author_deathdate sind (natürlich) Datumsfelder.

Die übrigen Felder sind alle „Text“ in der einen oder anderen Form. In Solr besteht der Unterschied zwischen „Strings“ und „Text“ darin, dass String-Felder wortwörtlich indiziert werden und die Suche nach einem String-Feld eine exakte Übereinstimmung des gesamten Wertes erfordert (Großschreibung, Interpunktion, Leerzeichen, alles…), während Textfelder zur Index- und Abfragezeit jede beliebige benutzerdefinierte Tokenisierung und Analyse haben können. Ich werde mir die Frage, warum/wie/wann ich für verschiedene Felder unterschiedliche Textanalysen benötige, für einen anderen Tag aufheben und einfach einen sehr einfachen Ansatz für alle Felder verwenden. Damit kann ich nun das „*“ dynamicField, das ich verwendet habe, entfernen (weil ich alle meine Felder identifiziert und ihnen eindeutige Typen gegeben habe) und bin für heute fertig.

Etwas, das ich an dieser Stelle betonen möchte: Wenn Sie erst einmal den Dreh raus haben, ist die Verwendung des Schema-Browsers zur Inspektion der Felder, die iterative Bearbeitung der Schemadatei und die Neuindizierung ein wirklich einfacher und unkomplizierter Prozess – selbst wenn Sie sich das zugrunde liegende DB-Schema noch nie angesehen haben. Es hat mindestens zehnmal länger gedauert, über die Dinge zu schreiben, die ich in diesem Blog getan habe, als sie tatsächlich zu tun.

Damit sind wir beim blog_2-Tag angelangt. Ich habe jetzt einen viel nützlicheren Index als letzte Woche und kann alle möglichen interessanten Abfragen durchführen, wie zum Beispiel…

• Alle Datensätze, in denen der Nachname des Autors smith lautet
• Alle Datensätze für Romane von in Paris geborenen Autoren
• Aufzeichnungen über Titel mit „Leerzeichen“ im Namen, mit Faketenzählungen basierend auf der Art der Arbeit
• Eine Aufschlüsselung, die zeigt, wie viele Romane „Weltraum“ vs. „Roboter“ vs. „Roboter“ in ihren Titeln enthalten

Das war’s für diese Woche. Ich habe noch nicht entschieden, worauf ich mich beim nächsten Mal konzentrieren werde, aber es gibt unendlich viele Verbesserungsmöglichkeiten und viele verschiedene Wege, wie man sie angehen kann – wenn Sie Vorschläge haben, schreiben Sie sie bitte in die Kommentare.