SolrCloud Grundlagen

Mit wachsendem Datenbestand und mit der wachsenden Verbreitung einer Anwendung werden 2 Faktoren immer wichtiger: Performance und Ausfallsicherheit. Solr bot dafür bisher (und noch immer) Solr Distributed Search und Solr Replication. Nimmt man beide Features zusammen und packt noch etwas Konfigurationsmanagment hinzu, erhält man in etwa das, was Solr Cloud ausmacht.
Früher hätte man es einfach Solr Cluster genannt, heute heißt es dann natürlich Cloud. SolrCloud!
Vorab ein paar Einschränkungen / wichtige Punkte / Probleme zu Solr Cloud:

1. Solr Cloud gibt es erst am Solr Version 4
2. MLT (More Like This) wird nicht unterstützt
3. Grouping wirft Fehler bei group.query (wobei group.field läuft)
4. SolrCloud benötigt Apache ZooKeeper

...um nur die (für uns) relevanten Punkte aufzuführen. Solr 4 liegt derzeit nur in der Beta vor. Denkbar, dass bis zur finalen Version auch group.query sauber laufen wird. Zum MLT gibt es in den Groups/Foren einige Einträge, wünsche und Vorschläge zu Patches, aber auch keine wirkliche Problemlösung.

Auf der anderen Seite bietet Solr Cloud auch ein paar Vorteile:

1. Hochverfügbarkeit durch mehere Solr Instanzen auf mehreren Maschinen
2. bessere Datenintegrität durch Rplikation auf n Maschinen
3. höhere Geschwindigkeit beim suchen und Neuaufbau des Index

SolrCloud nutzt ein paar neue und ein paar alte Begrifflichkeiten.

• Colleciton: eine Collection ist bspw. eine Ansammlung an Nodes, über die ein Solr Index verteilt und repliziert ist. Sie ist das überspannende "ALLES"
• Shard: die Stücke eines Index, wobei dieser Begriff bereits beim Distributed Search genutzt wurde. Shards bestehen in 2 Arten:

1. (klassischer) Shard: ein (aktiver) Teil eines Index
2. Shard replicas: die Kopie eines Shard zur Sicherstellung der Redundanz, falls ein Knoten ausfällt.

• Slice: Slice ist kein offizieller Begriff seitens Solr, symbolisiert allerdings immer mal wieder ein Stückchen eines shard.

In der Kombination schaut das dann in etwa so aus:

Eine (frühere) Solr Instanz, also ein Solr Index (oder Solr Core) tritt jetzt als Collection auf, verteilt auf unterschiedliche Shrads. Dabei kann jeder Shard auf einem anderen Server liegen, was aber nicht zwingend notwendig ist. Selbst mehrere Shards auf der gleichen Maschine bringen einen Performance Vorteil bei Suchanfragen oder Facetted search, da jetzt über CPU's skaliert werden kann, was mit nur einem Solr Core nicht wirklich möglich ist.
Jeder Node (Shard) enthält einen Teil des Index sowie Kopie(n) der anderen shard / Indexteile.

Dabei ist die Aufteilung der Replikas und verteilten Index-Stückchen in der Cloud weitestgehend frei konfigurierbar (mehr im Artikel zur Einrichtung der Cloud). Ein Index kann bspw. auf 4 Nodes (z.B. auf 4 Server), aufgeteilt werden, wobei von jedem Slice nur eine weitere Kopie auf einem anderen Shard vorhanden ist. Beispiel mit 3 Nodes:
Shard 1: beinhaltet Slice 1 und als shard replica Slice 2'
Shard 2: beinhaltet Slice 2 und als shard replica Slice 3'
Shard 3: beinhaltet Slice 3 un dals shard replica Slice 1'
Das spart in der Summe gerade bei einem großen Index Speicherplatz in der Solr Cloud und garantiert dennoch eine Datenredundanz.



In der Anwendung selber adressiert man nur die Collection im bekannten Format: http://nodeX:8080/solr/collectionName/select?q=...

Wer den CollectionName so wählt, wie früher den einzelnen SolrCore nannte, muss also in der Anwendung noch nicht mal etwas umschreiben.
Der Solr Cluster, sorry, die Solr Cloud, kümmert sich dann um das Zusammensammeln der Ergebnisse oder bei einem Import auch um das replizieren der Daten auf die anderen Knoten.

Wie man einen solCloud einrichtet und einen Lucene Index  / Solr Core in eine solrCloud migrierd, ist hier zu lesen: SolrCloud einrichten / Migration zu SolrCloud