ApacheCon Europe 2012

Die Apache Software Foundation kurz ASF (apache.org), die als Synonym für freie Software genauso wie die Free Software Foundation (fsf.org) steht, hat die diesjährige Konferenz zufällig in der Heimatstadt von Timo Kiefer Sinsheim im Stadion der TSG Hoffenheim 1899 stattfinden lassen.

Die ASF beherbergt eine ganze Reihe von freien Software-Projekten wie z.B. der sehr bekannte Apache Webserver und die Office-Alternative OpenOffice.org. Namhafte Unternehmen wie Yahoo, Microsoft, Google, IBM, HP, AMD, Facebook, um nur die bekanntesten zu nennen, unterstützen die ASF. Auf der Konferenz gab es grob die folgenden Themenblöcke: OpenOffice.org, Lucence, Solr & Friends, Linked Data, BigData, ApacheEE, Cloud, Web Infrastructure, OFBiz und Community. Ich interessierte mich für die Vorträge im Bereich: Lucence, Solr & Friends, Linked Data und habe mir unter anderem folgende angesehen bzw. angehört:

Im Folgenden habe ich die Informationen der einzelnen Projekte, die es so zu hören gab in den Abschnitten zusammengefasst.

Lucence
Es ging los mit einem Vortrag über „Lucence Fundamentals“, fachlich sehr schön, mit der Mathematik, die so dahinter steckt. Soviel ist hängen geblieben: es gibt ein Boolean Model, Vector Space Model und Probabilistic Model an Hand denen die Relevanz berechnet wird. Danach wurde es für mich wesentlich interessanter als bei „Tipps & Tricks Query Parser“, auf konkrete Anwendungsbeispiele eingegangen wurde, wie Query Parser eingesetzt werden können.

Apache Solr
Kurz vielleicht noch für die, die nicht so im Thema drin sind: Ein Query Parser versucht eine Sucheingabe für den Suchindex entsprechend aufzubereiten, dazu gehört z.B. gewisse Begriffe aus der Eingabe zu filtern.
So gibt es z.B. die Magic-Fields (_val_ und _query_) mit denen u.a. Nested Queries ausgeführt werden können, eventuell sogar mit anderen Query Parsern.
Der Standard Query Parser ist ja der „lucence“ der in Solr verwendet wird. Dabei gibt es noch ein paar weitere wie: dismax, edismax (Extended dismax Query Parser), term, surround, join, spatial und frange. Über diese gab es dann jeweils mehr und weniger Informationen.

dismax Query Parser

  • Unterstützt für den geübten Sucheingabe-Helden die folgenden Syntax: +word, -word oder „word“
  • Es können Minimum-Ergebnisse zwischen AND und OR definiert werden
  • Boosting-Functions (Boosting d.h. im Suchkontext, ein Dokument aufzuwerten, so dass dieses in der Ergebnis-Listen-Reihenfolge früher erscheint): z.B. Ein Dokument Erstellungsdatum ist jünger, somit ist dieses Dokument relevanter
  • Debugging Optionen

edismax Query Parser

  • Unterstützt die Syntax des Standard lucence Query Parser und des dismax Query Parser
  • Limit User Fields
  • Stop Words

surround Query Parser

  • Wildcards, Infix, Prefix
  • Geordnet, ungeordnet

join Query Parser

  • Erlaubt Joins über Cores

spatial Query Parser

  • Hiermit kann der Geo-Kram gemacht werden

frange Query Parser

  • Damit können Wertbereiche mit angegeben werden

Diese Query Parser können z.B. über die oben angesprochenen Magic-Fields, oder aber über eine Request-Handler-Konfiguration verwendet werden, so dass z.B. beim Request mit /document immer der dismax Query Parser verwendet wird.
Es gab noch ein paar coole Beispiele wie die Query Parser angewendet wurden, die Lust darauf machten es selbst in konkreten Anwendungsfällen auszuprobieren.

Im Vortrag „Dokument Relations“ ging es dann darum wie Joins einer Abfrage gemacht werden können. So dass z.B. alle Produkte gefunden werden können, die mit Produkt-Varianten referenziert sind, die als Attribut die Frabe blau haben. Dabei gibt es einmal einen Index time join bei der Indizierung der Dokumente und einmal einen Query time join bei der Suchanfrage.

Wer Solr 4 als NoSQL Datenbank einsetzen möchte fand im Vortrag „Solr 4: The NoSQL Database“ die Antworten dazu. Konkret wurde entsprechend die Version 4 von Solr dafür vorbereitet um diesen auch als „vollwertigen“ Datenbankserver zu verwenden. Einige der Keyfeatures sind:

  • Atomic Updates (die leider noch nicht von Lucence direkt unterstützt werden, so dass intern das Dokument abgerufen wird, geändert und wieder neu indiziert werden muss – dies ändert sich aber in einer der kommenden Lucence Versionen)
  • Es gibt nun ein Transaction Log, so dass commits nicht mehr verloren gehen
  • Eine weitere schöne Sache des Transaction Log ist, dass nun auch „Echtzeit“ (NRT = Near Realtime) Abfragen möglich sind
  • Optimistic Concurrency, d.h. wenn explizit eine Version mit dem Parameter _version_ angegeben wurde, kann es zu dem HTTP Fehler-Code 409 kommen: Version Missmatch
  • „Schemalos“, Dynamische Feldnamen enthalten z.B. einen Suffix _i dieser bedeutet dann dass das Feld ein Integer ist, so kann jedes Dokument von einem anderen Typ sein. Wenn ein Feld auf null gesetzt wird so wird dieses gelöscht.
  • softCommit, commitWithin, autoCommit
  • Index von Shapes
  • Mehrere Werte pro Feld sind möglich
  • Funktionen für die Relevanz: z.B. termfreq(feld,text) gibt an wie oft der Text in einem Dokument vorkommt
  • Boolean Conditions Functions: if(expression, trueValue, falseValue)
  • Pseudo Fields: z.B. Aliasing, attr_*, geodist()
  • Pseudo Join: {!join from id to=blog_id}started:[2010 TO *] für alle Blogeinträge seit 2010
  • Pivot Faceting

Achja, die offiziellen Manuals über Solr 4 sollen in den nächsten 2 Wochen online gehen.

ElasticSearch

Wer noch keinen Plan hatte von ElasticSearch, so wie ich, und nur das Buzz Word kannte für den gab es eine geniale Einführung zum Thema. Das ganz schön praxisbezogen, wie die Jungs von proquest.com, mit ElasticSearch durchgestartet ist.
Kurz die Features:

  • Scaleable, Automatic Sharding, RESTful und alles im JSON Format
  • Schemalos, automatische Feldtyp Erkennung
  • Integrierte Facetten, Arrays, Routing, Aliases, Cross Indexing, Multiple Doc Type

Eine Indizierung von 1 Millionen Einträgen dauert auf einem gewöhnlichen Notebook gerade mal 40 Sekunden!
Flexible Datumsformate, d.h. falls ein Datum ein gültiger Zeitstempel ist wird es in das eine Feld eingetragen, falls es z.B. nur ein Textstück ist wie „letzten Sommer“ wird es in ein anderes Feld eingetragen.

Dann ist noch kurz auf die Unterschiede Solr und ElasticSearch eingegangen worden. Im Wesentlichen ist das Fazit für kleinere Projekte, so wie diese auch bei proquest verwendet werden, ist es eine coole Sache ElasticSearch zu verwenden. ElasticSeach ist aber noch jung und an der ein oder anderen Stelle noch nicht so gut vorbereitet wie Solr. Da es noch nicht viele einsetzen gibt es auch noch nicht so viele Blogeinträge, wie z.B. eigene Plugins geschrieben werden können – chinesische Schriftzeichen z.B. überlässt man auch lieber Solr. Aber ElasticSearch soll viel einfacher anzuwenden sein als Solr.
http://de.slideshare.net/AnneVeling/elasticsearch-in-production-lessons-learned

Apache Tika
Wer viel indizieren und finden möchte braucht auch Informationsquellen. Das sind oft Dateien in den unterschiedlichsten Formaten. Einfache Text-Dokumente können noch von Hand indiziert werden, bei PDF-Dateien hört das aber schon wieder auf. Damit man sich nicht bei jedem Format Gedanken machen muss, gibt es das Apache Tika Projekt, das mittlerweile ein Teilprojekt von Apache Lucence ist. Dieses Tool liest nahezu jedes offene Datei-Format und extrahiert den Text und die Metadaten so, dass diese z.B. über einen RequestHandler direkt an Solr für die Indizierung übergeben werden können. Eine nette Demo um etwas mit Tika zu spielen gibt es hier: http://gibthub.com/jukka/tika-demo.

eCommerce und Suche
In der Vorlesung „Compound Terms Query Parser for Great Shopping Experience“ ging es um den speziellen Einsatzbereich der Suche im eCommerce Bereich. Ein präzises Suchergebnis ist im eCommerce Bereich relevanter denn je und ganz besonders auf Mobilen Endgeräten.
Dann wurden die speziellen Probleme der eCommerce Suche aufgezeigt. Da im eCommerce Bereich meistens Produkte mit Attributlisten beschrieben sind auf der ein Eintrag aus einer Bezeichnung wie z.B. Farbe: und einem Wert z.B. blau besteht, bekommt die Bezeichnung eine viel höhere Relevanz da diese viel viel häufiger in Dokumenten vorkommt.
Mit interessanten und einfach zu verstehenden Beispielen wurde aufgezeigt wie naiv eine Suche funktionieren würde, die nicht auf die speziellen Bedürfnisse des eCommerce Bereich getrimmt ist. So würde die Suche bei Eingabe von „pink pullover“ nicht nur pinke Pullover als Ergebnisse enthalten, sondern auch Pullover der Marke „Pink Lotus“.
Nachdem alle das Problem nach ein paar Folien verstanden hatten, ging es um die Skizzierung einer Lösung. Diese besteht zum einen aus der Erweiterung der Suche iterativ, d.h. z.B. zuerst wird mit einer UND-Verknüpfung der Terme gesucht. Werden keine Ergebnisse gefunden wird mit einer OR-Verknüpfung der Terme gesucht, usw. bis etwas gefunden wird. Da der Aufwand einer Suche in Abhängigkeit der gefundenen Ergebnisse ist d.h. O(documents_found log document_size) sind mehrere Suchanfragen vertretbar. Desweiteren ist es wichtig die Gewichtung für ein exaktes Ergebnis höher zu bewerten als für ein Ergebnis bei dem Wörter ausgelassen wurden, etwa 50% zu 30%.
https://docs.google.com/presentation/pub?id=1oifLFI0MiA3ZyXZWisHJVRK13P8cki5yCABvABPObKw&start=false&loop=false&delayms=3000#slide=id.g22bda216_2_15

Apache Nutch
Hier wurde der Apache Crawler vorgestellt, quasi der GoogleBot für alle. Es wurde das Projekt vorgestellt – kurz gesagt Apache Nutch ist ein Crawler der auf Apache Hadoop basiert, d.h. auch gerne mal auf mehrere Rechner verteilt werden kann.
Der Crawler kann auf einfache Art und Weise an Solr angebunden werden um entsprechend das gefundene direkt zu indizieren. Dabei wird der PageRank Algorithmus unterstützt. JavaScript wird beim crawlen zurzeit nicht unterstützt. Natürlich kann auch Nutch sehr fein konfiguriert werden, so dass zuerst in die Tiefe gecrawlt wird statt in die Breite. Apache Nutch gibt es bereits seit 10 Jahren und dieses Jahr kam die Version 2.0 raus. Diese unterstützt noch nicht alle Funktionen der Version 1.x, basiert aber z.B. bereits auf dem DataStore Apache GORA (Bibliothek für eine Datenbank unabhängige Speicherung von Daten).
http://de.slideshare.net/digitalpebble/large-scale-crawling-with-apache-nutch

BigData und Suche
Bei „Big Search with Big Data Principles“ ging es um ein Praxisbericht aus einem Projekt mit über 100 Millionen Dokumenten, die durchsucht werden können. Es ging darum, wie man ziemlich große JVM Prozesse am Leben hält, diese gezielt zum Absturz bringt oder an der einen oder anderen Stelle etwas tunen kann. Solr kam unter anderem als key/value Store zum Einsatz. Da dieser ziemlich schnell ist, so schaffte er tausende von Abfragen innerhalb einer Sekunde. Wichtig war auch, dass man Tika vielleicht nicht direkt an Solr anbinden soll, da somit nur der Solr Server langsam wird. Besser ist diese separat auf einem anderen Server laufen zu lassen.
Dann sei es sinnvoller Avro statt JavaBin (Solr verwendet als Standard JavaBin) zu verwenden, da es unter anderem von mehreren Sprachen unterstützt wird und schneller zu lesen ist als JavaBin. Wenn man dann mal so einen großen Index aufgebaut hat, ist es natürlich auch möglich ein Upgrade von diesem zu machen und somit nicht alles neu indizieren zu müssen. Interessant war noch wie die Umgebung aussah, wie entwickelt wurde usw..
Für gewöhnlich hat man meistens eine oder zwei Entwicklungsinstanzen dazu noch ein paar Test-Instanzen. Aber oft kommt das Szenario vor, dass man Dinge nur in einer Live Umgebung testen kann. Dies wurde gelöst in dem für gewisse Zeitpunkte in der Server-Farm (in dem Fall die Amazon EC2) ein paar Produktiv Server als Entwicklung erklärt wurden und aus dem Produktivverbund genommen wurden. Ähnliches bei Load-Tests. Auf ein tolles Plugin für Apache Solr wurde kurz eingegangen: SolrPanl, welches unter anderem die Suchanfragen loggt bzw. analysieren kann. Es ist wichtig zu wissen nach was die Anwender suchen um danach die Suche optimieren zu können.
http://synapticloop.com/project/java/solr-panl/

http://de.slideshare.net/o19s/apachecon-europe-2012-big-search-4-big-data

Apache Stanbol
Ein Forschungsprojekt der EU, das aus einem Text mit weiteren Informationen noch anreichern kann, unter anderem kann es sogar für die Dokumenten-Klassifizierung verwendet werden. Das Projekt besteht aus einigen Apache-Projekten wie Solr, Tika, OpenNLP, Clerezza, Jena, Flex und Apache Sling.
Stanbol kann aus einem Text sog. Entities extrahieren wie z.B. Themen, Personen, Orte, etc. Dafür soll es in Zukunft auch einen TYPO3 Connector (und auch in Drupal 8) geben um z.B. den Redakteur bei seiner Arbeit zu unterstützen.

Am einfachsten ist man probiert mal selbst etwas auf dem Development Server aus um zu sehen wie Stanbol arbeitet:
http://dev.iks-project.eu:8081/enhancervie

Ein Problem des Projektes sei gerade noch das Thema Lizenzen, da Teile der Modelle mit nicht lizenzierten Daten trainiert worden sind. Demnächst soll das Apache Incubator Projekt als vollwertiges Apache Projekt aufgenommen werden.
http://de.slideshare.net/fabchrist/what-apachestanbolcandoforyouapacheconeu12-byfchrist
http://stanbol.apache.org/

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s