Apache Lucene & Solr - mal eben schnell was finden

Das Lucene-Projekt gibt es schon seit 1999. Mit dem lange erwarteten Release 4 Ende 2012 gab es unter anderem eine bis zu 100x schnellere unscharfe Suche, eine effiziente Indexierung neuer Daten (near realtime search), und eine verbesserte Replikation im Solr Cluster. Seitdem gibt es regelmäßige Minor-Releases.
Grund genug einmal unter die Haube zu schauen: Der Vortrag gibt einen Einstieg wie man Lucene in eine Java-Anwendung einbettet, als Standalone Suchserver betreibt, oder als hochverfügbaren Cluster.

Transcript

1. Apache Lucene & Solr mal eben schnell was finden Alexander Schwartz Java User Group Darmstadt / 12. Dezember 2013 1 © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz
2. 2 Was ich vorhabe 1. Worum es geht 2. Sponsor 3. Problemstellung und Werkzeuge 4. Daten für Suche vorbereiten 5. Fehlertolerante Suche 6. Erweiterte Funktionen der Suche: Navigation und Autovervollständigung 7. Performance und Resourcenbedarf 8. Skalierung der Kapazität und weitere Funktionen 9. Zusammenfassung 10. Fragen & Diskussion © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz
3. 3 Agenda 1. Worum es geht 2. Sponsor 3. Problemstellung und Werkzeuge 4. Daten für Suche vorbereiten 5. Fehlertolerante Suche 6. Erweiterte Funktionen der Suche: Navigation und Autovervollständigung 7. Performance und Resourcenbedarf 8. Skalierung der Kapazität und weitere Funktionen 9. Zusammenfassung 10. Fragen & Diskussion © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz
4. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 4 Worum es hier geht Apache Lucene und Apache Solr • Apache Lucene als Suchindex, mit dem man „wie Google“ Daten indexieren und schnell wiederauffinden kann • Apache Solr als Container um Lucene, um es einfacher anbinden zu können und bei Bedarf auf mehreren Rechnern als Cluster betreiben zu können
5. 5 Agenda 1. Worum es geht 2. Sponsor 3. Problemstellung und Werkzeuge 4. Daten für Suche vorbereiten 5. Fehlertolerante Suche 6. Erweiterte Funktionen der Suche: Navigation und Autovervollständigung 7. Performance und Resourcenbedarf 8. Skalierung der Kapazität und weitere Funktionen 9. Zusammenfassung 10. Fragen & Diskussion © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz
6. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 6 Mein Sponsor und Arbeitgeber 1980 gegründet mehr als 4000 Kollegen 9 Branchen 540 Mio € Umsatz 2012 23 Länder in 13 Städten in Deutschland präsent msg systems ag
7. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 7 Wer ich bin Alexander Schwartz Lead IT Consultant im GB Travel und Logistics 11 Jahre Java 7 Jahre PL/SQL 7 Jahre Absatzfinanzierung 3,5 Jahre Direktbank 1 Frau 2 Kinder 311 gefundene Geocaches
8. 8 Agenda 1. Worum es geht 2. Sponsor 3. Problemstellung und Werkzeuge 4. Daten für Suche vorbereiten 5. Fehlertolerante Suche 6. Erweiterte Funktionen der Suche: Navigation und Autovervollständigung 7. Performance und Resourcenbedarf 8. Skalierung der Kapazität und weitere Funktionen 9. Zusammenfassung 10. Fragen & Diskussion © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz
9. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 9 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
10. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 10 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
11. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 11 Apache Lucene • 1999 Dough Cutting entwickelt Lucene • 2001 Incubator Apache Project • 2005 Top Level Project Apache Apache Solr • 2004 Yonik Seeley erstellt die erste Version bei CNET • 2006 Incubator Apache Project • 2007 Top Level Apache Project • 2010 Zusammenschluss Solr/Lucene Team Historie Solr/Lucene Historie von Apache Lucene und Apache Solr
12. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 12 • 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
13. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 13 • 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
14. 14 Agenda 1. Worum es geht 2. Sponsor 3. Problemstellung und Werkzeuge 4. Daten für Suche vorbereiten 5. Fehlertolerante Suche 6. Erweiterte Funktionen der Suche: Navigation und Autovervollständigung 7. Performance und Resourcenbedarf 8. Skalierung der Kapazität und weitere Funktionen 9. Zusammenfassung 10. Fragen & Diskussion © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz
15. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 15 Ausgangsdaten In diesem Beispiel: Relationale Kundendaten Feld Daten FIRSTNAME Alexander LASTNAME Schwartz TITLE STREET Musterweg HOUSENUMBER 1 CITY Musterstadt ZIP 60386 EMAIL xxx@gmx.net
16. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 16 Datenstruktur definieren Struktur zunächst in schema.xml beschreiben* <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" /> * Alternativ kann Solr auch zur Laufzeit Feldtypen erraten
17. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 17 Bibliotheken einbinden Aufnehmen in die Maven-Dependencies in pom.xml Embedded Solr: <dependency> <groupId>org.apache.solr</groupId> <artifactId>solr-core</artifactId> <version>4.6.0</version> </dependency> Nur SolrJ-Client: <dependency> <groupId>org.apache.solr</groupId> <artifactId>solr-solrj</artifactId> <version>4.6.0</version> </dependency>
18. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 18 Index befüllen Füllen eines SolrDocument und Speichern in Solr 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(); Alternativen: JavaBeans Dateiupload CSV/JSON/XML
19. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 19 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
20. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 20 Solr Admin Konsole Spaltenindex kann im Admin-Frontend angeschaut werden
21. 21 Agenda 1. Worum es geht 2. Sponsor 3. Problemstellung und Werkzeuge 4. Daten für Suche vorbereiten 5. Fehlertolerante Suche 6. Erweiterte Funktionen der Suche: Navigation und Autovervollständigung 7. Performance und Resourcenbedarf 8. Skalierung der Kapazität und weitere Funktionen 9. Zusammenfassung 10. Fragen & Diskussion © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz
22. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 22 Suchen mit Solr/Lucene 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
23. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 23 Solr Admin Konsole Test-Abfragen durchführen im Admin-Frontend
24. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 24 Suchen mit Solr/Lucene Unscharfe Suche mit Levenshtein-Distanz • +LASTNAME:schwartz~1 Im Nachname darf um ein Zeichen abweichen Findet: • Schwartz • 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
25. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 25 Suchen mit Solr/Lucene Tolerante Suche mit Tokenizern und Filtern Für jedes Feld können spezifische Normalisierungen festgelegt werden: <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> Ergebnisse: Hans-Peter → hans, peter Müller → müller → muller Mueller → mueller → muller André → andré → andre
26. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 26 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
27. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 27 Solr Admin Konsole Tokenizer und Filter im Admin-Frontend ausprobieren
28. Achtung Performance: ggf. als ein Feld indexieren © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 28 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
29. 29 Agenda 1. Worum es geht 2. Sponsor 3. Problemstellung und Werkzeuge 4. Daten für Suche vorbereiten 5. Fehlertolerante Suche 6. Erweiterte Funktionen der Suche: Navigation und Autovervollständigung 7. Performance und Resourcenbedarf 8. Skalierung der Kapazität und weitere Funktionen 9. Zusammenfassung 10. Fragen & Diskussion © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz
30. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 30 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
31. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 31 Navigieren in Suchergebnissen mit Solr/Lucene Doppeln von Feldern für unterschiedliche Indexierung Zusätzliche Indexierung wird in schema.xml konfiguriert. Danach müssen die Daten erneut indexiert werden. <field name="CITYPLAIN" type="string" indexed="true" stored="false" /> <copyField source="CITY" dest="CITYPLAIN"/>
32. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 32 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, …
33. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 33 Autovervollständigung Beschleunigung der Platzhaltersuche Zusätzliche Indexierung vorberechneter Fragmente: <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> Indexiert: Alexander → al, ale, alex, alexa, alexan, alexand, alexande, alexander
34. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 34 Autovervollständigung Beschleunigung der Platzhaltersuche Suche erfolgt nun ohne Nennung der expliziten Wildcards q +NAMESUGGEST:alexa Findet: • Alexandr • Alexandar • Alexander • Alexandra • …
35. 35 Agenda 1. Worum es geht 2. Sponsor 3. Problemstellung und Werkzeuge 4. Daten für Suche vorbereiten 5. Fehlertolerante Suche 6. Erweiterte Funktionen der Suche: Navigation und Autovervollständigung 7. Performance und Resourcenbedarf 8. Skalierung der Kapazität und weitere Funktionen 9. Zusammenfassung 10. Fragen & Diskussion © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz
36. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 36 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
37. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 37 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
38. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 38 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
39. 39 Agenda 1. Worum es geht 2. Sponsor 3. Problemstellung und Werkzeuge 4. Daten für Suche vorbereiten 5. Fehlertolerante Suche 6. Erweiterte Funktionen der Suche: Navigation und Autovervollständigung 7. Performance und Resourcenbedarf 8. Skalierung der Kapazität und weitere Funktionen 9. Zusammenfassung 10. Fragen & Diskussion © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz
40. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 40 Skalierung Skalieren für große Indexe - viele Suchanfragen - viele Datenänderungen • Vertikale Skalierung (mehr RAM, mehr CPUs in einer Maschine) erfolgt linear, kann jedoch Grenzen der Ausbaufähigkeit eines Knotens erreichen • Mehrere kleine Knoten sind meist günstiger als weniger große Knoten • Bei horizontaler Skalierung kann die Anfrage auf mehrere Rechner verteilt werden und wird anschließend aggregiert Komponenten: Apache SolrCloud • Solr mit aktivierten Clusterfähigkeiten • Datenpool (Core) wird in Shards aufgeteilt • Jeder Knoten kümmert sich als Leader um einen Teil der Daten, und hat ggf. noch Repliken der Daten von anderen Knoten Apache Zookeeper • Koordinierungsinstanz für den Cluster (Leader-Election) • Vorhalten von Konfigurationsdateien
41. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 41 Skalierung Komponenten bei Skalierung mit SolrCloud Client Knoten 1 Knoten 2 Zookeeper Shard 1 (Leader) Shard 2 (Leader) Shard 2 (Replik) Shard 1 (Replik)
42. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 42 • 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
43. 43 Agenda 1. Worum es geht 2. Sponsor 3. Problemstellung und Werkzeuge 4. Daten für Suche vorbereiten 5. Fehlertolerante Suche 6. Erweiterte Funktionen der Suche: Navigation und Autovervollständigung 7. Performance und Resourcenbedarf 8. Skalierung der Kapazität und weitere Funktionen 9. Zusammenfassung 10. Fragen & Diskussion © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz
44. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 44 • 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
45. 45 Agenda 1. Worum es geht 2. Sponsor 3. Problemstellung und Werkzeuge 4. Daten für Suche vorbereiten 5. Fehlertolerante Suche 6. Erweiterte Funktionen der Suche: Navigation und Autovervollständigung 7. Performance und Resourcenbedarf 8. Skalierung der Kapazität und weitere Funktionen 9. Zusammenfassung 10. Fragen & Diskussion © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz
46. © msg systems ag, 12. Dezember 2013 Java User Group Darmstadt / Alexander Schwartz 46 Literatur: Grainger/Potter: Solr in Action (Manning 2013) http://www.manning.com/grainger/ Als „Early Access“ verfügbar, alle Kapitel vorhanden, Softwarestand: Solr 4.4 Fragen & Diskussion Hier ist Raum für Fragen und Diskussion
47. 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: Alexander.Schwartz@msg-systems.com www.msg-systems.com 47 Java User Group Darmstadt / Alexander Schwartz © msg systems ag, 12. Dezember 2013