Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Apache Lucene & Solr - mal eben schnell was finden

Apache Lucene & Solr - mal eben schnell was finden

Die richtige Website finden wir mit wenigen Worten in einem Suchfeld mit unserer Lieblingssuchmaschine in Sekundenbruchteilen. Wenn in Unternehmensanwendungen gesucht wird, dann gibt es komplizierte Suchmasken, die Suche dauert ewig und ist nicht fehlertolerant.

Der Vortrag zeigt, wie man mit Apache Lucene und Solr die Nadel im Heuhaufen am Beispiel von Kundendaten findet. Und das in Sekundenbruchteilen.

Alexander Schwartz

August 27, 2014
Tweet

More Decks by Alexander Schwartz

Other Decks in Technology

Transcript

  1. Apache Lucene & Solr mal eben schnell was finden 1

    © msg systems ag, 26. August 2014 Source Talk Tage 2014 / Alexander Schwartz Alexander Schwartz Source Talk Tage 2014 am 27. August 2014 in Göttingen @ahus1de
  2. 2 Was ich vorhabe 1. Problemstellung und Werkzeuge 2. Daten

    für Suche vorbereiten 3. Fehlertolerante Suche 4. Erweiterte Funktionen der Suche: Navigation und Autovervollständigung 5. Performance und Resourcenbedarf 6. Weitere Funktionen 7. Zusammenfassung 8. Fragen & Diskussion © msg systems ag, 26. August 2014 Source Talk Tage 2014 / Alexander Schwartz
  3. 3 Agenda 1. Problemstellung und Werkzeuge 2. Daten für Suche

    vorbereiten 3. Fehlertolerante Suche 4. Erweiterte Funktionen der Suche: Navigation und Autovervollständigung 5. Performance und Resourcenbedarf 6. Weitere Funktionen 7. Zusammenfassung 8. Fragen & Diskussion © msg systems ag, 26. August 2014 Source Talk Tage 2014 / Alexander Schwartz
  4. © msg systems ag, 26. August 2014 Source Talk Tage

    2014 / Alexander Schwartz 4 Suche in Webpages Aus vielen langen Dokumenten mit wenigen Stichworten das richtige Dokument finden Suche in Logdateien Alle Logdateien der letzten Wochen interaktiv durchsuchen, ohne an ein festes Schema gebunden zu sein. Suche in Stammdaten Den richtigen Kunden innerhalb von Millionen von Kunden finden, auch wenn die Suchkriterien unvollständig sind. Problemstellungen Die Nadel im Heuhaufen finden
  5. © msg systems ag, 26. August 2014 Source Talk Tage

    2014 / Alexander Schwartz 5 Worum es hier geht Wofür Apache Lucene und Apache Solr stehen • Apache Lucene  Open Source (Apache Lizenz)  Kommerziell nutzbar  Datenaufbereitung, Suche, Ergebnisaufbereitung  dokumentenbasiert • Apache Solr  Open Source (Apache Lizenz)  Kommerziell nutzbar  API für Anwendungen  Skalierung über Rechnergrenzen
  6. © msg systems ag, 26. August 2014 Source Talk Tage

    2014 / Alexander Schwartz 6 • Einfache horizontale Skalierung mit Solr Cloud • 100x schnellere unscharfe Suche Levenshtein FuzzyQuery nutzt nun einen Endlichen Automaten • Near Realtime Search Änderungen an den Daten sind schnell (< 1 Sekunde) in den Suchergebnissen enthalten • Push-Replikation Betreibt man mehrere Knoten, so stehen neue Daten sofort allen Knoten zur Verfügung Seit Release 4.0 in 10/2012 alle 2-3 Monate ein Feature-Release Solr/Lucene 4 Das ist neu in Version Apache Solr und Apache Lucene 4
  7. © msg systems ag, 26. August 2014 Source Talk Tage

    2014 / Alexander Schwartz 7 • 2010 gestartet Shay Baron (als Ablösung von Compass) • Nutzt genauso wie Solr im Kern Lucene • Konsequent auf REST, JSON und Skalierung ausgerichtet Gemeinsamkeiten: • Starke Konkurrenz zwischen beiden Teams • Aktive Community • In jedem Release neue Features Unterschiede: • elasticsearch hatte früher mehr Cloud-Features • Solr hat später auf JSON/REST gesetzt • Solr kann einfacher eingebettet werden • elasticsearch hat im Java-API eine Query-DSL elasticsearch Die Konkurrenz: elasticsearch
  8. © msg systems ag, 26. August 2014 Source Talk Tage

    2014 / Alexander Schwartz 8 • Hibernate Search 5 integriert Lucene 4 • Daten werden beim Schreiben transparent indexiert • Alle Lucene-Suchmöglichkeiten stehen zur Verfügung Hibernate Search Die Alternative: Hibernate Search
  9. 9 Agenda 1. Problemstellung und Werkzeuge 2. Daten für Suche

    vorbereiten 3. Fehlertolerante Suche 4. Erweiterte Funktionen der Suche: Navigation und Autovervollständigung 5. Performance und Resourcenbedarf 6. Weitere Funktionen 7. Zusammenfassung 8. Fragen & Diskussion © msg systems ag, 26. August 2014 Source Talk Tage 2014 / Alexander Schwartz
  10. © msg systems ag, 26. August 2014 Source Talk Tage

    2014 / Alexander Schwartz 10 Ausgangsdaten In diesem Beispiel: Relationale Kundendaten Feld Daten FIRSTNAME Alexander LASTNAME Schwartz TITLE STREET Musterweg HOUSENUMBER 1 CITY Musterstadt ZIP 60386 EMAIL [email protected]
  11. <field name="id" type="string" indexed="true" stored="true" required="true"/> <field name="FIRSTNAME" type="text_de" indexed="true"

    stored="true" /> <field name="LASTNAME" type="text_de" indexed="true" stored="true" /> ... <field name="ZIP" type="string" indexed="true" stored="true" /> ... <field name="EMAIL" type="text_general" indexed="true" stored="true" /> © msg systems ag, 26. August 2014 Source Talk Tage 2014 / Alexander Schwartz 11 Datenstruktur definieren Struktur zunächst in schema.xml beschreiben* * Alternativ kann Solr auch zur Laufzeit Feldtypen erraten
  12. Collection<SolrInputDocument> docs = new ArrayList<SolrInputDocument>(); ... SolrInputDocument doc = new

    SolrInputDocument(); doc.addField("id", c.getCustomerExternalId()); doc.addField("FIRSTNAME", c.getCustomerFirstName()); doc.addField("LASTNAME", c.getCustomerLastName()); ... docs.add(doc); ... solr.add(docs); solr.commit(); © msg systems ag, 26. August 2014 Source Talk Tage 2014 / Alexander Schwartz 12 Index befüllen Füllen eines SolrDocument und Speichern in Solr Alternativen: JavaBeans Dateiupload CSV/JSON/XML
  13. © msg systems ag, 26. August 2014 Source Talk Tage

    2014 / Alexander Schwartz 13 Invertierter Index in Lucene Für jeden Begriff ist gespeichert, in welchem Dokument er vorkommt Spalte Vorname alexander 2 peter 7 stephan 3 Spalte Nachname schwartz 2,7 klein 3 ID Vorname Nachname 2 Alexander Schwartz 7 Peter Schwartz 3 Stephan Klein
  14. 14 Agenda 1. Problemstellung und Werkzeuge 2. Daten für Suche

    vorbereiten 3. Fehlertolerante Suche 4. Erweiterte Funktionen der Suche: Navigation und Autovervollständigung 5. Performance und Resourcenbedarf 6. Weitere Funktionen 7. Zusammenfassung 8. Fragen & Diskussion © msg systems ag, 26. August 2014 Source Talk Tage 2014 / Alexander Schwartz
  15. © msg systems ag, 26. August 2014 Source Talk Tage

    2014 / Alexander Schwartz 15 Suchen mit Solr/Lucene Solr/Lucene hat eine eigene Abfragesprache • +FIRSTNAME:alexander +LASTNAME:schwartz Suchergebnis muss beide Worte enthalten • FIRSTNAME:alexander LASTNAME:schwartz Suchergebnis sollte beide Worte enthalten; je mehr desto besser • FIRSTNAME:alexander LASTNAME:schwartz^2 Ein Treffer im Nachnamen ist für das Ranking doppelt so wichtig wie im Vornamen • +FIRSTNAME:a* +LASTNAME:schwartz Vorname muss mit „A“ anfangen, Nachname muss „Schwartz“ sein
  16. © msg systems ag, 26. August 2014 Source Talk Tage

    2014 / Alexander Schwartz 16 Suchen mit Solr/Lucene Unscharfe Suche mit Levenshtein-Distanz • +LASTNAME:schwartz~1 Im Nachname darf um ein Zeichen abweichen Findet: • Schwartz • Schwarz • Schvartz • Schwaitz • Schwarcz • Schwarez • Schwarta • Schwarte (Distanz wird gemessen in „Editierschritten“, d.h. löschen und hinzufügen von Zeichen. Ist gut geeignet für Tippfehler und OCR-Erkennungsfehler.) Lucene begrenzt Levenshtein Distanz auf max. 2
  17. © msg systems ag, 26. August 2014 Source Talk Tage

    2014 / Alexander Schwartz 17 Suchen mit Solr/Lucene Tolerante Suche mit Tokenizern und Filtern Für jedes Feld können spezifische Normalisierungen festgelegt werden: Ergebnisse: Hans-Peter → hans, peter Müller → müller → muller Mueller → mueller → muller André → andré → andre <fieldType name="text_de" class="solr.TextField" > <analyzer> <tokenizer class="solr.StandardTokenizerFactory"/> <filter class="solr.LowerCaseFilterFactory"/> <filter class="solr.GermanNormalizationFilterFactory"/> <filter class="solr.ASCIIFoldingFilterFactory"/> </analyzer> </fieldType>
  18. © msg systems ag, 26. August 2014 Source Talk Tage

    2014 / Alexander Schwartz 18 Suchen mit Solr/Lucene Tolerante Suche gegenüber Umlauten und Sonderzeichen • +LASTNAME:müller • +LASTNAME:mueller • +LASTNAME:müllér Findet (jeweils): • Müller • Mueller
  19. Achtung Performance: ggf. als ein Feld indexieren © msg systems

    ag, 26. August 2014 Source Talk Tage 2014 / Alexander Schwartz 19 Suchen mit Solr/Lucene Tolerante Suche gegenüber fehlenden und unklassifizierten Werten Mit dem „mimimum match“ Parameter kann angegeben werden, dass eine bestimmte Anzahl von Feldern passen muss q: Evyatar Müller Wendelfeldstrasse 139 Musterstadt 07950 qf: FIRSTNAME LASTNAME STREET CITY HOUSENUMBER ZIP mm: 4 Findet: (zusätzlich gewinne ich Klassifikations-Informationen, welche Token zu welchem Feld passen) Vorname Nachname Straße Hausnr. PLZ Ort Gaby Müller Wendefeldstrasse 139 07951 Musterstadt Evyatar Meier Kirchstrasse 139 07951 Musterstadt
  20. 20 Agenda 1. Problemstellung und Werkzeuge 2. Daten für Suche

    vorbereiten 3. Fehlertolerante Suche 4. Erweiterte Funktionen der Suche: Navigation und Autovervollständigung 5. Performance und Resourcenbedarf 6. Weitere Funktionen 7. Zusammenfassung 8. Fragen & Diskussion © msg systems ag, 26. August 2014 Source Talk Tage 2014 / Alexander Schwartz
  21. © msg systems ag, 26. August 2014 Source Talk Tage

    2014 / Alexander Schwartz 21 Navigieren in Suchergebnissen mit Solr/Lucene Mit Faceting Navigation im Suchergebnis erleichtern Das Suchergebnis wird bei Faceting angereichert um die Anzahl der Treffer mit bestimmten Merkmalen q +FIRSTNAME:alexander~2 facet on facet.field CITYPLAIN LASTNAME facet.mincount 1 Findet: Ort Anzahl Berlin 31 Hamburg 16 Stuttgart 13 Nachname Anzahl almenrader 2 gorrissen 2 heidkross 2 Für Faceting wird zusätzlich der Originalwert im Index aufgenommen
  22. © msg systems ag, 26. August 2014 Source Talk Tage

    2014 / Alexander Schwartz 22 Navigieren in Suchergebnissen mit Solr/Lucene Mit Pivoting in mehreren Ebenen navigieren Pivoting ist ein Faceting auf mehreren Ebenen. q +FIRSTNAME:alexander~2 facet on facet.pivot CITYPLAIN,ZIP facet.mincount 1 Findet: Ort Anzahl Postleitzahlen Berlin 31 10319:2, 10249:1, … Hamburg 16 20148:1, 20357:1, … München 12 80331:1, 80333:1, …
  23. © msg systems ag, 26. August 2014 Source Talk Tage

    2014 / Alexander Schwartz 23 Autovervollständigung Beschleunigung der Platzhaltersuche Zusätzliche Indexierung vorberechneter Fragmente: Indexiert: Alexander → al, ale, alex, alexa, alexan, alexand, alexande, alexander <field name="NAMESUGGEST" type="text_suggest_ngram" indexed="true" stored="false" multiValued="true" /> <fieldType name="text_suggest_ngram" class="solr.TextField" positionIncrementGap="100"> <analyzer type="index"> … <filter class="solr.EdgeNGramFilterFactory" maxGramSize="10" minGramSize="2"/> </analyzer> <analyzer type="query"> … </analyzer> </fieldType>
  24. © msg systems ag, 26. August 2014 Source Talk Tage

    2014 / Alexander Schwartz 24 Autovervollständigung Beschleunigung der Platzhaltersuche Suche erfolgt nun ohne Nennung der expliziten Wildcards q +NAMESUGGEST:alexa Findet: • Alexandr • Alexandar • Alexander • Alexandra • …
  25. 25 Agenda 1. Problemstellung und Werkzeuge 2. Daten für Suche

    vorbereiten 3. Fehlertolerante Suche 4. Erweiterte Funktionen der Suche: Navigation und Autovervollständigung 5. Performance und Resourcenbedarf 6. Weitere Funktionen 7. Zusammenfassung 8. Fragen & Diskussion © msg systems ag, 26. August 2014 Source Talk Tage 2014 / Alexander Schwartz
  26. © msg systems ag, 26. August 2014 Source Talk Tage

    2014 / Alexander Schwartz 26 Resourcenverbrauch Genug Arbeitsspeicher ist essentiell für schnelle Suchergebnisse • Solr/Lucene speichern ursprüngliche Daten und Indexdaten in Dateien im Dateisystem • Daten werden erst bei der nächsten Re-Organisation („Optimierung“) gelöscht (findet regelmäßig automatisch bei der Indexierung statt, kann auch manuell gestartet werden) • Bei Linux/Windows 64bit greift Lucene über Memory Mapped Files auf die Daten zu; Betriebssystem beschleunigt via Dateisystem-Cache • Idealerweise passen Index und JVM ins RAM (zur Not schnelle SSD für den Index) Beispiel: 5 Mio. Kundendatensätze • ca. 500 MB im Format CSV • ca. 750 MB als Lucene Index (optimiert) oder ca. 2000 MB, wenn der Index stark entartet ist (viele Löschungen/Aktualisierungen, ist abhängig von Parameterwahl) • ca. 3 GB RAM benötigt
  27. © msg systems ag, 26. August 2014 Source Talk Tage

    2014 / Alexander Schwartz 27 Resourcenverbrauch Je unschärfer die Suche, desto mehr CPU-Zeit wird benötigt Nr. Szenario [Zeiten jeweils in ms *] Durch. Q95% Max. 1 Kundennummer (exakt) und Name (exakt) 4 14 75 2 Kundennummer (unscharf 1 Zeichen) und Name (unscharf 1 Z.) 18 52 128 * Apache Solr 4.1 auf Xeon X3440 @ 2,53GHz ohne Hyperthreading; 5 Mio. Kundenstammdaten; Index passt zusammen mit VM in das RAM; kein Sharding Nr. Szenario [Zeiten jeweils in ms *] Durch. Q95% Max. 1 Kundennummer (exakt) und Name (exakt) 4 14 75 2 Kundennummer (unscharf 1 Zeichen) und Name (unscharf 1 Z.) 18 52 128 3 Name (exakt) und Adresse (exakt) 6 22 99 4 Name (exakt) und Adresse (exakt), aber komplett unklassifiziert 10 31 81 5 Name (unscharf 1 Zeichen) und Adresse (unscharf 1 Zeichen) 29 61 252 Nr. Szenario [Zeiten jeweils in ms *] Durch. Q95% Max. 1 Kundennummer (exakt) und Name (exakt) 4 14 75 2 Kundennummer (unscharf 1 Zeichen) und Name (unscharf 1 Z.) 18 52 128 3 Name (exakt) und Adresse (exakt) 6 22 99 4 Name (exakt) und Adresse (exakt), aber komplett unklassifiziert 10 31 81 5 Name (unscharf 1 Zeichen) und Adresse (unscharf 1 Zeichen) 29 61 252 6 Name (unscharf 1 Zeichen) und Adresse (unscharf 1 Zeichen) und ein Wort darf fehlen) 157 265 373 7 Name (unscharf 2 Zeichen) und Adresse (unscharf 2 Zeichen) und ein Wort darf fehlen 300 400 509 8 Suche Name/Adresse unklassifiziert und unscharf 1 Zeichen und ein Wort darf fehlen 249 379 641 9 Suche Name/Adresse unklassifiziert und unscharf 2 Zeichen und ein Wort darf fehlen 648 873 1322
  28. © msg systems ag, 26. August 2014 Source Talk Tage

    2014 / Alexander Schwartz 28 Resourcenverbrauch Optimierungen mit zusätzlichem Index und neuerer Apache Solr-Version Nr. Szenario [Zeiten jeweils in ms *] Durch. Q95% Max. 9 Suche Name/Adresse unklassifiziert und unscharf 2 Zeichen und ein Wort darf fehlen mit Apache Solr 4.1 648 873 1322 10 Suche Name/Adresse unklassifiziert und unscharf 2 Zeichen und ein Wort darf fehlen mit Apache Solr 4.6 67 89 162 11 Suche Name/Adresse unklassifiziert und unscharf 2 Zeichen und ein Wort darf fehlen mit Apache Solr 4.6, alle Felder in einem Feld (+100 MB Indexgröße) 20 30 86 * Apache Solr 4.1 wie vorherige Folie, Apache Solr 4.6 auf i5-2520M @ 2,50GHz ohne Hyperthreading; 5 Mio. Kundenstammdaten; Index passt zusammen mit VM in das RAM; kein Sharding
  29. 29 Agenda 1. Problemstellung und Werkzeuge 2. Daten für Suche

    vorbereiten 3. Fehlertolerante Suche 4. Erweiterte Funktionen der Suche: Navigation und Autovervollständigung 5. Performance und Resourcenbedarf 6. Weitere Funktionen 7. Zusammenfassung 8. Fragen & Diskussion © msg systems ag, 26. August 2014 Source Talk Tage 2014 / Alexander Schwartz
  30. © msg systems ag, 26. August 2014 Source Talk Tage

    2014 / Alexander Schwartz 30 • Skalierung über Rechnergrenzen mit Solr Cloud • Highlighting – Schlüsselworte im Dokument markieren • „More Like This“ Suche – ähnliche Dokumente zu einem bekannten Dokument finden • Geo-Operationen (Distanz zu einem Punkt, einer Zickzack-Linie, einer geometrischen Figur, Schnitte von geometrischen Figuren) • Join über Cores hinweg • Parent/Child Beziehung innerhalb eines Cores • Clustering von Ergebnissen Blick über den Rand der Präsentation Weitere interessante Funktionen von Apache Solr/Lucene
  31. 31 Agenda 1. Problemstellung und Werkzeuge 2. Daten für Suche

    vorbereiten 3. Fehlertolerante Suche 4. Erweiterte Funktionen der Suche: Navigation und Autovervollständigung 5. Performance und Resourcenbedarf 6. Weitere Funktionen 7. Zusammenfassung 8. Fragen & Diskussion © msg systems ag, 26. August 2014 Source Talk Tage 2014 / Alexander Schwartz
  32. © msg systems ag, 26. August 2014 Source Talk Tage

    2014 / Alexander Schwartz 32 • Such-Funktionen in bestehenden Anwendungen flexibler gestalten • Interaktive Suche beschleunigen • Flexible Regeln für automatische Absendererkennung bei Eingangspost • Neue Möglichkeiten der Datenauswertung • Antworten – beim richtigen Index – innerhalb von 1-100 ms Offene Punkte • Abfragesprache Lucene für Poweruser – für den normalen User verstecken? • Absicherung von Solr (Verschlüsselung, Authentifikation) (hier sind ggf. Patches notwendig) Zusammenfassung Potential von Solr und Lucene für „normale“ Anwendungen
  33. 33 Agenda 1. Problemstellung und Werkzeuge 2. Daten für Suche

    vorbereiten 3. Fehlertolerante Suche 4. Erweiterte Funktionen der Suche: Navigation und Autovervollständigung 5. Performance und Resourcenbedarf 6. Weitere Funktionen 7. Zusammenfassung 8. Fragen & Diskussion © msg systems ag, 26. August 2014 Source Talk Tage 2014 / Alexander Schwartz
  34. © msg systems ag, 26. August 2014 Source Talk Tage

    2014 / Alexander Schwartz 34 Literatur: Grainger/Potter: Solr in Action (Manning 2014) http://www.manning.com/grainger/ Softwarestand: Apache Solr 4.7 Fragen & Diskussion Hier ist Raum für Fragen und Diskussion
  35. www.msg-systems.com Vielen Dank für Ihre Aufmerksamkeit msg systems ag Mergenthalerallee

    73 - 75 65760 Eschborn Telefon: +49 (171) 5 62 57 67 E-Mail: [email protected] www.msg-systems.com 35 Source Talk Tage 2014 / Alexander Schwartz © msg systems ag, 26. August 2014