Lucene/Solr Revolution – Workshop Day 2 – Solr under the hood

Heute war der zweite Tag des “Solr Under the Hood” Kurses. Während ich gestern noch relativ entspannt durch den Kurs bin, gab es heute wirklich kompaktes und konzentriertes tiefes Solr-Wissen. Der Tag begann mit einer Erklärung, wie der Commit Prozess funktioniert, und wieso er den kompletten Solr Server zum Absturz bringen kann.

Merging Strategie

Solr speichert die Daten in sogenannten Segmentfiles auf dem Dateisystem. Dabei erzeugt prinzipiell jeder /update Aufruf ein neues Segmentfile.

Entsprechend einer Merging Strategy, werden diese Segmentfiles dann zusammengeführt, bis wieder ein entsprechender Break Even erreicht ist.

Auf YouTube findet sich das folgende Video, welches recht anschaulich zeigt wie sich die Segmentfiles beim Erzeugen des Wikipedia Index verhalten:

http://www.youtube.com/watch?v=YW0bOvLp72E

Commit Prozess

Grundsätzlich benutzt Solr einen “SearchIndex Searcher” SIS, welcher die aktuellen Segments (seit dem letzten Commit) im JavaHeap hat. Wird nun ein Commit ausgeführt, istanziiert Solr einen neuen SIS, welcher die alten plus die neuen Segments in den Java Heap lädt, den Cache aufwärmt, und sobald sämtliche “Vorwärmprozesse” abgeschlossen sind, den alten mit dem neuen SIS ersetzt. In dem Moment existiert der komplette SIS also zweimal im Java Heap, nur einmal outdatet, was den Garage Collector von Java auf den Plan ruft.

An dieser Stelle kommt es in manchen Setups zum Crash von Solr durch ein Aufstacken des Java Heap. Denn wenn der SIS vor dem Commit bereits 60% vom Heap belegt, hat er mit dem zweiten Instanziieren nicht mehr genügend RAM.

Soft Commits

Neu in Solr 4.x ist das Konzept der Soft Commits. Dabei werden die Updates nicht in die Segmentfiles geschrieben, sondern in die im RAM vorgehaltenen gecachten Segments.

Dadurch sind die Daten fast real time nach der Indizierung durchsuchbar. Solr kümmert sich dann zur Laufzeit in bestimmten Zeitabständen um eine Aktualisierung der Segmentfiles im Dateisystem. Dies hat natürlich zur Folge, das die Daten bei einem Ausfall aus dem Index “verloren” gehen können, ohne das dies bemerkt wird.

Dieses Konzept darf daher nur angewandt werden, falls es keine sicherheitsrelevanten Daten sind.

Performance

Wir wurden dann mit der Aufgabe fürs nächste Lab in die Pause geschickt. Unser Testdatensatz benötigt in etwa 15min zum indizieren. Das neu gewonnen Wissen sollten wir nun dazu nutzen, die Indizierung schneller zu machen. Ich habe zwei Setups probiert. Erstens habe ich für beide Tests den Java Heap Size erhöht, und zweitens eine Softcommit Strategie eingestellt. Nun habe ich einmal per threaded post.jar jeweils 4 Therads gleichzeitig gestartet welche meine Testdaten indizieren sollten, und einmal eine Singlethreading Strategie gewählt. Durch das Multithreading konnte ich die Indizierungszeit von 15min auf unter 50%, und zwar 6min reduzieren. Interessanterweise war die Indizierungszeit für die Singlethreadstrategie nochmals geringer und zwar nur 4min, obwohl hier eigentlich ein Vorteil für die Multithreadingstrategie zu erwarten war.

Replikation

Nach der Mittagspause ging es dann mit Replikation weiter. Eine sehr einfache und robuste Replikation wird durch den Einsatz eines Loadbalancers und einem simplen Master Slave Setup hergestellt.

Im Prinzip geschieht nicht viel mehr, als das der Slave sich vom Master immer die aktuellsten Segmentfiles geben lässt, und so immer auf dem neusten Stand ist. Das setzt natürlich voraus, das Updateprozesse nur auf dem Slave geschrieben werden, und Leseprozesse von dem Loadbalancer an alle Solr-Server verteilt werden.

Sharding

Eine weitere Möglichkeit der Replikation sind Shards. Shards enthalten nur eine Teilmenge der indizierten Daten, zum Beispiel nach Dokumentenid MODULO Anzahl Shards verteilt. Um jetzt eine Suchanfrage stellen zu können, muss man in das Query die betreffenden Shards mit aufnehmen. Bei der erwähnten Shardingstrategie wären das natürlich alle Shards. Auf Harding wird zurückgegriffen, wenn die Datenmenge für einen einzelnen Index zu gross wird. Teile der mächtigen Strategien von Solr funktionieren auf Shards nicht, was in Kauf genommen wird da das gelöste Problem – Performance – einfach schwerer wiegt.

SolrCloud

Zum Schluss des Tages gab es noch das i-Tüpfelchen. Quasi das, was in den letzten 18 Monaten entwickelt wurde. Die SolrCloud.

Bei der SolrCloud gibt der Administrator sämtliche Konfigurationsgewalt über Solr an ein Koordinationsframework für Infrastruktur wie zum Beispiel ZooKeeper ab.

Der Administrator “registriert” bei ZooKeeper lediglich einen frischen leeren SolrServer. ZooKeeper kümmert sich um die Konfiguration, Replikation, und ggf. auch Probleme wie Servercrashs.

ZooKeeper verwendet dabei eine Shardingstrategie. Der Einsatz macht in meinen Augen nur in grossen Umgebungen Sinn, wo eine einzelne Solr-Instanz nicht mehr ausreicht.

Split Shards

Ein grosser Nachteil bei der Verwendung von Shards ist, das die Frage “was passiert wenn ich einen neuen Shard brauche, weil mein Index zu gros wird?” in der aktuellen Solr Version nicht befriedigend beantwortet werden kann. Da die Daten gemäss einer eindeutigen Strategie auf die Shards verteilt werden, muss der Index konsequenterweise komplett neu aufgebaut werden. Naturgemäss kommt Harding nur sinnvoll bei sehr grossen Datenmengen in Frage, wodurch Indizierungszeiten von mehreren Stunden wenn nicht Tagen keine Seltenheit darstellen. Bei einem Produktivsystem, welches bereits an der Grenze seiner Leistungskapazität läuft, also keine einfach Aufgabe. In Solr 4.3 ist dieses Problem laut https://issues.apache.org/jira/browse/SOLR-3755 gelöst. Shards können dann von Solr selber zur Laufzeit gesplittet werden.

Ausblick

Morgen ist dann also der erste Tag der Konferenz. Ich bin gespannt, das Programm verspricht einige sehr interessante Vorträge.