Solr-gestützte ISFDB – Teil 1
Dies ist Teil 1 einer (nie endenden?) Serie von Artikeln über die Indizierung und Suche der ISFDB.org-Daten mit Solr. Es…
Dies ist Teil 1 einer (nie endenden?) Serie von Artikeln über die Indizierung und Suche der ISFDB.org-Daten mit Solr.
Es gibt drei Dinge, die ich schon seit langem tun wollte…
- Erfahren Sie mehr über den DataImportHandler von Solr
- Ein tolles Suchsystem für die ISFDB zu entwickeln (Für die, die es nicht wissen, ich bin eine Art Liebhaber des Sammelns von antiken Sci-Fi-Taschenbüchern und Zeitschriften)
- Schreiben Sie mehr Blogs über Solr
Mein Neujahrsvorsatz für dieses Jahr lautet also, alle drei Dinge gleichzeitig zu tun.
Eines meiner häufigen Ärgernisse bei den meisten technischen Artikeln, die Sie online finden, ist, dass sie entweder zu simpel oder zu vage sind. Autoren, die „den Code zeigen“, verwenden in der Regel triviale, vereinfachte Beispiele, damit der Code in dem Artikel erklärt werden kann, ohne dass er zu einem Roman wird. Autoren, die über „größere“, interessantere Konzepte sprechen wollen, neigen dazu, sich zu verzetteln und entweder den Code nicht zu zeigen oder keine Zeit/Energie zu haben, alles im Detail zu erläutern. In beiden Fällen beschönigen die meisten Autoren die Probleme, auf die sie auf ihrem Weg stoßen, und zeigen nur die fertigen Produkte.
Mein Ziel für dieses Jahr ist es, eine Reihe von Blogbeiträgen zu schreiben, die nicht unter einem dieser Probleme leiden. Ich werde versuchen, jede Woche (oder jede zweite Woche) ein paar Stunden damit zu verbringen, Code zu einem öffentlichen Repository auf Github hinzuzufügen, der dann als Grundlage für einen Artikel dient, den ich in dieser Woche darüber schreibe, wie ich das bestehende Setup in irgendeiner Weise verbessert habe. Sie, der wissbegierige Leser, werden nicht nur den Code hinter jedem Artikel sehen können, sondern auch jeden Commit mitverfolgen und alle individuellen Fortschritte sehen können – mit allen Warzen und allem.
Erste Schritte
In dieser ersten Woche dreht sich alles um Bootstrapping. Unter dem Tag blog_1 finden Sie eine README.txt-Datei, eine recht einfache build.xml-Datei (die von „ant“ verwendet wird) und einige sehr einfache Solr-Konfigurationsdateien zur Indizierung einiger ISFDB-Daten. Wenn Sie das alles selbst ausprobieren möchten, finden Sie in der Datei README.txt eine Anleitung, wie Sie alle ISFDB-Daten abrufen und in Ihren eigenen mysql-Server laden, und wie Sie sie dann mit Solr unter Verwendung der mitgelieferten Konfigurationsdateien indizieren. Wenn Sie Probleme haben oder durch den Prozess verwirrt sind, posten Sie sie bitte hier in den Kommentaren, und ich werde versuchen, die Schritte in zukünftigen Iterationen zu verbessern.
Wie ich bereits erwähnt habe, sind die Solr-Konfigurationen extrem vereinfacht:
- Ein Solr-Dokument für jedes Autor+Titel-Paar (ein Titel in der ISFDB kann ein Roman oder eine Kurzgeschichte usw. sein, aber jeder Titel kann mehrere Autoren haben, und er kann in mehreren Publikationen erschienen sein – um die Publikationen kümmern wir uns später).
- Jede Spalte in der DB wird als Solr-Feld mit einem dynamicField auf „*“ indiziert.
- Alle Solr-Felder verwenden einen einfachen „String“-Feldtyp
In zukünftigen Artikeln werden wir diese Konfigurationen iterativ verbessern, aber zunächst möchte ich auf einige der Probleme hinweisen, auf die ich bei dieser einfachen Einrichtung gestoßen bin – wie ich bereits sagte: Warzen und alles! (Leider habe ich, weil ich die Codebasen ‚gebootstrapt‘ habe, nur ein einziges Mal nach Git übertragen, um alles einzurichten, so dass ich nicht alle Fehler aufzählen kann, die ich gemacht habe.)
- DIH-Konfiguration ist umständlich VooDoo – DataImportHandler verwendet seine eigene Konfigurationsdatei, um das gesamte Verhalten zu steuern, wo alle „Entitäten“ zu finden sind, die Sie indizieren möchten. Es gibt einen offenen Fehler, der darin besteht, dass Sie diese Konfigurationsdatei auf sehr eigenartige Weise spezifizieren müssen (die sich stark von der Funktionsweise der meisten Dinge in Solr unterscheidet), da sie sonst nicht richtig funktioniert. Ich wurde von diesem Bug gebissen, als ich versuchte, meine„config„-Eigenschaft als „invarianten“ Parameter statt als „Standard“ anzugeben (weil ich nicht möchte, dass irgendjemand versucht, sie zur Anfragezeit zu ändern. Das Ergebnis war eine sehr verwirrende Meldung „DataImportHandler started. Nicht initialisiert. Es können keine Befehle ausgeführt werden“, die verschwunden ist, nachdem ich den Fehler entdeckt habe.
- DIH will wirklich einen Primärschlüssel – Solr verlangt nicht, dass Sie ein uniqueKey-Feld haben, Ihr Index kann einfach ein Stapel unstrukturierter Dokumente sein, wenn Sie wollen, und in den Unterlagen des DataImportHandlers steht, dass ein Primärschlüssel optional ist. Als ich jedoch versuchte, meinen Index ohne einen solchen einzurichten, bekam ich einige schmerzhafte RuntimeExceptions beim Versuch, den DIH zu initialisieren.
- MySql ‚0000-00-00‘ Datumsangaben – Die DataImportHandler FAQ hat einen hilfreichen Tipp über den Umgang mit MySql-Datenbanken, die falsche Datumsangaben enthalten, und wie Sie Ihre JDBC-URL an
convertToNull
anpassen können… aber… bevor ich erkannte, dass ich dieses Problem hatte, bekam ich einige wirklich verwirrende Fehler…
… irgendeine Fehlermeldung, was? Glücklicherweise hat der Teil „kann nicht als java.sql.Date dargestellt werden“ in Verbindung mit einem kleinen Stochern in der Datenbank, um den Datensatz für „Meredith Price“ zu inspizieren, dazu geführt, dass mir der Teil „0000-00-00“ ihres Datensatzes ins Auge sprang und ich mich daran erinnerte, dieses Problem in den FAQ gesehen zu haben. Aber ich habe ehrlich gesagt keine Ahnung, warum ein falsches Datum den JDBC-Treiber dazu veranlasst, die gesamte Zeile als ein einziges Datumsobjekt zu interpretieren – glücklicherweise glaube ich nicht, dass dies die Schuld von Solr ist.Update: Ich habe die Fehlermeldung nach dem ersten Posting geändert, um die scherzhaften Nicht-Zeichen durch ‚#‘ zu ersetzen … sie haben die Feed-Reader vor Schmerz weinen lassen.
[java] WARNING: Error reading data
[java] java.sql.SQLException: Value '#2386Meredith Price#######191##0##69Price#2296#2173#2386#1#2173The Dark Angel#####
[java] 0000-00-00#NOVEL##61#0##20#0nk_M._Robinson#4016#http://www.imdb.com/name/nm0732631/#1##177Robinson#2295#2172#1266#1#2172#The Dark Beyond the Stars#####
[java] 1991-07-00#NOVEL6http://en.wikipedia.org/wiki/The_Dark_Beyond_the_Stars#538#0##228#0,http://en.wikipedia.org/wiki/The_Dark_Design#647#0##330#03339#0#8.8#1775#0766#0##370#0les_of_Shadow_Valley#4471137995##181#0' can not be represented as java.sql.Date
[java] at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1075)
Sobald ich diese Probleme überwunden hatte, funktionierte alles sehr gut. Auf meinem Laptop brauchte DIH weniger als 2 Minuten, um die 658842 Dokumente in der Datenbank zu indizieren, und mit dem Schema-Browser kann ich bereits einige interessante Trends in den Daten erkennen(Asimov, Isaac ist überraschenderweise nicht der produktivste Autor in der ISFDB, anscheinend ist es Bleiler, Everett Franklin – aber das liegt offensichtlich daran, dass er bei Tausenden von Titeln anderer Autoren als Redakteur tätig war, und ich habe diese Art von Beziehung nicht ausgeschlossen).
Ok, das war’s für diese Woche … Mein Plan für das nächste Mal ist es, über die iterative Verbesserung des Schemas zu sprechen, aber wer weiß, was mir bis dahin noch alles einfallen wird. Wenn Sie Wünsche oder Fragen haben, schreiben Sie sie bitte in die Kommentare.