Sortierung, Facettierung und Schemadesign in Solr

Vor kurzem habe ich bei einem Kunden eine Bewertung der Best Practices vorgenommen und bin dabei auf eine häufige Quelle…

Vor kurzem habe ich bei einem Kunden eine Bewertung der Best Practices vorgenommen und bin dabei auf eine häufige Quelle der Verwirrung im Zusammenhang mit Sortierung, Facettierung und Schemadesign gestoßen.

Zum Hintergrund: Solr bietet ein Schema, das die Felder und Feldtypen (FT) beschreibt, die von einer Anwendung verwendet werden. Feldtypen beschreiben, wie Solr die in einem Feld enthaltenen Informationen behandeln soll. Der Integer FT weist Solr beispielsweise an, den Inhalt eines Feldes vom Typ Integer als, Sie ahnen es, eine ganze Zahl zu behandeln. Mit Integer meine ich hier die guten alten Java-Ints. Solr bietet weitere FTs wie long, double, float, string, date sowie Text (der mit dem Analyseprozess von Lucene verknüpft werden kann). Außerdem bietet Solr mehrere „sortierbare“ FTs wie sint, slong, sdouble und sfloat. Darin liegt die Verwirrung. Ich glaube, Entwickler hören das Wort „sortierbar“ und denken, dass sie die sortierbare FT für jedes Feld verwenden sollten, nach dem sie die Ergebnisse sortieren möchten. Allerdings gibt es hier einige Feinheiten. Sortierbare“ FTs manipulieren nämlich den Inhalt so, dass die lexikografische Reihenfolge mit der numerischen Reihenfolge für die Suche übereinstimmt. Sortierbare FTs sind also eigentlich für Bereichsabfragen gedacht (z.B. [price:2 TO 100]) und nicht für die Sortierung bei der Rückgabe von Ergebnissen. Aufgrund dieser erforderlichen Änderungen benötigen Sortables mehr Platz im Index (und im Speicher) als ihre nicht sortierbaren Pendants.

Was hat das mit Schemadesign zu tun? Nun, dieser Kunde hatte drei Felder, die alle als sortierbare Ganzzahl-FTs definiert waren, wie in:

1. fieldOriginal – Die Quelle des Inhalts. Dies war das Hauptfeld, das für die Sortierung verwendet wurde
2. fieldSearch – Kopieren Sie das Feld von Original, aber gerundet auf die nächsten 100. Dies war das Hauptfeld für die Suche.
3. fieldFacet – Kopie des Feldes Original, aber gerundet auf der Basis eines Prozentsatzes des Originalwertes, um eine gleitende Skala für die Facettierung zu erhalten. Dies war das Hauptfeld, das für die Facettierung verwendet wurde.

In diesem Fall verwendete der Kunde Original zum Sortieren, Search zum Suchen und Facet zum Facettieren. Es wurden keine Bereichsabfragen durchgeführt, so dass fieldSearch nicht „sortierbar“ sein musste. Außerdem hatte das Feld Original mehr als 1 Million eindeutige Begriffe, so dass die Sortierung einen großen Teil des Speicherplatzes und der Festplatte beanspruchte. Die beiden anderen Felder waren kleiner, so dass die Kosten für die Sortierbarkeit nicht so sehr ins Gewicht fielen. Schließlich wurde dieses Feld-„Muster“ auch für mehrere andere Felder repliziert, von denen einige ebenfalls eine erhebliche Anzahl eindeutiger Begriffe enthielten.

Indem wir die Felder auf Ganzzahlen umgestellt haben, konnten wir den Speicherbedarf und den benötigten Festplattenspeicher in dieser Client-Anwendung erheblich reduzieren.

Achten Sie also, wie immer, auf das Design Ihres Schemas. Das Solr-Beispielschema ist zwar von Haus aus ziemlich gut, aber Sie sollten es auch nicht einfach als Evangelium nehmen. Nehmen Sie sich beim Entwurf etwas Zeit, um über Ihre Bedürfnisse nachzudenken. Das wird Ihnen später beim Debuggen und Testen Ihrer Anwendung viel Zeit ersparen.

**UPDATE**: Beachten Sie, dass diese Änderungen eine Neuindizierung erforderlich machen.