Embed Size (px)
DESCRIPTION
Mit einem Bericht aus der Praxis wird dargestellt, wie die Umstellung auf Elastic Search in einem bestehenden Produkt gelungen ist. In einem High-Performance-Umfeld mit Massendaten in komplexen Strukturen wurde die bestehende Suchtechnechnologie durch Elastic Search abgelöst. Ziele der Umstellung waren bessere Suchperformance, Datenverfügbarkeit, Reduzierung bestehender technologischer Komplexitäten, höhere Flexibilität und leichtere Erweiterbarkeit. Im Spannungsfeld von Anspruch und Wirklichkeit ergeben sich eine Reihe von Erkenntninssen und Best-Practice-Ansätzen, die der Votragende mit Ihnen teilen möchte.
Citation preview
ma
ird
um
on
t.co
m
ADAC Kartografie
Baedeker
DuMont
Falk
Kompass
Marco Polo
4trips.de
Baedeker.com
Discover-Outdoor.com
DuMontReise.de
Falk.de
Lonelyplanet.de
Kompass.de
Marcopolo.de
Stefan-Loose.de
Falk Mobile
Marco Polo Mobile
iPad Apps
iPhone Apps
Switch to Elastic Search
Mairdumont Digital 2014
ma
ird
um
on
t.co
m
Content
User
Technology
Points of Interests (POI)
Destinations
Travel Content
Photos / Videos
Traveling Tours / Tracks
Events
Central Authentication Service
User Profile
User generated content
Data Management
High Performance SearchServices
ma
ird
um
on
t.co
m
Points of Interest
Mehr als 5.5 Mio Master Records
Mehr als 70 Mio related Records
von Partnern und Usern
Contributions
Kommentare
Likes
Votes
Bilder
Video
Mehr als 1.8 Mio Bilder zu POIs
ma
ird
um
on
t.co
m
Reiseinformationen
Mehr als 520,000 Destinationen weltweit,
organisiert im Destination Tree
Typen von Destinationen:
￭ Weltregionen (9),
￭ Länder (218), Admin 1 Regionen (2943),
￭ Orte (518,000)
￭ Reisedestinationen (2300)
(z.B. Bodensee, Schwarzwald, Masuren, …)
Travelcontent mit
mehr als 4,000 Destinationen mit
Beschreibungstexten und Tipps
aus den bekannten
Marco Polo Reiseführern
Mehr als 48.000 Bilder zu Destinationen
Mehr als 65,000 Events
wie Konzerte, Ausstellungen, Festivals etc.
ma
ird
um
on
t.co
m
Touren und Tracks
~ 1 Mio Tracks weltweit
Geografische Suche
Kategorien
￭ Hiking, City Tours,
￭ Mountainbike, Streetbike,
￭ Inline Skating,
￭ Jogging,
￭ Motorbike, Auto
ma
ird
um
on
t.co
m
Partner Channel Customers
Lunchtime
ma
ird
um
on
t.co
m
Technologie
ma
ird
um
on
t.co
m
MD Content API Architektur mit Hibernate Search
Glassfish 3.0.1
Hibernate 3.6.0
Hibernate-Search 3.3
Lucene 3.0.2 (patched)
13 Slaves, 1 Master
Index Update ~ 1h
POI Index: ~ 8 - 12 G
￭ Optimize Index Process
￭ High Network Traffic
ma
ird
um
on
t.co
m
MD Content API Architektur mit Hibernate Search
Architekturelle Nachteile
￭ Hibernate-Search führt zu einer engen Kopplung
von Programmcode und Indizierung
￭ Optimierung von Suchen
ist aufwändig
ma
ird
um
on
t.co
m
Architectural Feeling
ma
ird
um
on
t.co
m
Architectural Feeling
Stable!
Yes, but…
Proven!
Scalable?
It depends on…
Really fast?
Yes, but…
Flexibility?
ma
ird
um
on
t.co
m
Ziele der Umstellung auf Elastic Search (ES)
Schnellere Suche
Optimale Verfügbarkeit (Indexverteilung)
Höhere Flexibilität und Skalierbarkeit
Höhere Ausfallsicherheit
ma
ird
um
on
t.co
m
Vorteile Elastic Search (ES)
ES bietet einen einfacheren Betrieb des Clusters
ma
ird
um
on
t.co
m
Vorteile Elastic Search (ES)
Flexibles Master-Slave Verhalten des ES Clusters(Jeder Knoten kann die Master-Rolle übernehmen)
ma
ird
um
on
t.co
m
Vorteile Elastic Search (ES)
Das Verteilen von Indexteilen (Shards) auf mehrere
Knoten übernimmt das Search-Framework
selbständig
ma
ird
um
on
t.co
m
Vorteile Elastic Search (ES)
Einfache Erweiterung des Clusters um neue Knoten
ma
ird
um
on
t.co
m
Vorteile Elastic Search (ES)
Alle Objektinformationen werden im Search-
Framework vorgehalten,
Suchergebnisse (POI, Destination, Event, etc.) können
ohne Datenbank-Zugriff ausgeliefert werden
ES sorgt für die Trennung von Mapping-
Informationen / Entitäten
ES bietet eine Pluginschnittstelle anz.B. für die direkte Anbindung an eine
relationale Datenquelle
ma
ird
um
on
t.co
m
Der Plan
Beibehaltung der Schichten Web-
Services und Service-Facade
Anpassung der Service-Objekte
Beibehaltung PostgreSQL
Über River werden Änderungen
(CRUD) in der Datenbank ermittelt
und in die ES-Indizes übernommen.
Entkopplung der Objekte POI und
Destination, lose Kopplung über
geografische Informationen (Umkreis,
BoundingBox, Polygon)
Aufbau eines Messframeworks und
spezifischer Messpunkte in der
Applikation über UDP-Unicast
Polygon-Berechnung für alle
bestehende City-Destinationen aus
POI-Informationen
ma
ird
um
on
t.co
m
How the development team feels.
ma
ird
um
on
t.co
m
Lesson 1 – Focus the most critical parts first
Das SQL-Statement (mit vielen JOINs) erwies sich bei der Ausführung als zu langsam
komplexe SQL-Statements sind zudem fehleranfällig und unübersichtlich
Die Indexbeladung erfolgt direkt aus der Applikation heraus.
Dazu verwenden wir POJOs, die in ihrer Struktur den Indizes entsprechen, und wandeln
diese mit GSON für die Indizierung über den BulkProcessor nach JSON um.
ma
ird
um
on
t.co
m
Lesson 2 – Sizing mit realen Daten
Hat ElasticSearch nicht genug Hauptspeicher, so werden Abfragen signifikant
verlangsamt
„It is what it is: a in-memory-database“
Facetten, gecachte Filter, usw. brauchen zusätzlichen Speicher zur Laufzeit.
Beispiel Elastic Search Cluster:
Hardware8 ES-Server
32 GB RAM
8 Kerne
POI Index22 GB
74 Mio Dokumente
4 Replica pro Shard (88 GB)
8 Shards (~ 3GB)
Cache
Filter (~ 3 GB)
Field (~ 1 GB)
ma
ird
um
on
t.co
m
ma
ird
um
on
t.co
m
Lesson 3 – Inspect and adapt
Nested
Pro:
￭ Nested Docs werden im selben
Lucene Block abgelegt
￭ Lese / Query Performance besser
als bei Parent / Child
Con:
￭ Update erfolgt auf dem gesamten
Objekt (parent und nested
children)
￭ Daten sollten sich nicht oft ändern
Parent / Child
Pro:
￭ Child-Docs werden separat vom
parent gespeichert (selber Shard)
￭ Updates auf Einzeldokumenten
￭ “Joins” sind möglich
Con:
￭ Schlechtere Lese / Query
Performance
￭ Memory overhead (Join list)
￭ Sorting / Scoring ist schwieriger(hängt vom Anwendungsfall ab)
http://www.elasticsearch.org/blog/managing-relations-inside-elasticsearch/
ma
ird
um
on
t.co
m
Lesson 3 – Inspect and adapt
„Folge dem Plan“ hat seine Grenzen
„It works!“ beats „graceful architecture“
Komplexe Datenstrukturen & komplexe Sichtbarkeiten
￭ Parent-Child beste Struktur für „Joins“
￭ erwies sich als deutlich zu langsam.
￭ Speicherverbrauch und CPU-Last waren deutlich höher als vergleichbare Ansätze
mit Nested documents.
Entscheidung:
￭ Umstellung von Parent-Child auf Nested Documents
￭ Nachteil: Gesamtes Nested Objekt wird geladen
▪ separate Prüfung von Channel und Visibility in der Applikation
￭ Teilweiser Verzicht auf Nested Verlust der Eindeutigkeit in den Treffern
Performancegewinn: Faktor 8-10
ma
ird
um
on
t.co
m
Lesson 4 – Use Filter (if possible)
Einschränkung über ein Feld
{
"query":{
"term:{
{field-name}: {value}
}
}
}
High performance equivalent using filters
{
"query”{
"filtered": {
"query": {"match_all": {}},
"filter": {
"term": {
{field-name}: {value}
}
}
}
}
}
}
Pro:
Deutlich schneller als Field Queries
durch Filter-Cache
Add more RAM
Con:
Kein Scoring
ma
ird
um
on
t.co
m
Bigdesk – Live View
ma
ird
um
on
t.co
m
ma
ird
um
on
t.co
m
Lesson 4 – Create a update strategy for your application
Eine neue Version der Such-Applikation
￭ anzupassende Indexstruktur,
￭ im laufenden Betrieb – kein Maintenance Mode möglich
Lösung:
￭ Zugriff auf unsere Indizes (POI, Destination, Media, …) über Aliase regeln.
￭ Vorteil:
▪ Bei Indexänderungen kann der neue Index im Hintergrund beladen werden
▪ Anschließend das entsprechende Alias vom alten zum neuen Index umhängen
ma
ird
um
on
t.co
m
Lesson 4: Use Index-Aliases
ma
ird
um
on
t.co
m
Lesson 5 – Visualisiere Ergebnisse
Erstelle ein einfach zu benutzendes GUI
￭ Höhere Benutzungshäufigkeit
￭ „Gefühlte“ Performance ist im Fokus
￭ Wenn hier langsam, sind Performance-Tests auch langsam
ma
ird
um
on
t.co
m
Lesson 6 – Give performance a value
Versuche nicht, auf größtmögliche Performance zu optimieren
Klare Wertvorgaben geben den handelnden Personen ein Ziel
Beispiel:
￭ Ziel:
BoundingBox Suche mit 80 POI-Ergebnissen < 500ms
￭ Noch akzeptabel:
BoundingBox Suche mit 80 POI-Ergebnissen < 800ms
ma
ird
um
on
t.co
m
ma
ird
um
on
t.co
m
ma
ird
um
on
t.co
m
Lesson 7 – Keep it simple (KIS)
Erkenntnis
￭ Datengrundlage für diesen
Zweck nicht ausreichend
Lösung:
￭ Destination ohne Polygon
Umkreissuche
￭ Keine komplexen
Algorithmen
Plan: Ständig besser werden
ma
ird
um
on
t.co
m
Lesson 8 – Optimizing last
Beispiel Polygonsuchen
2 Standardverfahren
￭ geo polygon filter
￭ geo shape type +
geo_shape Filter oder
geo_shape Query
Erkenntnis
￭ Filter zur Polygonsuche werden
wohl nicht gecached
￭ GeoShape-Suchen haben
leicht schlechtere Performance
Verfolge den Standard
Evaluiere Alternativen
Optimiere den am besten funktionierenden Standard
ma
ird
um
on
t.co
m
Lesson 8 – Optimizing last
Beispiel Polygonsuchen
Optimierung Geo-Polygon-Filter
￭ Verzichte auf Genauigkeit (wenn möglich im km-Bereich)
￭ Einfügen eines BoundingBox-
Filters vor dem Polygon-Filter
hilft
￭ Der Polygon-Filter sollte immer
am Ende der Filterkette
angefügt werden
Verfolge den Standard
Evaluiere Alternativen
Optimiere den am besten funktionierenden Standard
ma
ird
um
on
t.co
m
Node-Client
Pro:
￭ deutlich schneller(Ø ca. 60 ms pro Anfrage)
￭ Zusammenführen im Node-Client
Weniger Kommunikationsschritte
Con:
￭ Bidirektionale Verbindungen müssen in
Firewalls beachtet werden
￭ Höherer Verwaltungsaufwand im Cluster
Lesson 8 – Optimizing last / Example II
Transport-Client
Pro:
Kein Rückkanal
Client ist nicht Teil des Clusters
Con:
Zusammenführen im Cluster
CPU Last im Cluster höher
Zusätzlicher Kommunikationsschritt
ma
ird
um
on
t.co
m
Lesson 9: ZDF
ma
ird
um
on
t.co
m
Lesson 9: ZDF
ma
ird
um
on
t.co
m
Lesson 9: ZDF
ma
ird
um
on
t.co
m
Lesson 10 – stay up-to-date
Beobachte Framework Lifecycle
Update von Elastic Search 0.20 auf 0.90 führte zu Verbesserung
￭ Speicherverbrauch von ES wurde deutlich verringert
￭ Profitieren von neuen Features (sort auf Feldern eines nested object)
Update von Elastic Search 0.90 auf 0.90.5
￭ Bugfix in Elastic Search
Glassfish 3.0.1 auf Glassfish 3.1.2.x
￭ Aktuellere abhängige Komponenten
￭ Stabilität, Performance
￭ Aktuell: Analyse Glassfish 4
Buche ein Elastic Search Training
Hol dir Unterstützung von Experten
Behalte deine Kunden im Auge
ma
ird
um
on
t.co
m
One More Thing
ma
ird
um
on
t.co
m
Lesson 11 – Do some cool stuff
ma
ird
um
on
t.co
m
Lesson 11 – One More Thing
ma
ird
um
on
t.co
m
ma
ird
um
on
t.co
m
ADAC Kartografie
Baedeker
DuMont
Falk
Kompass
Marco Polo
4trips.de
Baedeker.com
Discover-Outdoor.com
DuMontReise.de
Falk.de
Lonelyplanet.de
Kompass.de
Marcopolo.de
Stefan-Loose.de
Falk Mobile
Marco Polo Mobile
iPad Apps
iPhone Apps
Credits:
Ralf Beutler [email protected]
https://www.xing.com/profile/Ralf_Beutler
https://www.google.com/+RalfBeutler
https://confluence.mairdumont.com/confluence/display/
ON/Online-Dokumentation
http://www.widas.de/
http://www.elasticsearch.org/
