Was hat es mit der Kleinschreibung von Wildcard-Abfragen (Multiterm) in Solr auf sich?

Wildcard-Abfragebegriffe werden nicht analysiert, warum?

Vor dem aktuellen 3x-Zweig (der als 3.6 veröffentlicht wird) und dem Solr-Stammcode (4.0) waren die Benutzer häufig verwirrt, weil die Platzhaltersuche nicht analysiert wurde, was sich oft in der Groß- und Kleinschreibung zeigte. Angenommen, Sie haben eine Analysekette in Ihrer schema.xml-Datei, die wie folgt definiert ist, und ein Feld dieses Typs mit dem Namen lc_field:

<fieldType name="lowercase" class="solr.TextField" >
  <tokenizer class="solr.WhitespaceTokenizerFactory"/>
  <filter class="solr.LowercaseFilterFactory" />
</fieldType>

Jetzt indexieren Sie den Text „Mein Hund hat Flöhe“. So weit, so gut. Die Suche in diesem Feld als
field_lc:fleas gibt das Dokument zurück, ebenso wie field_lc:flea*.

Aber jetzt suchen Sie auf field_lc:Flea* und erhalten keine Ergebnisse. Was?!?!?! Fast jeder kratzt sich darüber den Kopf, und es ist eine Frage, die oft auf der Liste der Solr-Benutzer auftaucht. Die Benutzer fragen sich, warum die obige Analysekette nicht auf die Wildcard-Abfragen angewendet wird. Es stellt sich heraus, dass die Sache komplizierter ist, als Sie vielleicht zunächst denken. Was passiert, wenn ein einzelner Eingabebegriff in mehrere Teile aufgeteilt wird? Zum Beispiel für diejenigen unter Ihnen, die mit WordDelimiterFilterFactory (WDFF) vertraut sind, die bei einem Wechsel der Groß-/Kleinschreibung aufteilen kann. Was bedeutet es, ‚fleA*‘ zu parsen? Die Anwendung von WDFF könnte durchaus die beiden Token ‚fle‘ und ‚A‘ und möglicherweise ‚fleA‘ ergeben. Wenn ein Platzhalter vorhanden ist, welche Token sollten dann ausgegeben werden?

1. 1. ‚fleA*‘
   2. ‚fle*‘, ‚A*‘, ‚fleA*‘
   3. ‚fle*‘, ‚A*‘
   4. <Ihre Lösung hier einfügen>

Sie können, so wage ich zu behaupten, jede beliebige Regel aufstellen, die Ihnen in den Sinn kommt. Und sie wird in manchen Situationen falsch sein. Besonders erschreckend ist alles, was wie oben ‚A*‘ ergibt. Dann hätten Sie eine riesige ODER-Klausel, die aus allen Begriffen besteht, die mit ‚A‘ in Ihrem Index beginnen. Es sei denn, Sie hätten eine Regel wie „Dies nur tun, wenn das vorangegangene Fragment 2 Zeichen oder mehr war“. Aber dann würde jemand sagen: „Ich brauche drei Zeichen“. Kann WDFF also einen Parameter „wildCardMin=#“ bereitstellen? Ich habe schon jetzt Schwierigkeiten, mir alle Parameter von WDFF und ihr Zusammenspiel zu merken, diesen Weg einzuschlagen wäre ein Alptraum. Und ich habe noch nicht einmal über einige der wirklich interessanten Fragen nachgedacht, wie z.B. die Frage, wie die Nähe in all das einbezogen werden kann.

Wildcards sind nicht das einzige Problem

Das gleiche Problem tritt bei der Akzentfaltung, bei Normalisierungen und eigentlich bei jeder anderen Komponente einer Analysekette auf, die die Abfragebegriffe irgendwie verändert. In der Vergangenheit wurde dieses Verhalten in den meisten Fällen ignoriert. Es war Sache des Anwendungsprogrammierers, manuell „das Richtige zu tun“, bevor er die Abfrage an Solr sendet. Dies beinhaltet oft Operationen wie die Kleinschreibung und das Falten von Akzenten auf der Anwendungsseite, wenn ein Platzhalter gefunden wird.

Die neue Art der Bearbeitung dieser Fälle

Ab SOLR-2438 ist dieses Verhalten für einige der häufigsten Fälle nicht mehr zutreffend. Eine Abfrageanalysekette, die eine der folgenden Komponenten enthält, wird automatisch „das Richtige tun“ und sie auf Abfragen mit mehreren Begriffen anwenden. Wenn Ihre Analysekette aus einem dieser Elemente besteht und Sie möchten, dass diese auf „Multi-Term“-Abfragen angewendet werden, müssen Sie überhaupt nichts tun, es wird „einfach funktionieren“. Zur Abfragezeit werden die angegebenen Transformationen auf die Abfragebegriffe angewandt und alle sind zufrieden. Oder sollten es sein. Beachten Sie bitte, dass es sich um eine Alles-oder-Nichts-Operation handelt. Alle unten aufgeführten Elemente, die in der Abfrageanalysekette zu finden sind, werden auf die Multi-Term-Terme angewendet (Solr 3.6+)

• • ASCIIFoldingFilterFactory
  • LowerCaseFilterFactory
  • LowerCaseTokenizerFactory
  • MappingCharFilterFactory
  • PersianCharFilterFactory

Außerdem wurden in der Version 4.0 von Solr weitere Filter hinzugefügt, die Liste finden Sie unten. HINWEIS: Diese Liste ist aktuell (Stand: Oktober 2012). Es können noch weitere hinzugefügt werden! Im Zweifelsfall sehen Sie sich die Klassendefinition Ihrer bevorzugten FilterFactory an und prüfen Sie, ob sie als „… implements MultiTermAwareComponent“ deklariert ist.

• • ASCIIFoldingFilterFactory
  • ArabicNormalizationFilterFactory
  • CJKWidthFilterFactory
  • CollationKeyFilterFactory
  • ElisionFilterFactory
  • GermanNormalizationFilterFactory
  • GreekLowerCaseFilterFactory
  • HindiNormalizationFilterFactory
  • ICUCollationKeyFilterFactory
  • ICUFoldingFilterFactory
  • ICUNormalizer2FilterFactory
  • ICUTransformFilterFactory
  • IndicNormalizationFilterFactory
  • IrishLowerCaseFilterFactory
  • JapaneseIterationMarkCharFilterFactory
  • LowerCaseFilterFactory
  • MappingCharFilterFactory
  • PersianCharFilterFactory
  • PersianNormalizationFilterFactory
  • TurkishLowerCaseFilterFactory

Das bedeutet wiederum, dass Sie sich nicht mehr um diese Umwandlungen kümmern müssen. Noch eine Anmerkung zur Erklärung. Ich habe über die „Abfrageanalysekette“ gesprochen. Aber was ist, wenn Sie keine haben? Erinnern Sie sich daran, dass Ihr <analyzer>Tag mehrere mögliche ‚type‘ Parameter haben kann: „index“, „query“ oder keinen. Nun, wenn ein ‚ type=“query“ ‚ gefunden wird, wird diese Analysekette untersucht und jede der oben genannten Komponenten wird aufgezeichnet, um bei Abfragen mit mehreren Begriffen verwendet zu werden. Wenn kein ‚ type=“query“ ‚ gefunden wird, dann wird der ‚ type=“index“ ‚ verwendet. Und wenn kein ‚ type=“index“ ‚ gefunden wird, dann wird derjenige ohne den Parameter ‚type‘ verwendet.

Was bedeutet eigentlich „Multi-Term“?

Ich habe auch den Ausdruck „Mult-Term“ und manchmal „Wildcard“ verwendet. Es hat sich herausgestellt, dass der einfache Wildcard-Fall eine Spezialisierung einer breiteren Kategorie von Abfragen ist, einschließlich:

• • Platzhalter
  • Reichweite
  • Präfix

All dies wird nun wie oben beschrieben gehandhabt.

Schemamöglichkeiten auf Expertenebene

All dies geschieht automatisch, aber es gibt drei unmittelbare Fragen:

• • Was ist mit den anderen Komponenten?
  • Was ist, wenn ich das alte Verhalten brauche?
  • Was ist, wenn ich etwas ganz anderes möchte?

Es stellt sich heraus, dass alle drei dieser Fragen dieselbe Antwort haben. Doch bevor ich sie skizziere, möchte ich betonen, dass Sie sich sehr wahrscheinlich nicht um das kümmern müssen, was folgt! In besonderen Fällen könnten Sie das wissen müssen, deshalb erwähne ich es hier.

In den obigen Erklärungen habe ich geschrieben, dass „die Analysekette überprüft wird und jede der oben genannten Komponenten aufgezeichnet wird, um bei Abfragen mit mehreren Begriffen verwendet zu werden“. Nun, in Wirklichkeit gibt es eine neue Analysekette, die in der Datei schema.xml angegeben werden kann und die, Sie ahnen es, „multiterm“ heißt. Sie geben sie wie folgt als Teil einer <fieldType> an:

<analyzer type="multiterm" >
  <tokenizer class="solr.WhitespaceTokenizerFactory"/>
  <filter class="solr.ASCIIFoldingFilterFactory" />
  <filter class="solr.YourFavoriteFilterFactoryHere" />
</analyzer>

Sie können jede Komponente, die zulässig ist, in eine ‚type=“index“ ‚ oder ‚type=“query“ ‚ Analysekette einfügen. Wenn Sie zum Beispiel das Verhalten im alten Stil erzwingen möchten, können Sie Folgendes angeben

  <tokenizer class="solr.KeywordTokenizerFactory" />

als die gesamte „Multiterm“-Analysekette. Es erscheint etwas seltsam, hier KeywordTokenizerFactory zu verwenden, aber dies gilt für die einzelnen Terme, nicht für die gesamte Eingabe. Es bedeutet also, dass die Terme gar nicht analysiert werden sollen. Kommt Ihnen das bekannt vor? Das ist genau das, was in der Vergangenheit passiert ist.

Was hat dies mit dem automatischen Verhalten zu tun?

Wenn Sie keine eigene „Multiterm“-Analysekette definieren, konstruiert Solr eine für Sie aus den Analysatoren, die Sie wie oben beschrieben definiert haben: Abfrage, Index oder Standard, in dieser Reihenfolge.

Weit unter der Bettdecke, unten im Code

All dies wird erreicht, indem Komponenten „multitermfähig“ gemacht werden. Das bedeutet, dass sie die Schnittstelle „MultiTermAwareComponent“ implementieren. Derzeit sind die oben aufgeführten Komponenten die einzigen, die diese Schnittstelle implementieren, aber andere könnten gute Kandidaten sein, und einige von ihnen sind in JIRA SOLR-2921 aufgeführt. Im Großen und Ganzen dürfte es trivial sein, diese in den Code zu implementieren. Was nicht trivial ist, ist zu verstehen, was „das Richtige“ ist. Einige Beispiele:

• • Stemmers
  • verschiedene sprachspezifische Normalisierungsfilter
  • verschiedene sprachspezifische Filter für Kleinbuchstaben.
  • verschiedene ICU-Filter

Der Grund dafür, dass diese nicht „multi term aware“ gemacht wurden, ist der übliche Open-Source-Grund: „Was wir haben, ist ein guter Schritt nach vorne, wir sollten nicht alles aufschieben, um die letzten Anwendungsfälle zu erledigen“. Mit anderen Worten, die Implementierer (in diesem Fall ich, mit viel Hilfe von anderen) sind müde ;).

Jeder, der wirklich weiß, was in den Fällen von Komponenten, die „MultiTermAwareComponent“ noch nicht implementiert haben, zu tun ist, und der Anwendungsfälle für diese Komponenten liefern könnte, würde uns eine große Hilfe sein, insbesondere durch Beispiele, die die korrekten Ein- und Ausgaben für Platzhalterfälle illustrieren. Und auch einige Beispiele dafür, was nicht ausgegeben werden sollte. Oder noch besser, einen Entwurf eines JUnit-Tests, der das erwartete Verhalten zeigt. Oder noch besser, ein vollständiger Patch!

Jede Änderung, die potenziell mehr als ein Token erzeugt, muss mit Vorsicht gehandhabt werden. Ein Beispiel hierfür ist der Code für LowerCaseTokenizerFactory. Bedenken Sie, dass Solr jetzt eine Ausnahme auslöst, wenn die Transformation mehr als ein Token erzeugt, also seien Sie vorsichtig!

Diese Änderung sollte einen langjährigen Punkt der Verwirrung für Solr-Benutzer beseitigen. Wir sind an jeglichem Feedback aus der Community sehr interessiert, insbesondere an Problemen, die auftauchen. SOLR-2438 enthält Patches für die 3x- und 4x-Codezeilen, aber es ist wahrscheinlich einfacher, sich einen aktuellen 3x- oder 4x-Zweig (oder ein Nightly-Build) zu besorgen, wenn Sie diese Änderung „in freier Wildbahn“ testen möchten. Es bleibt noch einiges zu tun, um diese Änderung für weitere Analysekomponenten einzubauen.

Ressourcen:

Diese Seite im Solr-Wiki enthält die Wiki-Dokumentation: Analyse von Mehrbegriffsabfragen

Haupt-JIRA (bereits in 3.6 und 4.0 Codezeilen): SOLR-2438

JIRA für andere Komponenten, die noch nicht „Multi-Term-fähig“ sind, aber in Zukunft möglich sein werden: SOLR-2921