SHI GmbH Augsburg - Ihr Starker Partner für Search & Big Data, Apache Solr, IT Commerce Lösungen

27-03-2017 - 28-03-2017
Apache Solr Unleashed
29-03-2017 - 30-03-2017
Apache Solr Under the Hood
04-04-2017 - 05-04-2017
Apache SolrCloud
SHI - Fast Forward to Success
SHI - Fast Forward to Success
Geschwindigkeit zählt. Bei den Kosten und bei den Erfolgsaussichten.
Bei uns sorgen professionelles Projektmanagement und modulare Entwicklung
für Ihren raschen und effizienten Software-Projekterfolg.
SHI - Support und Service
SHI - Support und Service
Wir sind Dienstleister aus Leidenschaft und verstehen unsere Kunden.
Nach dem Projekt ist vor dem Projekt und individuelle, persönliche
Betreuung stehen bei uns ganz weit oben.
SHI - Individuelle Anwendungen aus Software-Bausteinen
SHI - Individuelle Anwendungen aus Software-Bausteinen
Bei uns bekommen Sie weder Software von der Stange, noch unerprobte Eigenentwicklungen. Wir setzen auf bewährte Open-Source-Technologien und setzen Ihre individuelle Anwendung
aus passenden
Bausteinen zusammen.
SHI - Beratung  Entwicklung  Consulting
SHI - Beratung Entwicklung Consulting
Wir beraten unterstützen Sie mit Schulungen, Trainings und Consulting. Von der Strategieberatung bis zur Anwendungsentwicklung helfen wir Ihnen bei der Optimierung Ihrer
Geschäftsprozesse.

Universal AJAX Live Search

Veröffentlicht am 09.02.2017 von Markus Klose


Dieser Blog ist eine kurze Einführung in die CDCR (Cross Data Center Replication) Funktionalität von Solr. Es wird beschrieben, was CDCR ist, was CDCR nicht ist und wann man diese Funktionalität einsetzen kann.

Veröffentlicht am 08.02.2017 von Daniel Wrigley

Teil III


Nachdem die beiden vorhergehenden Blogs eine Einführung in die Thematik und vorbereitende Maßnahmen behandelt haben, geht es im abschließenden Teil der Blog-Serie um das große Ziel: Mit Hilfe von Streaming Expressions ein Modell zur Erkennung von Spam-Mails zu trainieren und zu validieren und zu Klassifikationszwecken einzusetzen.

Klassifikation mit Solr mit Hilfe von Streaming Expressions

Wie im einführenden Beitrag beschrieben, durchläuft man bei Klassifikationsthemen drei Phasen:


1.    Trainieren eines Modells
2.    Testen und Validierung des Modells
3.    Klassifikation von neuen Dokumenten mit Hilfe des validierten Modells


Alle Phasen werden von Solr und den enthaltenen Streaming Expressions ab Version 6.3.0, die für diesen Beitrag verwendet wird, unterstützt. Das heißt konkret: Auf Basis indexierter Dokumente kann Solr ein Modell errechnen, welches in einer Collection gespeichert werden kann. Die in der Trainingsphase extrahierten Features können in mehreren Iterationen verfeinert werden, um ein besseres Klassifikationsmodell zu erhalten, welches eine bessere Klassifikationsgüte aufweist. Dieses gespeicherte Modell kann dann wiederum verwendet werden, um weitere, indexierte Dokumente zu klassifizieren.

Exkurs – Streaming Expressions

Streaming Expressions wurden in Solr 6.0 eingeführt und seitdem stetig erweitert und verbessert. Sie bieten eine einfache, aber sehr mächtige Sprache für die Verarbeitung von Datenströmen mit Solr. Durch die hohe Skalierbarkeit, die die SolrCloud bietet, ist ein hoher Grad an Parallelisierung bei der Verarbeitung möglich. Der bereitgestellte Funktionsumfang weist ein Höchstmaß an Flexibilität auf, was durch die Kombinationsmöglichkeiten der Expressions unterstrichen wird. Das Spektrum reicht von einfachen Operationen wie Suchen bis hin zu komplexen Tätigkeiten wie Klassifikation mittels Machine Learning Algorithmen. Letzteres wird in diesem Beispiel gezeigt.


Klassifikationsmodell trainieren und speichern

Das Trainieren des Modells übernimmt Solr, ebenso wie das Speichern in einer Collection:


update(modelCollection,
 batchSize=1,
 train(mails,
 features(mails, q="*:*", featureSet="first", field="_text_",
 outcome="out_i", numTerms=250),
 q="*:*",
 name="model1",
 field="_text_",
 outcome="out_i",
 maxIterations=100))

Bereits bei diesem Aufruf werden drei Streaming Expressions miteinander verknüpft. Die innerste Funktion (features) extrahiert Features aus den Ergebnissen einer Suchanfrage. Hierfür werden 250 Terme aus dem Feld _text_ extrahiert. Es wird ein Algorithmus namens Information Gain verwendet, um die wichtigsten Terme aus diesem Feld zu extrahieren. Die Query (q) gibt an, welche Dokumente zum Trainingsset dazugezählt werden. In diesem Fall sind es alle („Match All Query“). Die Angabe der Query ermöglicht es, in einer SolrCloud Collection mehrere Trainingssets zu halten, um die besten Trainingsdaten für einen bestimmten Use Case herauszufinden.


Die extrahierten Features bilden den Input für die train-Funktion. Unter Angabe von maxIterations wird spezifiziert, wie viele Iterationen zur Modellerstellung durchgeführt werden sollen. In diesem Beispiel sind es 100 Iterationen. Demnach werden auch der Reihe nach 100 Modelle berechnet, die dann an die update-Funktion zur Indexierung weitergereicht werden.


Die Iterationen übernehmen in diesem Fall günstiger Weise bereits eine Art Validierung des Modells, d.h. nach jeder Iteration werden die für eine Wahrheitsmatrix notwendigen Zahlen mit ausgegeben. Die beste Klassifikationsgüte ist erreicht, wenn alle 1500 Spam-Nachrichten mit dem errechneten Modell als Spam erkannt werden, alle 3672 restlichen Nachrichten als „Kein Spam“ erkannt werden und die Fehlerrate möglichst niedrig ist. Der Output hierzu sähe folgendermaßen aus:


"trueNegative_i": 3672,
"falseNegative_i": 0,
"falsePositive_i": 0,
"error_d": 0.01928354545373971,
"truePositive_i": 1500


Den zugrunde liegenden Algorithmus hier en détail zu beschreiben, würde den Rahmen sprengen. Mehrere Iterationen bedeutet im Wesentlichen, dass pro Iteration versucht wird, die Fehlerquote (error_d) zu minimieren, indem das Featureset angepasst wird. Auch wenn nach 100 Iterationen ein sehr niedriger Fehlerwert berechnet wird und keine falsch negativen und keine falsch positiven Klassifikationen ermittelt werden, ist diese Validierung mit Vorsicht zu genießen, da derjenige Datensatz zum Testen und Validieren verwendet wird, der bereits zur Erstellung des Modells herangezogen worden ist. Eine bessere Variante wäre die Verwendung von Daten, die nicht zur Modellerstellung verwendet wurden.


Nichtsdestotrotz wird es für diese Einführung dabei belassen. Das Ergebnis dieses Schritts sieht also wie folgt aus: Es ist auf dem Inhalt der Collection mails pro Iteration der train-Funktion ein Modell in der Collection modelCollection indexiert worden. Diese Modelle stehen nun für die Klassifikation weiterer Dokumente zur Verfügung.


Dokumente mit dem trainierten Modell klassifizieren

Nachdem ein Modell trainiert ist, können nun Dokumente klassifiziert werden. Natürlich können für einen schnellen Test diejenigen verwendet werden, die bereits für das Training des Modells Verwendung fanden. Nachfolgende Streaming Expression sucht in der Collection mails nach allen Dokumenten (q=*:*, „Match-All Query“), liefert zwei Dokumente zurück (rows=2) und klassifiziert diese mit dem berechneten Modell. Aber es wird wenig überraschend sein, dass dies funktioniert und eine richtige Klassifikation erfolgt, da bereits bei der Modellerstellung von Solr zurückgemeldet wurde, dass alle für das Training verwendeten Datensätze erfolgreich klassifiziert werden konnten.

classify(model(modelCollection, id="model1", cacheMillis=5000),
   search(mails,
    q="*:*",
    fl="_text_, id",
    sort="id asc",
    rows="2"),
   field="_text_")

Ein richtiger Test wären also neue Dokumente. Nachdem der Enron Datensatz einige Mails mehr hat als nur diejenigen, die für das Erstellen des Klassifikationsmodells verwendet wurden, ist dies auch kein Problem. Die einfachste Möglichkeit wäre das Anlegen einer neuen Collection, die Indexierung neuer Mails und eine Anpassung obiger Streaming Expression.


Zusammenfassung

Obwohl der Rahmen dieser Einführung in Solrs Machine Learning Fähigkeiten sehr eng abgesteckt war, hat der durch Solr Streaming Expressions zur Verfügung stehende Ansatz zur Klassifikation sehr gute Ergebnisse bei dieser Binärklassifikation gezeigt. Streaming Expressions sind bereits jetzt, trotz ihres noch recht jungen Alters, mächtige Werkzeuge, deren Kraft sich eigentlich erst richtig entfaltet, wenn sie in großen SolrCloud-Installationen kombiniert bzw. verknüpft werden. Selbst dieses Fallbeispiel ließe sich noch problemlos ausbauen, indem neue, nicht klassifizierte Dokumente von dem Modell klassifiziert werden und das Klassifikationsergebnis mittels der update Streaming Expression wieder in Solr eingespielt wird. Es ist auf jeden Fall sehr beeindruckend und spannend zu sehen, wie sich Solr aktuell nach nun mehr als zehn Jahren weiterentwickelt.


Ein Wort der Vorsicht zum Schluss: Streaming Expressions werden zum jetzigen Zeitpunkt (Solr 6.3.0) noch als experimentell angesehen, d.h. oben beschriebenes Beispiel kann in aktuelleren Versionen zu Fehlern führen bzw. sogar nicht mehr im Funktionsumfang enthalten sein.

Veröffentlicht am 26.01.2017 von Daniel Wrigley

Teil II


In einem vorherigen Blog wurde eine Einführung in das Thema Klassifikation gegeben, das hiermit mit einem konkreten Use Case fortgeführt wird. Dieser zweite Teil der Blogserie wird die Vorbereitungsmaßnahmen beleuchten, die notwendig sind, um Solr als Klassifikationsmaschine einsetzen zu können. Dieser Blog behandelt also vom Starten von Solr über das Anlegen der notwendigen Collections bis hin zur Indexierung der Trainingsdaten alle Schritte.

Veröffentlicht am 17.01.2017 von Daniel Wrigley

Teil I

Spätestens seit dem letzten Major Release von Solr im April letzten Jahres, der Version 6.0, sind Features und Möglichkeiten eingeführt worden, die nicht mehr unbedingt zum klassischen Repertoire einer Suchmaschine zu zählen sind. Abfragen auf Basis von SQL-Syntax sind hier zu nennen, Graphen-Traversierung oder eben Textklassifikation, ein Bereich des Machine Learning, das in dieser Blogserie näher beleuchtet wird. In diesem ersten Beitrag werden die inhaltlichen Grundlagen der Textklassifikation erläutert, bevor ein konkreter Use Case dargelegt wird.

 

Die sogenannten „Saved Searches“ sind eine Suchtechnik, bei der ein Anwender seine Suche „speichern“ kann. Jede Änderung im Index wird mit den Saved Searches abgeglichen. Sobald ein Produkt auf diese Suche passt, wird der Anwender (beispielsweise durch eine E-Mail) benachrichtigt. Dies ermöglicht ein nachträgliches Finden von Produkten, Artikeln etc. Diese Technik lohnt sich vor allem dann, wenn die Inhalte des Index häufig aktualisiert werden, wie es in Auktionsplattformen der Fall ist. Einige E-Shops bieten diese Funktionalität bereits an und wir können messen, dass das Interesse an Saved Searches kontinuierlich steigt. Daher stehen wir oft den Fragen gegenüber, ob Saved Searches mit Apache Solr umgesetzt werden können.

Dass Suche mittlerweile mehr ist, als nur das Auffinden von Dokumenten, die ein Suchwort beinhalten, ist längst kein Geheimnis mehr. Ebenso ist hinlänglich bekannt, dass es hierfür Lösungen gibt, die sehr weit ausgereift sind. Dies sind nicht nur Lösungen kommerzieller Natur, sondern auch kostenlose Open Source Varianten, wie Apache Solr, die unübertroffene Skalierbarkeit zeigen.

Bei Apache Solr gibt es grundlegend keine Sicherheitsmechanismen. Dies betrifft sowohl den Zugriff auf den Solr-Server selbst, als auch die einzelnen Dokumente. Natürlich gibt viele bewährte Workarounds hierfür. Beispielsweise kann man den Solr-Server im eigenen Netz so absichern, dass nur bestimmte Ports freigeschaltet werden. Für Dokumentsicherheit kann man ACL Informationen mit im Index abspeichern und bei der Suche mit berücksichtigen.

Viele Applikationen, die auf Apache Solr basieren, enthalten Daten, auf die nicht jeder zugreifen soll, und müssen daher besonders gesichert werden. Dies wird im World Wide Web in der Regel über eine Verschlüsselung der Kommunikation und eine Zugriffsbeschränkung mittels TLS/SSL erreicht. Der gleiche Mechanismus ist schon vor einigen Versionen in Apache Solr integriert worden. Seit Solr 4.8 können nun einzelne Solr Installationen technisch mit Zertifikaten abgesichert werden. Dies gilt natürlich auch für verteilte Systeme, wie klassische Master/Slave-Architekturen oder die SolrCloud.

Wie Sie SSL in Ihrer Solr Installation aktivieren können, ist im Apache Solr Reference Guide ausführlich beschrieben.

Diese Woche ist Apache Solr 4.9 veröffentlicht worden. Neben vielen Bug-Fixes und Verbesserungen gab es auch einige neue Funktionalitäten. Eine von den hervorstechenden Neuerungen ist die AnalyticsQuery API, die ich in diesem Blog kurz vorstellen werde.

Apache Solr 4.9 steht in den Startlöchern. Daher wird es Zeit neue und spannende Funktionalitäten unter die Lupe zu nehmen. Eine der kommenden Neuerungen wird das sogenannte Re-Ranking sein, welches ich in diesem Blog beschreiben möchte.

Wie bereits im vergangenen Blog (Monitoring mit Solr) angedeutet, möchte ich hier nun auf die Möglichkeit eingehen, wie man Log-Dateien mittels Logstash verarbeiten kann, so dass diese anstelle in einem Elasticsearch Index in einem Solr Index landen.

Logstash bietet eine Vielzahl von Plugins, sowohl für „input“, „filter“ oder „output“. Das Plugin für den Solr Output ist nicht integraler Bestandteil von Logstash, sondern wurde von der Community entwickelt. Um dieses Plugin zu nutzen, muss es separat installiert werden. Ich verzichte bewusst auf die Beschreibung, wie man dieses Plugin installiert, da ich mich auf die Konfiguration konzentrieren möchte. Weiter unten finden Sie jedoch einen Link mit der Beschreibung zur Plugin-Installation.

In einem früheren Blog habe ich einen kurzen Einblick in Apache Stanbol und Named Entity Recognition (NER) gegeben. Die gezeigte Oberfläche war der Stanbol Enhancer. Er ist dafür zuständig, Entitäten im Fließtext zu erkennen.

In diesem Beitrag will ich etwas näher auf den sogenannten Contenthub eingehen, der ebenfalls Teil von Apache Stanbol ist. Der Contenthub besteht aus zwei Komponenten: Store und Search. Wie die Namen bereits verraten, ist Store für die persistente Datenspeicherung zuständig und Search für die Suche. Führt man den full launcher aus (nicht den stable launcher!), wird im Hintergrund ein Solr Server gestartet. Dieser dient gleichermaßen zur Speicherung angereicherter Daten als auch zur Suche in diesen Daten.

Wird ein Dokument über den Stanbol Contenthub erstellt, wird dessen Inhalt an den Stanbol Enhancer übergeben. Dieser ist dafür zuständig, diesen Inhalt mit Metadaten anzureichern. Dieser Prozess wird auch Enhancement genannt. Optional besteht die Möglichkeit, externe Daten hinzuzufügen. Schließlich wird das Dokument zusammen mit den Metadaten in einem Solr Core indexiert.

Monitoring ist ein wichtiges Thema. Egal ob es sich um die technische Überwachung einer Serverlandschaft handelt oder beispielsweise um das Tracking des Userverhaltens beim Einkauf in einem Onlineshop. Es ist immer wichtig, gezielt nach Informationen wie Conversion-Rate oder CPU-Auslastung zu „suchen“, diese aufzubereiten und darzustellen.

Sehr schnell kommt man bei diesem Thema mit dem ELK-Stack – Elasticsearch, Logstash und Kibana – von Elasticsearch in Berührung. Aber es geht natürlich auch anders.

Dieser Beitrag stellt den Auftakt einer Serie von Beiträgen dar, die sich dem Thema aus der Sicht von Solr widmet. Wir werden an Beispielen zeigen, wie man bereits jetzt Solr für Monitoring Aufgaben nutzen kann, wie man Solr mit bestehenden Tools bzw. Frameworks zusammenbringen kann und was für die Zukunft geplant ist.

Mein Kollege Daniel Wrigley hatte vor gut einem Jahr bereits über das Document-Routing in Solr in einem Blogbeitrag berichtet. In diesem Jahr sind weitere Solr Versionen mit Anpassungen, Erweiterungen und neuen Features veröffentlicht worden. Die Änderungen betreffen auch das mit Solr 4.1 eingeführte Document Routing. Mit der Solr Version 4.5 wurde dieses Feature überarbeitet und vereinfacht. Dies möchte ich nun in diesem Blog vorstellen.

Das “neue” Document Routing

An dem grundlegenden Mechanismus vom Document Routing hat sich nichts geändert. Solr stellt weiterhin die beiden Routing Varianten „implicit“ und „compositeId“ zur Verfügung, wobei „implicit“ weiterhin die Default-Einstellung ist. Ändern kann man diese Variante nun beim Erstellen einer Collection, indem man den Parameter „router.name“ setzt.

http://localhost:8983/solr/admin/collections?action=CREATE&name=myCollection&...amp;router.name=compositeId

Bei der Variante „compositeId“ wertet Solr bei der Indexierung weiterhin die Dokument-IDs aus, um Dokumente mit dem gleichen Präfix im gleichen Shard zu indexieren. Zum Beispiel landen Dokumente mit den IDs „SPORT!123“ und „SPORT!234“ in einem Shard. Es ist dabei weiterhin freigestellt, was die Präfixe sind. Sie müssen nicht zwingend eine Kategorie, wie in meinem Beispiel, widerspiegeln.

Für die Suche wurde der Parameter „shard.keys“ durch „_route_“ ersetzt. Der „shard.keys“ Parameter wird in einer der kommenden Solr Releases entfernt, daher sollte man, wenn möglich, auf „_route“ umsteigen. Dieser neue Parameter reiht sich in die „magischen“ Variablen von Solr wie „_val_“, „_version_“ oder „_root_“ ein und wird zukünftig genutzt, um in der Suchanfrage den Shard zu definieren, in dem gesucht werden soll.

Folgender Request würde in dem Shard suchen, in dem die Sport-Dokumente gelandet sind.

http://localhost:8983/solr/select?q=*:*&_route_=SPORT!

Solche Suchanfragen können die Performance verbessern, da weniger Shards durchsucht werden und somit auch weniger Netzwerklast erzeugt wird.

Fazit

Auch wenn sich augenscheinlich nicht so viel geändert hat, ist die Nutzung vom Document Routing nun etwas intuitiver geworden.

Document Routing ist dabei nicht das Wundermittel, um die Suchperformance zu steigern, aber es hilft definitiv, um die Ressourcen in einem Solr Cluster weise bzw. gezielt zu nutzen.

Weiterführende Informationen:

Am 28. Januar wurde die Version 4.6.1 von Open Source Suchserver Apache Solr veröffentlicht. Es handelt sich hierbei um ein Release, das knapp 30 Bugs bereinigt. Das sorgt für mehr Stabilität und Verlässlichkeit. Mark Miller, Lucene PMC und Solr Committer nennt es deshalb sogar einen Meilenstein in der Entwicklung von SolrCloud, die Ende 2012 eingeführt wurde. Sie können die Veränderungen in dieser Version in den Apache Solr Release Notes einsehen. Die neueste Version steht auf der Homepage von Solr zum Download zur Verfügung.

In einem früheren Beitrag bin ich bereits etwas näher auf das Thema Stemming in der Analysekette von Solr (http://www.shi-gmbh.com/blog/solr-analysekette-stemming/) eingegangen. Neben der Bedeutung von Stemming für die Suchtechnologie habe ich auch den Einsatz des Porter-Stemmers in Solr beschrieben, ebenso wie die Erweiterungen durch den KeywordMarkerFilter (Wörter als Keywords markieren, um Stemming zu vermeiden) und den StemmerOverrideFilter (eigene Stemming-Regeln definieren).

In diesem Artikel möchte ich den Hunspell Stemmer inklusive dessen Stärken und Schwächen etwas näher beleuchten und wie Sie mit diesen umgehen können.

Das bekannte Programm LogStash, daß zuvor nur für Elasticsearch verfügbar war, gibt es nun auch für Solr. Die Entwickler von Lucidworks haben letzte Woche die erste Version von LogStash-4-Solr auf Ihrer WebSeite veröffentlicht.

 

LogStash wurde implementiert, um Log-Dateien schnell und unkompliziert in Elasticsearch zu importieren. Dabei kann über eine Konfiguration festgelegt werden, welche Teile eines Log-Eintrags, in welche Felder indiziert werden sollen.

Mit LogStash-4-Solr können die Log-Dateien jetzt in Solr importiert werden und die vorhandenen LogStash-Konfigurationen können weiter verwendet werden.

Die Anbindung von Kibana ist noch nicht vorhanden. Hierfür gibt es aber aktuell das Projekt SEMKit „Search Engine Migration Kit“ (ehemals Kibana4Solr), welches als Mittelschicht zwischen Kibana und Solr dienen soll. Das Projekt SEMKit wurde im November auf der Lucene Revolution in Dublin vorgestellt und wird voraussichtlich ab Dezember in Github als Open Source Projekt zu Verfügung stehen.

In einem meiner letzten Beiträge bin ich bereits auf die Möglichkeit eingegangen, Suchtechnologie zu Analysezwecken einzusetzen. Die Produkte bzw. Projekte, die ich genannt hatte, waren Apache Solr, ElasticSearch, Logstash, Kibana und LogStash-4-Solr.

Dieser Beitrag soll Ihnen eine kurze Einführung in das noch sehr junge Projekt LogStash-4-Solr geben, welches sich im Moment in einer Beta-Version befindet. Die Funktionsweise des Tools ist folgende: Es gibt ein bestimmtes Set an Quelldaten (z.B. Log-Dateien wie der Name schon andeutet), die von LogStash-4-Solr gesammelt und zur Indexierung aufbereitet werden. Danach werden diese Daten an Solr gesendet, damit diese indexiert werden können.

 

Logstash ist „im Original“ in der Version 1.3.2 veröffentlicht. LogStash-4-Solr ist ein Plugin, welches Sie mit Logstash 1.2.2 verwenden.

Systemvoraussetzungen

Und damit sind wir schon bei den notwendigen Systemvoraussetzungen, um den Anleitungen dieses Beitrags folgen zu können. Sie benötigen Solr ab Version 4.4. Getestet wurde die Anleitung mit Solr 4.6, der aktuell jüngsten Version. Des Weiteren benötigen Sie oben erwähnte Logstash-Version, die Sie über die ElasticSearch-Homepage mit folgendem Link beziehen können:
https://download.elasticsearch.org/logstash/logstash/logstash-1.2.2-flatjar.jar.
Zudem noch den Teil, der dafür sorgen soll, dass Logstash auch mit Solr zusammenarbeitet. Diesen erhalten Sie auf http://logstash4solr.lucidworks.com/. Es ist ein Archiv namens deploy.zip.

Vorbereitung und Einrichtung von Solr und LogStash-4-Solr

Erfüllen Sie die Voraussetzungen, können Sie mit der Einrichtung beginnen. Zunächst legen Sie einen neuen Solr-Core an, in dem die Daten später zu finden sein sollen. Kopieren Sie dazu das Verzeichnis logstash_logs aus dem Archiv deploy.zip in das Verzeichnis, in dem Ihre Solr-Cores sich befinden, also dem Solr-Home-Verzeichnis. Erstellen Sie dann einen Core, der denselben Namen des Verzeichnisses trägt, das Sie eben kopiert haben (logstash_logs). Nun sollten Sie einen laufenden Solr Suchserver haben, der mindestens einen Core namens logstash_logs hat.

Im nächsten Schritt richten Sie Ihre Logstash-Konfiguration ein. Eine Logstash –Konfiguration besteht immer aus drei Teilen: Input, Filter, Output. Input definiert eine oder mehrere Quellen, die Sie indexieren möchten. Filter ist für die Aufbereitung der Daten zuständig. Hier können Sie unter anderem angeben, welche Informationen in dem Input-Datenstream sind und in welchen Feldern Sie diesen indexieren wollen. Output definiert schließlich eine oder mehrere Ziele dieser Strecke.

Im Folgenden finden Sie eine Beispielkonfiguration, die sich eignet sich für folgendes Szenario:

  • Quelldaten sind Syslog-Dateien Ihres Unix-Systems (Input)
  • Indexierung mit Solr
  • Solr Umgebung: Identischer Host, Port 8983
  • Name eines Cores: logstash_logs
input {
  file {
    type => "syslog"
    exclude => ["*.gz","*.zip","*.tgz"]
    path => [ "/var/log/syslog" ]
    sincedb_path => "/dev/null"
    start_position => "beginning"
  }
}
 
filter {
  if [type] == "syslog" {
    grok {
      match => [ "message", "%{SYSLOGLINE}" ]
    }
    date {
      match => ["timestamp", "MMM dd hh:mm:ss"]
    }	
  }
}
 
output {
  stdout {
    debug => true
    codec => "rubydebug"
  }
  lucidworks_solr_lsv122 {
    collection_host => "127.0.0.1"
    collection_port => "8983"
    collection_name => "logstash_logs"
    field_prefix => "logstash_"
  }
}

Ist Ihre Solr-Installation nicht unter http://localhost:8983/solr erreichbar, müssen Sie die Konfiguration eben entsprechend anpassen. Gleiches gilt natürlich für den Fall, dass Sie unter dem angegebenen Pfad nicht Ihre Syslog-Daten haben. Die Konfiguration nennen Sie logstash.conf und legen Sie in dem Verzeichnis ab, in das Sie das Archiv deploy.zip entpackt haben.

Die ausführbare Logstash-Jar (logstash-1.2.2-flatjar.jar) kopieren Sie ebenfalls in dieses Verzeichnis. Die vorbereitenden Maßnahmen sind hiermit getroffen.

Indexierung Ihrer Daten

Sie starten die Indexierung Ihrer Syslog-Dateien mit folgendem Aufruf (inklusive Leerzeichen und Punkt am Ende):

java -jar logstash-1.2.2-flatjar.jar agent -f logstash.conf -p .

In Ihrem Terminalfenster sollten Sie nun alle Events aus Ihrem Syslog sehen, die nacheinander indexiert werden. Da Sie bei Ihrem Input definiert haben, dass vom Anfang der Datei begonnen werden soll (start_position => “beginning”), kann dieser Prozess natürlich etwas dauern. Nachdem die ersten Dokumente in Ihrem Index gelandet sind, können Sie in Ihrem Browser erste Suchanfragen starten:

http://localhost:8983/solr/logstash_logs/select?q=*%3A*

Jetzt können Sie zum Beispiel herausfinden, welches Programm am häufigsten für Syslog-Einträge verantwortlich ist. Dafür können Sie obige Query verwenden und auf dem Feld program eine Facette bilden:

http://localhost:8983/solr/logstash_logs/select?q=*%3A*&facet=on&facet.field=program&rows=0

In Ihrem Response sehen Sie nun die Anzahl der einzelnen Programme:

<result name="response" numFound="3447" start="0"/>
	<lst name="facet_counts">
	<lst name="facet_queries"/>
	</lst><lst name="facet_fields">
		</lst><lst name="program">
			<int name="kernel">2866</int>
			<int name="networkmanag">165</int>
			<int name="dhclient">129</int>
			<int name="daemon">74</int>
			<int name="dbu">40</int>
			<int name="rtkit">40</int>
			<int name="manag">38</int>
			<int name="modem">38</int>
			<int name="avahi">32</int>
			<int name="anacron">18</int>
			<int name="pulseaudio">16</int>
			<int name="cron">15</int>
			<int name="dnsmasq">12</int>
			<int name="rsyslogd">11</int>
			<int name="acpid">10</int>
			<int name="bluetoothd">10</int>
			<int name="configur">8</int>
			<int name="printer">8</int>
			<int name="udev">8</int>
			<int name="aptdaemon">6</int>
			<int name="aptdaemon.packagekit">6</int>
			<int name="aptdaemon.work">6</int>< <int name="ntpdate">4
			<int name="2039">2</int>
			<int name="account">2</int>
			<int name="failsaf">2</int>
			<int name="gnome">2</int>
			<int name="goa">2</int>
			<int name="mtp">2</int>
			<int name="polkitd">2</int>
			<int name="probe">2</int>
			<int name="python">2</int>
			<int name="session">2</int>
			<int name="hp">1</int>
		</lst>

Natürlich gibt es zahllose weitere Quellen, die Sie so indexieren können. Dazu werfen Sie am besten einen Blick in die Logstash-Doku. Achten Sie darauf, dass Sie nicht die Dokumentation der aktuellsten Version verwenden, denn diese wird immer „zu aktuell“ für die eingesetzte Logstash-Version sein und unter Umständen Features haben, die mit der momentan einsetzbaren LogStash-4-Solr-Version nicht verwendbar sind. Sie finden die Logstash-Doku für Version 1.2.2 unter http://logstash.net/docs/1.2.2/

Happy Logging, Indexing and Searching!

Die richtige Reihenfolge der Dokumente innerhalb der Trefferliste zu erreichen ist ein schwieriges Ziel. Da wird an allen Ecken und Enden geboostet, es wird der Relevanzalgorithmus umgeschrieben oder gar mit dem Elevate Feature gearbeitet. Trotz all dieser Möglichkeiten steht man oft vor der Situation, dass es dennoch nicht passt.

In diesem Blog möchte ich auf eine neue Möglichkeit eingehen, mit der man eine Sortierung durchführen kann, bei der man die Reihenfolge per Konfiguration selbst vorgeben kann.

EnumField

Oft haben wir in unseren Solr Projekten relativ einfache Anforderungen an das Sortieren: „Sortiere die Trefferliste, nach dem Inhalt eines bestimmten Feldes, jedoch nicht in alphabetischer Reihenfolge oder nach Häufigkeit, sondern nach einer definierten Gewichtung der Inhalte. Bisher mussten wir uns hier in den meisten Fällen mit External-File-Fields behelfen und eine entsprechende Lösung generieren.

Mit der Solr Version 4.6 wurde ein neuer Feldtyp eingeführt, mit dem man die Sortierung manuell beeinflussen kann. Der Enum-Feldtyp wurde dafür so designed, dass er eine XML-Datei als Konfiguration einliest und die Sortierung basierend auf der Reihenfolge der Werte der Konfiguration durchführt. Dadurch kann eine Sortierung umgesetzt werden, die losgelöst vom Alphabet und von der Häufigkeit des Vorkommens in der Trefferliste ist.

Die Konfiguration des Feldtyps ist zweiteilig aufgebaut. Zum einem, muss in der schema.xml-Datei Feld und Feldtyp definiert werden und zweitens, muss ein Mapping bzw. die Reihenfolge der Sortierung definiert werden.

schema.xml

<fieldtype name="priority" class="solr.EnumField" enumsConfig="enum.xml" enumName="priority"/>
<field name="priority" type="priority" indexed="true" stored="true" />

Im obigen Beispiel wird ein Enum-Feld definiert, dessen Konfiguration in einer Datei mit dem Namen enum.xml abgelegt wurde.

enum.xml

< ?xml version="1.0"?>
<enumsconfig>
   <enum name="priority">
      <value>Sehr Hoch</value>
      <value>Hoch</value>
      <value>Mittel</value>
      <value>Niedrig</value>
      <value>Sehr Niedrig</value>
   </enum>
   <enum name="gender">
      ...
   </enum>
 </enumsconfig>

In der obigen Konfiguration sind fünf unterschiedliche Werte für die Priorität definiert worden. Neben dem enum-Element mit dem Namen „priority“ können weitere Enums definiert werden, wenn man mehrere Felder von diesem Typ benötigt. Dies erspart einem die Pflege vieler unterschiedlicher Dateien.

Die Reihenfolge bei der Sortierung ergibt sich aus der Reihenfolge der Elemente, d.h. es werden zuerst alle Dokument mit dem Wert „Sehr Hoch“, dann die Dokumente mit dem Wert „Hoch“ usw. angezeigt.

Bei der Indexierung muss man nicht viel beachten. Man muss, wie im folgenden Beispiel dargestellt, nur die entsprechenden Werte indexieren.

<add>
   <doc>
      <field name="id">1</field>
      <field name="priority">Hoch</field>
   </doc>
   <doc>
      <field name="id">2</field>
      <field name="priority">Sehr Hoch</field>
   </doc>
</add>

Eine einfache Suche mit einer Sortierung wird nun das Dokument mit der id „2“ vor dem Dokument mit der id „1“ anzeigen.

http://localhost:8983/solr/collection1/select?q=*:*&sort=priority+asc

Fazit

Dieser Feldtyp ist noch sehr frisch, aber da steckt eine Menge Potenzial darin. Ich bin gespannt, was unsere Tests bezüglich des Speicherverbrauchs bei diesem Feldtyp zeigen. Vor allem dann, wenn wir es mit vielen Dokumenten zu tun haben; auch hier verspreche ich mir eine Verbesserung gegenüber der alten Situation.

In der aktuellen Implementierung fehlt die Möglichkeit die Reihenfolge in der XML-Datei dynamisch zu verändern. Wenn die Reihenefolge in der XML-Datei verändert wird, muss der Dokumentenbestand neu indexiert werden.

Weiterführende Informationen:

https://issues.apache.org/jira/browse/SOLR-5084

Veröffentlicht am 13.12.2016 von Patricia Kaufmann und Bianca Kaustrup

Es ist wieder soweit, Weihnachten steht vor der Tür.
Und wieder flattern täglich all die Wunschzettel der Kinder ins Haus - so viele verschiedene Wünsche, so viele verschiedene Vorlieben.

Hatte die kleine Sophie nicht erst letztes Jahr die Puppe gewollt? - Heuer ist es schon der Schminkkasten!

Und Florian wollte doch erst vor zwei Jahren das Cowboykostüm - heute ist es bereits eine Drohne.

Und Elisa? - Von ihr kam dieses Jahr gar kein Wunschzettel. Aber ich weiß was ihr gefallen könnte, denn ich habe Sie beobachtet. Elisa hat sich erst letzten Monat zwei DVDs gekauft - von diesem berühmten Schauspieler Tim Croise. Und es ist gerade ein neuer Film von ihm erschienen - den werde ich ihr einfach schenken.

Und dann ist da noch Dennis. Er hat Outdoorschuhe, eine Jacke und Wanderkarten auf seinen Wunschzettel geschrieben. Aber weil er besonders brav war, bringe ich ihm noch den Rucksack mit, über den sich Melanie und Björn letztes Jahr auch so gefreut haben. 

Aber was soll ich mit Hermann anstellen? Er hat mir schon lange keine Wunschzettel mehr geschickt - nun er ist auch kein kleiner Junge mehr. Aber ich weiß noch, dass er sich immer für Search und Big Data interessiert hat, da wird ihm das Buch „Einführung in Apache Solr“ ganz besonders gut gefallen.
Ein perfektes Geschenk für Hermann!

Wie ich das anstelle?

Klar, meine vielen Wichtel sind eine große Hilfe, aber ohne moderne technische Hilfsmittel könnten wir das niemals schaffen! Bei 7 Milliarden kleinen und großen Kindern mit voll beschriebenen Wunschzetteln braucht es schon mehr als einen Weihnachtsmann und seine Wichtel, um nichts durcheinander zu bringen. Und die ganzen Informationen müssen in kürzester Zeit ausgewertet werden! Aber da wir alle ehrenamtlich arbeiten und Kekse und Milch außerhalb des Nordpols nicht als Währungsmittel anerkannt werden, musste eine kostenlose Technologie her – Apache Solr nennt sich das Ganze.

Ich bin vielleicht ein alter Mann mit weißem Bart - aber ich bin nicht verstaubt und altmodisch!

Mit diesem Solr ist es kein Problem, die ganzen Wünsche zu speichern, egal in welcher Sprache sie geschrieben sind. Alle Briefe kommen in unserem Postfach in Apache NiFi an und werden von dort aus automatisch an die verschiedenen Wunsch-Cluster geschickt. Auch die „Artig und Unartig“-Liste habe ich mittlerweile in einem Solr-Knoten untergebracht. Als Dennis von „artig“ zu „ganz besonders brav“ aufgestiegen ist, konnte ich das ohne merkbare Zeitverzögerung in meinem System sehen!

Und wenn ein Kind mir mal keinen Wunschzettel schreibt, so wie Hermann, bekomme ich Vorschläge – meine Wichtel nennen das immer Recommendations – anhand der Wunschzettel vergangener Weihnachten. Damit ist es jetzt sogar möglich, prädiktiv zu analysieren, was die Kinder sich nächstes Jahr so alles wünschen werden und ich kann schon mal Vorbereitungen treffen.

Und ja, ich gebe es zu. Die kleine Elisa bekommt nur deshalb den richtigen Film, weil mir so ein ausgefuchster Spellchecker gesagt hat, dass der Schauspieler nicht Tim Croise, sondern Tom Cruise heißt.

Außerdem haben wir jetzt noch einen sogenannten ZooKeeper in unserem Team, der dafür sorgt, dass bei der Verteilung der Wünsche auf die Wunsch-Cluster nichts schiefgeht. Ich wünschte manchmal, dass dieser Zookeeper auch die Verteilung der Geschenke übernehmen könnte, aber weil ich dann gar nichts mehr zu tun hätte, mache ich das dann doch lieber persönlich. 

Und so bekommt jedes "meiner" Kinder nicht nur irgendein Geschenk, sondern genau das, was es sich wünscht oder wünschen wird.

Euer Big Data Clause

Veröffentlicht am 14.11.2016 von Patricia Kaufmann

Seit dem 08. November ist Solr in der Version 6.3 erhältlich. Neben diversen Fehlerkorrekturen und Optimierungen haben auch einige neue Features ihren Weg in die Suchmaschine gefunden. Nach initialen Tests zu den neuen Funktionalitäten soll im Folgenden Feedback zu


•    dem neuen ResponseWriter für xlsx-Formate
•    der neuen Facetten-Funktionalität facet.exists=true und
•    der erweiterten SQL-Query-Syntax


gegeben werden.

Veröffentlicht am 21.09.2016 von Markus Klose

Wie bekommt man in einem Big-Data Szenario seine Daten in Apache Solr? Eine gute Frage, denn Apache Solr bringt zwar im Standardumfang die Möglichkeit mit, Daten aus dem Dateisystem zu indexieren, aber Apache Solr kann beispielsweise kein HDFS crawlen. Verschärft wird das Problem noch durch die Tatsache, dass in Big Data Szenarien Daten oft unstrukturiert und/oder in diversen Data Warehouse Lösungen, wie beispielsweise Apache HIVE, gespeichert werden.

Veröffentlicht am 12.09.16 von Dr. Johannes Peter

Erstmalig in der Geschichte von Apache NiFi ist ein Major Release veröffentlicht worden, sodass ab sofort die Version 1.0.0 zum Download bereitgestellt wird. Im Rahmen erster Tests der neuen Version fallen sofort die Änderungen an der Nutzeroberfläche auf, die nun sehr viel eleganter gestaltet ist.

Veröffentlicht am 09.09.2016 von Markus Klose

Die Qualität einer Suche hängt von der Trefferliste ab. Selbstverständlich erwartet der Anwender das „richtige“ Dokument an erster Stelle. Aber auch die Informationen, die in der Trefferliste je Dokument angeboten werden, sind wichtig. Bisher musste man alle Informationen, die man in der Trefferliste anzeigen möchte, auch im Index ablegen. Dies führt zu einem größeren Index, schlechterer Performance und zu einer komplexeren Indexierungs-Strategie. Bestimmte Informationen, wie der „Preis eines Dokumentes“ oder das „Alter einer Person“, ändern sich regelmäßig und daher muss der Index immer wieder aktualisiert werden.


Mit den DocTransformern wird nun eine Möglichkeit geboten die von Apache Solr generierte Trefferliste zu beeinflussen, d.h. Felder bzw. Inhalte können generiert werden, die es nicht im Index gibt. Felder können manipuliert werden bevor sie an den Client geschickt werden. Felder können aber auch gelöscht werden. Mit DocTransformern kann der Index also kleiner  werden, was sich wiederrum positiv auf die Performance auswirkt, und unter Umständen wird auch die Indexierung vereinfacht und beschleunigt.

Veröffentlicht am 09.09.2016 von Markus Klose

Vor circa einer Woche, am 25. August 2016, wurde die neue Version 6.2 von Apache Solr veröffentlicht. Enthalten ist wie immer eine Reihe von Verbesserungen, Bugfixes und neuen Features.


Eine der Neuerungen im neuen Release ist der Upgrade der Apache Tika Version von 1.7 nach 1.13. Somit unterstützt Apache Solr nun noch mehr Datei-Formate bei der Indexierung.

Detaillierte Informationen zu dem Versions-Upgrade findet man im JIRA Ticket SOLR-8981.

Veröffentlicht am 30.08.2016 von Markus Klose

Apache NiFi MiNiFi. Hierbei handelt es sich nicht um einen Tippfehler, sondern um den Namen eines Unterprojektes von „Apache NiFi“, welches am 10.06.2016 in der Version 0.0.1 veröffentlicht worden ist.  Mit Apache NiFi MiNiFi werden sogenannte Agenten für die Daten-Extraktion möglich. Agenten sind leichtgewichtige Programme mit der Aufgabe Daten aus den unterschiedlichsten Quellen zu lesen und weiterzuleiten.

Veröffentlicht am 02.08.2016 von Dr. Johannes Peter

Am 12. Juli 2016 wurde die Version 0.7.0 von Apache NiFi veröffentlicht, das auf Grund seiner einfachen Bedienbarkeit, seiner Performanz und seiner Datensicherheit zunehmend im Big Data Kontext und darüber hinaus Verwendung findet. Apache NiFi ermöglicht es, Workflows zu generieren, um Daten zu extrahieren, zu transformieren und weiterzuschicken. Darüber hinaus eignet sich NiFi, zum Monitoren und Überwachen von Prozessen. 

Veröffentlicht am 25.07.16 von Patricia Kaufmann

Ausfallsicherheit ist eines der wichtigsten Kriterien für die Wahl einer SolrCloud-Lösung statt der Nutzung der Solr-Single-Core-Variante. Durch das Hinzufügen von Replikas lassen sich die Indizes der einzelnen Shards einer Collection duplizieren und sichern damit die Daten für den Fall, dass ein Solr-Knoten ausfällt.


Doch was, wenn gezielt ein bestimmter Zustand der SolrCloud gesichert werden soll, sodass er zu einem späteren Zeitpunkt wieder eingespielt werden kann? Bislang war der API-Aufruf zum Erstellen und Einspielen von Backups nur für einzelne Cores möglich, also auf den Single-Core-Modus von Solr zugeschnitten. Nutzer der SolrCloud mussten sich mit dem händischen Kopieren der Indizes behelfen oder jeden zu einer Collection gehörenden Core einzeln sichern – möglich, aber unpraktisch.

 

Veröffentlicht am 29.06.16 von Patricia Kaufmann


TolerantUpdateProcessor

Seit Mitte Juni steht Solr in der Version 6.1.0 zum Download bereit. Da es sich nur um ein Minor Release handelt, halten sich die Neuerungen in Grenzen. Ein zusätzliches Feature verdient es dennoch, erwähnt zu werden – die TolerantUpdateProcessorFactory. Wie der Name schon verrät handelt es sich hierbei um einen neuen Updateprozessor, der sich ab sofort mit in die diversen Update-Ketten einreihen lassen kann. 


Der neue Updateprozessor dient weniger selbst der Veränderung eingehender Daten, als dass er vielmehr die Fehlertoleranzgrenzen anderer Prozessoren in der Kette festlegt. Damit ist es beispielsweise möglich, uninteressante Datensätze schlichtweg zu ignorieren statt komplizierte Bedingungen zu formulieren.


Mit einem zusätzlichen Parameter „maxErrors“ kann außerdem festgelegt werden, wie tolerant der Prozessor tatsächlich sein soll. Ein Angeben von „maxErrors=10“ bricht die Indexierung beim 11. Fehler ab und sendet die entsprechende Meldung.

Veröffentlicht am 18.05.2016 von Patricia Kaufmann
Wie bereits in vorangegangenen Blogbeiträgen vorgestellt, bietet Solr 6 einige neue Features. Außer der neuen SQL-Suchsyntax, dem neuen Scoring-Algorithmus und der Möglichkeit zur Graphentraversierung wurde auch die Streaming API um einige Befehle erweitert. Hinzugekommen sind unter anderem verteilte Joins und ein Ausdruck update zum Aktualisieren einer Collection in der SolrCloud.

Veröffentlicht am 06.05.16 von Markus Klose

Das Release 6.0 von Apache Solr ist nun seit kurzem veröffentlicht. Mit dieser Version gibt es einige neue Funktionalitäten, aber auch einige teils gravierende Änderungen bestehender Funktionalitäten. Eine dieser Änderungen betrifft das Scoring. In Solr 6.0 ist der Default des Scoring-Mechanismus von der TF-IDF-Berechnung auf BM25 umgestellt worden.
Im Januar hat meine Kollegin Patricia Kaufmann bereits von diesen Änderungen berichtet. In diesem Blog möchte ich tiefer einsteigen und aufzeigen was genau sich ändert und wie man das Scoring bereits heute ändern kann.

Blog - Alle Antworten auf einen Blick

SEARCH & BIG DATA, BERATUNG, SCHULUNG, ENTWICKLUNG, SUPPORT, PUBLISHER SOLUTIONS
MIT APACHE SOLR, LUCENE, ELASTICSEARCH, SMARTLOGIC SEMAPHORE, SHI INFOPILOT