Schema vs. Schemaless vs. Managed Schema

Schema vs. Schemaless vs. Managed Schema – „Was ist was?“ und „Was passt am besten zu meiner Suche?“

Für eine gute Suche ist die Qualität des Indexes extrem wichtig. Die Qualität des Index setzt sich zum einem aus der Datenqualität und zum anderen aus der Verarbeitung der Daten während der Indexierung bzw. Suche zusammen. Diese Verarbeitung wird Analyse genannt. In dieser Analyse können beispielsweise Stopp-Wörter entfernt, Synonymersetzungen oder sprachabhängiges Stemming durchgeführt werden. Dies ist für eine gute Suche essentiell wichtig.
In Apache Solr gibt es mehrere Möglichkeiten diese Analyse zu beschreiben bzw. zu beeinflussen. In diesem Blog werde ich die einzelnen Möglichkeiten aufzeigen und die Vor- und Nachteile gegenüberstellen.

Die „schema.xml“

Die erste Variante ist zugleich auch die älteste. Schon seit Ewigkeiten wird das Datenmodell in der schema.xml beschrieben. Die Hauptbestandteile in der schema.xml sind die einzelnen Feld- bzw. Typ-Definitionen. Das nachfolgende Beispiel zeigt eine einfache Definition des Feldes „title“ und dessen Typbeschreibung „text_de“.

<field name="title" type="text_de" indexed="true" stored="true" />
<fieldType name="text_de" class="solr.TextField"
    positionIncrementGap="100">
    <analyzer>
           <tokenizer class="solr.StandardTokenizerFactory"/>
           <filter class="solr.LowerCaseFilterFactory"/>
           <filter class="solr.StopFilterFactory" ignoreCase="true"
                words="lang/stopwords_de.txt" format="snowball"
                enablePositionIncrements="true"/>
           <filter class="solr.GermanLightStemFilterFactory"/>
    </analyzer>
</fieldType>

Vorteile:

• Man kann jedes Feld separat definieren, um das Bestmögliche für die Suche herauszuholen.
• Mit „dynamicField“ Definitionen können gleichartige Felder über Präfixe bzw. Suffix definiert werden, wodurch der Aufwand bei der Pflege der schema.xml geringer wird.

Nachteile:

• Möchte man etwas am Datenmodell bzw. Schema ändern, muss immer die Datei schema.xml editiert werden.
• Änderungen an der schema.xml benötigen immer einen Core Reload, was zu Performanceeinbußen bei der Indexierung/suche führen kann.
• Im SolrCloud Modus muss jede Änderung über die ZooKeeper CLI bekannt gemacht werden.

Der „Schemaless“ Modus

Seid der Version 4.4 gibt es Apache Solr den sogenannten Schemaless-Modus. (Siehe Blogbeitrag https://www.shi-gmbh.com/blog/2013/solr-ist-schemaless). Dieser Modus wurde eingeführt, da es in der Community immer wieder den Wunsch gab, den Aufwand bei der Pflege der schema.xml zu verringern bzw. komplett zu entfernen.
Bei diesem Modus muss man als Anwender nicht erst die schema.xml Datei konfigurieren um neue bzw. unbekannte Felder zu indexieren. Apache Solr übernimmt während der Indexierung die automatische Erkennung um was für Inhalte es sich handelt und vergibt dementsprechend die Feldtypen, wie beispielsweise Datum, Zahl oder Text.
Der nachfolgende Konfigurationsauszug aus der solrconfig.xml zeigt, wie Apache Solr versucht für jedes Feld während der Indexierung festzulegen, um welchen Typ es sich hierbei handelt.

<updateRequestProcessorChain name="add-unknown-fields-to-the-schema">
    <processor class="solr.RemoveBlankFieldUpdateProcessorFactory"/>
    <processor class="solr.ParseBooleanFieldUpdateProcessorFactory"/>
    <processor class="solr.ParseLongFieldUpdateProcessorFactory"/>
    <processor class="solr.ParseDoubleFieldUpdateProcessorFactory"/>
    <processor class="solr.ParseDateFieldUpdateProcessorFactory">
            <arr name="format">
                  <str>yyyy-MM-dd</str>
                   ...
            </arr>
    </processor>
     ...
</updateRequestProcessorChain>

Vorteile:

• Es gibt keinen initialen Konfigurationsaufwand. Man kann Solr herunterladen und sofort mit der Indexierung loslegen.

Nachteile:

• Der Mechanismus zum Bestimmen der Feldtypen kann fehlschlagen so dass die Indexierung irgendwann mit einem Fehler abbrechen wird.
• Für Volltext-Felder gibt es keine automatische Erkennung, d.h. es wird beispielsweise nicht zwischen deutschen und englischen Texten unterschieden.

Das „Managed Schema“

Mit Apache Solr 5 wurde eine weitere Art eingeführt, wie das Solr Schema manipuliert werden kann. Der grundlegende Gedanke ist, die bisherige schema.xml SolrCloud-fähig zu machen und die Möglichkeit zu schaffen das Schema während der Laufzeit zu manipulieren.
Dieser Modus besitzt eine ausgereifte API mit der man über einfache URL-Aufrufe das Schema ändern oder einfach nur Informationen aus dem Schema herauslesen kann. Initial wird bei dieser Variante die schema.xml zwar verarbeitet, jedoch werden die Informationen nun als JSON Objekte persistiert, was die Synchronisation mit anderen Indexen innerhalb eine SolrCloud vereinfacht.
Der folgende Ausschnitt der solrconfig.xml zeigt, wie man das Managed Schema aktiviert.

<schemaFactory class="ManagedIndexSchemaFactory">
      <bool name="mutable">true</bool>
      <str name="managedSchemaResourceName">managed-schema</str>
</schemaFactory>

Vorteile:

• Man kann jedes Feld separat definieren, um das Bestmögliche für die Suche herauszuholen.
• Mit „dynamicField“ Definitionen können gleichartige Felder über Präfixe bzw. Suffix definiert werden, wodurch der Aufwand bei der Pflege der schema.xml geringer wird.
• Felder und Definitionen können zur Laufzeit von Solr verändert, gelöscht und hinzugefügt werden.

Nachteile:

• Die schema.xml wird umbenannt und nicht mehr benötigt. Ein hybrider Ansatz (API Nutzung und schema.xml) ist nicht möglich.

Weiterführende Informationen

Was nutze ich wann???

• Schema – https://cwiki.apache.org/confluence/display/solr/Documents%2C+Fields%2C+and+Schema+Design
• Schemaless – https://cwiki.apache.org/confluence/display/solr/Schemaless+Mode
• Schema API – https://cwiki.apache.org/confluence/display/solr/Schema+API

Obwohl ich in diesem Blog drei verschiedene Arten beschrieben habe gibt es am Ende doch nur 2 grundlegende Modelle. Ein Model mit ausspezifizierten Datenmodell (Schema) und ein Modell, bei dem Apache Solr die Aufgabe übernimmt das Schema zu spezifizieren.
Diese zweite Variante nutzen wir nur im Rahmen von POCs oder für schnelle Tests, wo es darum geht grundlegend zu zeigen, wie etwas funktioniert. Dies spart – vor allem beim initialen Setup – enorm viel Zeit. Eine qualitativ hochwertige Suche lässt sich mit dieser Variante jedoch nicht umsetzten, da wir im Rahmen unserer Projekte immer wieder für bestimmte Felder andere Analysen definieren müssen um den Anforderungen gerecht zu werden.
Dies lässt sich nur mit einem Schema machen, welches unter der Kontrolle von den Applikations-Entwicklern ist. Es eignen sich hierfür also Varianten eins und drei. Mit der Schema API wurde nun eine Schnittstelle eingeführt um flexibler und schneller auf das Schema eingehen zu können, vor allem, wenn man eine SolrCloud betreibt. Diese Variante ist daher mein Favorit unter den aktuellen Möglichkeiten ein Schema zu erstellen bzw. zu pflegen.