Einblick: Unsere Solr Implementation in der Praxis

Was realisieren wir mit Solr / Lucene?

Wie nutzen wir Solr / Lucene?

Alle der hier im Blog angesprochenen Punkt beziehen sich auf ein konkretes System im produktiven Umfeld.
Um nicht redundant die Referenzarchitektur darzustellen, möchte ich in diesem Post kurz erläutern, wie unsere Solr Welt geschaffen ist. Dies ist sicher für einige Leser interessant:

1. um abzuwägen, wie vergleichbar die hier erläuterten Probleme und Lösungen mit dem eigenen Projekt sind, 
2. um zu erkennen, warum wir manches so machen, wie wir es machen und
3. um einen Einblick zu geben wie ein fremdes System aussieht, dass intensiv auf Solr / Lucene setzt.

Los geht's:

Der Wechsel zu Solr / Lucene

Die Anwendung, über die wir hier im Blog sprechen, ist ein Nachrichtenportal.
Verarbeitet werden 2 Typen von Nachrichten:

1. eigene Nachrichten mit Metainformationen und gesamten News-Volltext sowie
2.  Nachrichten von Dritten, wobei wir lediglich Metainformationen und Links zum Volltext verarbeiten.

Für jeden Nachrichtentyp gibt es eine MySQL Tabelle als Datenspeicher, in der Nachrichten mehrere Monate gespeichert werden.

Zusätzlich existiert noch eine Archivtabelle, welche von beiden Nachrichtentypen gespeist wird.
Daten in der Archivtabelle werden nicht gelöscht und reichen derzeit 21 Jahre zurück.

Ursprünglich kam lediglich die MySQL Volltextsuche zum Einsatz. Dabei war es kein Problem in hundert- oder zweihunderttausend Nachrichten zu suchen. Das Ergebnis war binnen 5 Sekunden da.
Allerdings stießen wir bald auf 2 grundsätzliche Probleme:

1. MySQL Volltextsuchen sind für gute Ergebnisse nicht leistungsstark/funktional genug: es gibt  keine Wortstammbildung, kein Ergebnisboosting, keine Synonymverarbeitung, etc. und vor allem keine Relevanzsortierung. Mit steigender Zahl an Dokumenten wurden die Suchergebnisse unbrauchbarer.
   
2. MySQL Volltexsuche war dem ansteigenden Datenbestand nicht gewachsen: die Suche in 400.000 Meldungen dauerte schon 20 Sekunden und mehr. Da wird der Anwender ungeduldig.

Aus diesem Grund mussten andere Technologien zum Einsatz kommen und die Wahl fiel auf Solr und Lucene, was einen dramatische Verbesserung in der Qualität der Suchergebnisse brachte und das bei einer durchschnittlich 1000fach schnelleren Suche.


Die Migration von MySQL Volltext auf Solr / Lucene war, für die Suchfunktion der Anwendung, die bisher gravierenste und beste Entscheidung.

Struktur von Solr

Diese Struktur an MySQL Tabellen (für jeden Typ an Nachrichten eine Tabelle) wurde auch für Solr / Lucene übernommen.
Für jede MySQL Tabelle gibt es eine Solr / Lucene Kern (= Core). Das ist nicht zwingend notwendig, bietet sich aber in unserem Fall an, da die Anwendung ebenfalls differenziert.


In der Folge dessen gibt es 3 Solr Cores:
1.) Nachrichten, die nur Metainformationen und einen Link zu Drittanbietern enthalten - der kleinste und schnellste Core mit ca. 1 Million Meldungen. Wachstum ca. 4000 Dokumente täglich.
2.) Nachrichten, die uns als Volltexte vorliegen samt deren Metainformationen - knapp 1 Million News, allerdings deutlich größer als der 1. Core und damit auch langsamer. Wachstum ca. 3000 Dokumente täglich und
3.) der Archivcore mit ca. 10 Millionen News/Dokumenten - das Schwergewicht mit einem Wachstum von ca. 7000 News täglich.

Die Aufteilung in mehrere Cores ermöglicht eine bessere Skalierung und Spezialisierung. Allerdings ist eine Suche über den gesamten Datenbestand (alle Cores) problematisch. In unserem Fall allerdings unkritisch, da Core Nr. 3 als Archiv alle Daten aus Core 1 und Core 2 enthält.

Die 3 Cores sind in einer Solr Instanz vereint, welche in nur einem Java Server (tomcat) läuft. So können bestimmte Ressourcen geshared werden und dennoch ist jeder Kern dediziert konfigurierbar.
Wir haben uns bewusst dafür entschieden, nicht die out-of-the-Box Solr/Lucene Variante von der Solr Webseite zu nehmen. Der Tomcat ließ sich besser für die Nutzung deutscher Umlaute konfigurieren und man kommt nicht in die Versuchung  "per default" diverse Extension (Carrot Clustering, MLT, ....) mitzustarten, nur weil Sie schon dabei sind, aber vielleicht gar nicht benötigt werden.

Hardware / Hardwareanforderung für Solr / Lucene

Nach wie vor läuft unsere Solr / Lucene Umgebung auf einer VM in einem ESX Cluster. Die MySQL DB haben wir einfach auf diesem System belassen. Anfangs noch mit 4 GB RAM, bei einer Indexgröße von ca. 4 GB.
Im Laufe der Zeit wuchs der Datenbestand und die Indexgröße auf 44 GB. Wir haben uns davon verabschiedet, dass der RAM des Tomcat / Solr gleich der Größe des Index sein soll. Das kann man irgendwann nicht mehr (günstig) realisieren und ... wie wir feststellten ... ist es auch gar nicht notwendig.
Bei 44 GB Indexgröße läuft unser System nun mit 16 GB RAM.
Der Wechsel von 4 auf 16 GB Ram ist allerdings (auch) dadurch begründet, dass die Nutzerzahlen stark gestiegen sind, ebenso die Funktionen, die wir zu Solr auslagerten.
Bei den CPU's laufen wir in der VM weiterhin auf 2 Kernen, die eigentlich nur während eines Index-Neuaufbau dauerhaft am Anschlag sind. Eine Erweiterung auf 4 Kerne brachte nur moderaten Perfromancegewinn bei der Skalierung. Offensichtlich skaliert Solr / Lucene schlecht über viele Kerne.