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

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 - 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.
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.

Universal AJAX Live Search

Veröffentlicht am 18.05.2017 von Patricia Kaufmann


Das Commerce Special der code.talks in Berlin am 27. und 28. April 2017 war eine rundum gelungene Veranstaltung, die sowohl Entwickler als auch Manager mit ausreichend Informationsmaterial versorgte. Angefangen bei der wohlgewählten Kulisse im Kino in der Kulturbrauerei Berlin über eine Vielzahl an interessanten Vorträgen namhafter Referenten bis hin zur After-Conference-Party überzeugte die code.talks auf ganzer Linie.

Veröffentlicht am 10.04.2017 von Patricia Kaufmann


Seit Ende März glänzt Solr wieder in einem neuen Versionsgewand – das Release 6.5 hat einige interessante Zusatzfeatures zu bieten. Dazu gehört die Einführung von PointFields, Verbesserungen des Highlightings und auch der Bereich Streaming Expressions wurde um einige Funktionalitäten wie significantTerms und arithmetische Operationen erweitert. Besonders hervorzuheben ist aber die langersehnte Möglichkeit, Multi-Term-Synonyme zu definieren.

Veröffentlicht am 16.03.2017 von Markus Klose

Dieser Blog ist eine kurze Einführung in das Tool „Marple“, einem neuen Lucene Index Tool. Es wird beschrieben, was Marple kann und was nicht, verglichen mit dem bisherigen Tool Luke.


Bisher war Luke das Tool der Wahl, wenn es darum ging einen Solr/Lucene Index zu untersuchen ohne dabei Apache Solr zu konfigurieren. Seit einiger Zeit wird an einem neuen OpenSource Tool gearbeitet, welches sich Marple nennt. Am 24.02.2017 wurde nun die erste Version von Marple veröffentlicht. Bevor Sie sich nun aber Marple 1.0 herunterladen und ausprobieren folgt nun eine kurze Einführung in Marple.

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.

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.

 

Blog - Alle Antworten auf einen Blick

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