Vorwort: wieso ein Blog zu PHP, Solr und Lucene?

Wieso ein Blog zu PHP, Solr und Lucene?
Gegenstand und Ausgangspunkt all unserer Aktivitäten auf diesem Gebiet war ein Projekt um ein Nachrichtenportal und die Aufgabe, Recherchen und Analysen im Nachrichtenbestand von über 10 Million News performant zu handeln. Die MySQL Volltextsuche kam da schnell an Ihre grenzen, Oracle war keine Alternative.
Es reifte also die Frage, wie können andere (etwa die Internetsuchmaschiene google) immense Datenmengen spielend handeln?
Wir lösten den MySQL volltext mit Lucene ab. Der Performancegewinn war dramatisch. Suchen im Datenbestand, die vorher über 10 Sekunden dauerten, brauchen mittels Lucene und Solr nur selten mehr als 20ms!
Eine neue Welt tat sich auf, die es zu erobern galt und schnell fiel auf, dass deutschsprachige Seiten zum Thema Mangelware sind. Dies soll sich mit diesem Blog ein wenig ändern.

Sie haben Fragen zu Solr/Lucene/PHP? Schreiben sie uns einen Kommentar!

Freitag, 2. November 2012

SolrCloud einrichten / Migration zu SolrCloud

Ergänzend zu diesem Artikel SolrCloud Grundlagen möchte ich nun darauf eingehen, wie wir unsere SolrCloud eingerichtet haben. Betroffen ist unser Solr Archiv Index: 40 GB historische Daten in einigen Millionen Dokumenten, welcher doch recht träge ist. Diesen Solr Index migrieren wir nun zur SolrCloud, wobei wir erstmal mit nur einem Host anfangen. Auf diesem Host laufen dann aber später 3 Shards, also 3 Scheiben eines Solr-Index. Dies alleine bringt einen Geschwindigkeitsgewinn, da der Solr Index nun über 3 CPU kerne skalieren kann, statt wie bisher auf einem Kern fest hängt.


SolrCloud nutzt Apache zookeeper, um die Konfiguration zwischen den einzelnen Shards (Nodes) zu synchronisieren. Download und Installation von Zookeeper ist also einer der ersten Schritte.

Zookeeper

Die Zookeeperinstallation ist trival: Verzeichnis entpacken, bspw. nach /opt/zookeeper und die Konfiguration anpassen:  /opt/zookeeper/conf/zoo.cfg. Wichtig ist dabei der Parameter dataDir: dataDir=/opt/zookeeper/data
Wenn alles soweit passt, können wir den Status checken:
/opt/zookeeper/bin> ./zkServer.sh status

Solr 4

Das ganze funktioniert so, dass wir Solr 4 wie gewohnt auf einem System ablegen. In unserem Beispiel entpacken wir das heruntergeladene Solr 4 File unter /opt/solr4. Das Verzeichnis gilt eher als Vorlage für die nodes/shards und beinhaltet auch die Solr Anwendung, sowie alle notwendigen Bibliotheken.

der erste Shard

Die einzelnen Shards nennen wir, als Freund des Clustering, auch Knoten oder Nodes. Allgemeine Infos zur Bezeichnung und Co gibts hier: SolrCloud Grundlagen
Jeder Node bekommt 1 Verzeichnis unter /opt. Folglich legen wir für den ersten node an:
/opt/node01. Ein Knoten liegt also auf der gleichen Ebene wie Solr4 und der Zookeeper.

Jeder Knoten besteht dabei aus einer Solr Komponente (Konfigurations- und Datenbereich) im Verzeichnis sc01 und einem Tomcat Server (man könnte auch Jetty nehmen, aber wir setzen auf Tomcat, wegen der besseren Unterstützung der Umlaute) im Verzeichnis tc01. Wir legen also noch folgende Unterverzeichnisse an: /opt/node01/sc01 und /opt/node01/tc01.

der erste Shard/Solr Konfiguration

Im Verzeichnis des Shard /opt/node01/sc01 legen wir ein conf Verzeichnis an und befüllen es. Dazu kopieren wir das conf Verzeichnis des Cores, den wir in die Cloud migriren möchten.
/opt/node01/sc01/conf enthält dann die klassischen Solr Konfigurationsdateien: schema.xml, solrconfig.xml, data-import Konfiguration, etc.
Sinnvoll ist die Prüfung der /opt/node01/sc01/conf/solrconfig.xml. Wir haben uns bspw. entschieden für SolrCloud alle Portnummern um 1000 zu erhöhen und nochmals geprüft, ob die solrconfig.xml fit ist für Solr4. Zudem mussten wir den Pfad zur data-config.xml anpassen und zu den Lucene Libs.
Abschließend legen wir unter /opt/node01/sc01/solr.xml die Konfiguration für diesen Shard unseres Archiv-Index:

<?xml version="1.0" encoding="UTF-8" ?>
<solr persistent="true">
  <cores adminPath="/admin/cores" hostPort="9080">
    <core schema="schema.xml" config="solrconfig.xml" instanceDir="archiv/" 
          name="archiv" collection="archiv" shard="shard1"/>
  </cores>
</solr>

der erste Shard/Tomcat Konfiguration

Der Tomcat installiert sich ähnlich einfach wie der zookeeper: auspacken der Anwendung, unter: /opt/node01/tc01/.  Auch hier sind einige Anpassungen notwendig.
Anpassen der Ports in der /opt/node01/tc01/conf/server.xml. Auch hier zählen wir wieder 1000 drauf.
Die Datei /opt/node01/tc01/conf/Catalina/localhost/solr.xml definiert die Anwendung, die im Tomcat laufen soll. Hier verweisen wir auf  die Anwednung in underem Solr4 Verzeichnis. Der Inhalt der solr.xml sieht wie folgt aus:
<?xml version="1.0" encoding="utf-8"?>
<Context docBase="/opt/solr4/dist/apache-solr-4.0.0-BETA.war" debug="0" crossContext="true">
  <Environment name="solr/home" type="java.lang.String" value="/opt/node01/sc01/" override="true"/>
</Context>

Das wars eigentlich schon. Was noch fehlt ist ein Startskript für den Tomcat. Oder um es anders zu sagen: jeder Shard/Node läuft in einer eigenen Applikationsserverumgebung.

der erste Shard/Startskript

Das Startskript des Applikationsservers hat für die SolrCloud eine ganz besondere Bedeutung, denn hier wird die Verbindung zwischen den Solr Konfigurationen und Zookeeper manifestiert.
Wie gesagt gibt es für jeden Shard eine tomcat Instanz und damit ein Startskript. Daher bennen wir unsere Starskripte entsprechend. Für den ersten Node und die erste Tomcat-Instanz wählen wir /etc/init.d/tc01.
Das Startsript ist ein ganz normales runlevel-Skript, welches wir unter /etc/init.d ablegen. Diese differenzieren leicht von einer Linuxdistibution zur anderen. Wichtig und für alle gemeinsam sind aber die Tomcat- und Java-optionen, die zu Beginn des Skriptes definiert werden müssen:

ulimit -v unlimited
export JAVA_HOME=/usr/lib64/jvm/java-1_6_0-ibm-1.6.0/jre/
export JAVA_OPTS="-Xms2048m -Xmx2048m -Dbootstrap_confdir=/opt/node01/sc01/conf/"
export JAVA_OPTS="$JAVA_OPTS -Dcollection.configName=config-archiv"
export JAVA_OPTS="$JAVA_OPTS -DzkHost=myHost.domain:2181 -DhostPort=9081"
export TOMCAT_USER=root
export CATALINA_HOME=/opt/node01/tc01
export CATALINA_PID=$CATALINA_HOME/bin/tomcat6.pid

Hinsichtlich der Parameter sind natürlich die eigenen, passenden Werte zu wählen. Als Erläuterung vielleicht soviel, dass -DzkHost den Host definiert, auf dem der Zookeeper läuft. Und -DhostPort ist der Port, auf dem Solr läuft. Dieser Port wurde bereits weiter oben in der /opt/node01/sc01/solr.xml definiert (Thema: der erste Shard/Solr Konfiguration). In unserem Beispiel also 9080

solrCloud starten

Abschließend den tomcat starten ( /etc/init.d/tc01)  und in der /opt/node01/tc01/logs/catalina.out  prüfen, wie gut es läuft. Dazu hilft ein Blick auf die Webseite, ob der Solr Server läuft: http://myHost.domain:9080/solr.
Die Solr Cloud läuft jetzt. Wenn auch leer und auf nur einem Knoten.Jetzt müssen wir ihn mit Leben füllen.

solrCloud core einrichten

 Nachdem wir oben bereits den ersten shard angelegt haben, geht es nun darum, diesen in die solrCloud einzufügen. Das funktioniert eigentlich ganz einfach durch Aufruf einer Url und entsprechender Parameter.

http://myHost.domain:9080/solr/admin/cores?action=CREATE
                                               &name=archiv
                                               &collection.configName=config-archiv

Der Name wurde bereits in der shard Config angegeben (oben) auch der Name der Konfiguration der Collection wurde bereits genutzt (siehe JAVA_OPTS des tomcat.

Fertig.
...auch wenn es jetzt er richtig losgehen kann, denn solrCloud zeichnet sich gerade dadurch aus, dass ein Lucene/Solr Index über mehrere Instanzen (auch Server-Instanzen) betrieben wird.
Die nächsten Schritte thematisieren also das Hinzufügen weiterer Knoten zur solrCloud. Dazu gibt's dann einen eigenen Artikel.

1 Kommentar:

  1. Hallo,
    ich hab auch grad meine ersten Gehversuche mit SolrCloud hinter mir, aber auch erst mit einer Instanz. Bin gespannt auf deinen nächsten Beitrag.
    Grüße
    JP

    AntwortenLöschen