Solr 4.3: Shard-Splitting – Ein kurzer Blick
Dank an Rafał Kuć von Solr.pl für diesen Beitrag. Mit der Veröffentlichung von Solr 4.3 haben wir eine lang erwartete…
Dank an Rafał Kuć von Solr.pl für diesen Beitrag.
Mit der Veröffentlichung von Solr 4.3 haben wir eine lang erwartete Funktion erhalten – wir können jetzt Shards von Sammlungen aufteilen, die bereits erstellt wurden und über Daten verfügen (in einer SolrCloud-artigen Bereitstellung). In diesem Beitrag möchten wir diese Funktion ausprobieren und sehen, wie sie funktioniert.
Also los geht’s.
Ein paar Worte, bevor wir es versuchen
Die Wahl der richtigen Anzahl von Shards, die eine Sammlung haben sollte, ist eine der Variablen, die vor der endgültigen Bereitstellung bekannt sein muss. Bisher konnten wir nach der Erstellung einer Sammlung die Anzahl der Shards nicht ändern, sondern nur weitere Replikate hinzufügen. Das hatte natürlich Konsequenzen – wenn wir die falsche Anzahl von Shards gewählt haben, konnten wir am Ende zu wenige Shards haben und der einzige Ausweg bestand darin, eine neue Sammlung mit der richtigen Anzahl von Shards zu erstellen und dann unsere Daten neu zu indizieren. Mit der Veröffentlichung von Apache Solr 4.3 sind wir nun in der Lage, die Shards in unseren Sammlungen aufzuteilen.
Kleiner Cluster
Um die neue Shard-Splitting-Funktionalität zu testen, habe ich beschlossen, einen kleinen und einfachen Cluster mit einer einzigen Solr-Instanz und dem eingebetteten ZooKeeper zu betreiben und die mit Solr gelieferte Beispielsammlung zu verwenden. Zu diesem Zweck habe ich den folgenden Befehl ausgeführt:
[code language=“XML“]
java -Dbootstrap_confdir=./solr/collection1/conf -Dcollection.configName=collection1 -DzkRun -DnumShards=1 -DmaxShardsPerNode=2 -DreplicationFactor=1 -jar start.jar
[/code]
Nach dem Start des Mini-Clusters sah die Ansicht wie folgt aus:
Test Daten
Wie üblich benötigen wir einige Daten für Tests und ich habe mich für die Beispieldaten entschieden, die mit Solr bereitgestellt werden. Um sie zu indizieren, habe ich den folgenden Befehl im Verzeichnis exampledocs ausgeführt:
[code language=“XML“]
java -jar post.jar *.xml
[/code]
Die Anzahl der indizierten Dokumente wurde mit dem folgenden Befehl überprüft:
[code language=“XML“]
curl ‚http://localhost:8983/solr/collection1/select?q=*:*&rows=0‘
[/code]
Die von Solr zurückgegebene Antwort lautete wie folgt:
[code language=“XML“]
<?xml version=“1.0″ encoding=“UTF-8″?>
<response>
<lst name=“responseHeader“>
</lst>
<result name=“response“ numFound=“32″ start=“0″>
</result>
</response>
[/code]
Wie Sie sehen können, haben wir 32 Dokumente in unserer Sammlung.
Splitterteilung
Lassen Sie uns nun versuchen, den einzelnen Shard, aus dem unsere Sammlung besteht, aufzuteilen. Dazu verwenden wir die Collections API und eine neue Aktion – SPLITSHARD. In ihrer einfachsten Form benötigt sie zwei Parameter – collection ist der Name der Sammlung, die wir aufteilen möchten, und shard ist der Name des Shards, den wir aufteilen möchten. In unserem Fall sieht der Befehl, der den Shard aufteilt, also wie folgt aus:
[code language=“XML“]
curl ‚http://localhost:8983/solr/admin/collections?action=SPLITSHARD&collection=collection1&shard=shard1‘
[/code]
Wenn alles ohne Probleme läuft, erhalten wir nach ein paar Sekunden eine Antwort von Solr, die das Ende des Prozesses anzeigt. Die Antwort wird in etwa so aussehen:
[code language=“XML“]
<?xml version=“1.0″ encoding=“UTF-8″?>
<response>
<lst name=“responseHeader“>
</lst>
<lst name=“success“>
</lst>
</response>
[/code]
Cluster nach der Aufteilung
Nach der Aufteilung sieht unsere Clusteransicht wie folgt aus:
Wie wir sehen, haben wir jetzt zwei neue Shards. Theoretisch sollte jeder der neuen Shards einen Teil der Dokumente aus dem ursprünglichen Shard1 enthalten – einige der Dokumente sollten in Shard1_1 und einige in Shard1_0 abgelegt werden. Wiederum über das Solr-Verwaltungspanel können wir jeden der Cores (die eigentlichen Shards) überprüfen:
Scherbe1_1
Die Statistiken für den Shard mit dem Namen Shard1_1 lauten wie folgt:
Scherbe1_0
Und die Statistiken für Shard mit dem Namen Shard1_0 lauten wie folgt:
Wie Sie sehen, haben wir insgesamt 32 Dokumente, das ist die gleiche Anzahl wie in der ursprünglichen Sammlung.
Aufräumen
Das Aufräumen habe ich mir für das Ende aufgehoben. Um die Daten in neuen Shards zu sehen, müssen wir zunächst den Befehl commit für unsere Sammlung ausführen. Dies kann zum Beispiel mit dem folgenden Befehl geschehen:
[code language=“XML“]
curl ‚http://localhost:8983/solr/collection1/update‘ –data-binary ‚<commit/>‘ -H ‚Content-type:application/xml‘
[/code]
Darüber hinaus können wir auch den ursprünglichen Shard entfernen, zum Beispiel über das Solr-Administrationspanel oder die CoreAPI.
Letzter Test
Als Zusammenfassung habe ich beschlossen zu testen, ob die Dokumente in den Shards, die durch die SPLITSHARD-Aktion erstellt wurden, verfügbar sind. Dazu habe ich den folgenden Befehl verwendet:
[code language=“XML“]
curl ‚http://localhost:8983/solr/collection1/select?q=*:*&rows=100&fl=id,[shard]&indent=true‘
[/code]
Und Solr antwortete auf folgende Weise:
[code language=“XML“]
<?xml version=“1.0″ encoding=“UTF-8″?>
<response>
<lst name=“responseHeader“>
</lst>
<result name=“response“ numFound=“32″ start=“0″ maxScore=“1.0″>
</result>
</response>
[/code]
Wie Sie sehen können, stammen die Dokumente aus beiden Shards, was wiederum unseren Erwartungen entspricht. Bitte denken Sie daran, dass dies nur ein Anwendungsbeispiel ist und wir sicher auf das Thema Shard-Split zurückkommen werden.