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

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

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