Die Neuerungen von Apache Solr 4.0
Apache Solr 4.0, der derzeitige Entwicklungszweig des quelloffenen Suchservers, steht in den Startlöchern. Das Release enthält neue und überarbeitete Features, die zukünftig Solr-Suchen mächtiger, schneller und komfortabler machen sollen. Ein erster Einblick in die wichtigsten Neuerungen.
- Markus Klose
Apache Solr 4.0, der derzeitige Entwicklungszweig des quelloffenen Suchservers, steht in den Startlöchern. Das Release enthält neue und überarbeitete Features, die zukünftig Solr-Suchen mächtiger, schneller und komfortabler machen sollen. Da es nur noch wenige Wochen bis zur finalen Freigabe dauert, sei ein erster Einblick in die wichtigsten Neuerungen gegeben.
Die Erweiterungen mit dem womöglich größten Mehrwert sind unter dem Stichwort Solr Cloud zusammengefasst. Deren Techniken sollen die Konfiguration und Verwaltung verteilter Systeme vereinfachen. An erster Stelle ist hier das Apache-Projekt Zookeeper zu nennen. Mit Solr Cloud wird es außerdem keine Single Point of Failures mehr geben, wie man sie noch bei der aktuellen Version findet. Beim Ausfall eines Indizierungsservers springt ein anderer Server der Cloud ein. Solr bietet darüber hinaus eine automatische Verteilung der Dokumente bei der Indizierung und synchronisiert neue Knoten in der Cloud automatisch. Weitere Funktionen von Solr Cloud sind unter anderem:
Was ist Solr?
Solr beruht auf Apache Lucene, einer im Java-Umfeld populären Search Engine mit täglich über 5000 Downloads. Mit seiner Performance und seinem Funktionsumfang darf Solr als Open-Source-Alternative zu großen kommerziellen Produkten wie FAST ESP gelten.
Seinen Beginn hatte der Suchserver 2004 als Inhouse-Projekt bei CNET. 2006 wurde es an die Apache Software Foundation übergeben und ist mittlerweile ein Top-Level-Projekt der Open-Source-Organisation. 2010 wurde Solr mit Lucene zu einem Projekt zusammengefasst, da grundsätzlich das gleiche Team von Entwicklern an den Projekten beteiligt war und ist.
Die Version 4.0 liegt derzeit als Alpha-Version vor.
- Echtzeitabfrage (Realtime-Get): Direkt nach dem Indizieren lässt sich ein Dokument aus der Solr Cloud abrufen, ohne dass explizit eine Suche auszuführen wäre.
- Suche nahe an Echtzeit (NearRealTime): Mit einer neuen Commit-Strategie (softCommit) lassen sich neu hinzugefĂĽgte Dokumente nahezu sofort durch eine Suche finden.
- Update-Sicherheit: Selbst noch nicht transaktionierte Dokumente gehen bei einem Ausfall nicht verloren, da ein "Transaction Log" alle Ă„nderungen erfasst.
- Automatisches Failover bei schreibenden oder lesenden Zugriffen.
Vermittler und VerschlĂĽssler
Fragen wie "Welcher Hersteller bietet den preiswertesten Flat Screen an?", "Wo wurde der Architekt des Kölner Doms geboren?" und "Wer sind die Kinder von Max Mustermann?" mit einem Solr-Index zu beantworten ist nicht trivial, da ein Teil der Informationen aus einem Bereich kommt und ein weiterer Teil aus einem gänzlich anderen. In einem gewöhnlichen Solr-Datenmodell wären die unterschiedlichen Beziehungen zwischen Hersteller und Produkt, zwischen Kulturobjekten und Personen oder zwischen Personen untereinander aufzulösen. Ein Dokument hätte dann alle Informationen zum Erfüllen der Suchkriterien. Das resultiert jedoch in einem unübersichtlichen und komplexen Schema und einem nur über einen Kraftakt zu bewältigenden Indizieren, da schon kleine Änderungen an einem Teil, zum Beispiel der Preis, dazu führen, dass das komplette Dokument erneut zu indizieren ist.
Mit Join kann der Entwickler die Dokumente untereinander in Beziehung setzen, ähnlich wie man das aus relationalen Datenbanken kennt. Joins definiert der sogenannte "Local Params"-Mechanismus, der ein Schlüssel- und ein Fremdschlüsselfeld spezifiziert. Ein typischer Join sieht wie folgt aus:
{!join from=key_field to=foreignkey_field}
Über die Felder key_field und [/i]foreignkey_field[/i] setzt der Entwickler die Dokumente in Relation. Der Join wird in die Abfrage integriert; alle gängigen Parameter haben weiterhin ihre Gültigkeit.
FĂĽr die Fragestellung nach den Kindern von "Max Mustermann" sei davon ausgegangen, dass im Index Personen enthalten sind, die folgende Attribute haben: id, name, vater, mutter. Die Felder "vater" und "mutter" bilden die Beziehungen ab. Sie enthalten jeweils die ID der Person, die Mutter beziehungsweise Vater ist. Die Suche nach allen Kindern von Max Mustermann gestaltet sich mit dem Join wie folgt:
http://localhost:8983/select?q=*:*&fq={!join from=id
to=vater}name:"Max Mustermann"
Die neue Solr-Version enthält eine Codec API. Es wird zukünftig so sein, dass man mit ihr für jedes Feld individuell festlegen kann, in welchem Datei-Format es abzulegen ist. Die API ist konfigurierbar, sodass sich diverse Optionen für die Architektur und das Schema-Design ergeben können. Die folgenden Punkte skizzieren einige Codec-Varianten:
- Lucene40Codec: Das ist der Standard-Codec fĂĽr das Speichern der Indexinformationen.
- PulsingCodec: Er legt Informationen wie Postings und Nutzdaten mit im TermDictionary ab, um separate Zugriffe auf der Festplatte zu vermeiden.
- TeeCodec: Damit werden die gleichen Daten an unterschiedliche Ziele indiziert und somit die Replikationsoptionen erweitert.
- FilteringCodec: Er kann festlegen, ob bestimmte Feldinhalte (stored fields, indexed fields, payloads, postings) während der Indizierung gelöscht werden sollen oder nicht.
