MairDumont Switch to Elasticsearch

mairdumont.com
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

mairdumont.com
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

mairdumont.com
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

mairdumont.com
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.

mairdumont.com
Touren und Tracks
 ~ 1 Mio Tracks weltweit
 Geografische Suche
 Kategorien
￭ Hiking, City Tours,
￭ Mountainbike, Streetbike,
￭ Inline Skating,
￭ Jogging,
￭ Motorbike, Auto

mairdumont.com
Partner Channel Customers
Lunchtime

mairdumont.com
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

mairdumont.com
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

mairdumont.com
Architectural Feeling

mairdumont.com
Architectural Feeling
Stable!
Yes, but…
Proven!
Scalable?
It depends on…
Really fast?
Yes, but…
Flexibility?

mairdumont.com
Ziele der Umstellung auf Elastic Search (ES)
Schnellere Suche
Optimale Verfügbarkeit (Indexverteilung)
Höhere Flexibilität und Skalierbarkeit
Höhere Ausfallsicherheit

mairdumont.com
Vorteile Elastic Search (ES)
 ES bietet einen einfacheren Betrieb des Clusters

mairdumont.com
 Flexibles Master-Slave Verhalten des ES Clusters
(Jeder Knoten kann die Master-Rolle übernehmen)

mairdumont.com
 Das Verteilen von Indexteilen (Shards) auf mehrere
Knoten übernimmt das Search-Framework
selbständig

mairdumont.com
 Einfache Erweiterung des Clusters um neue Knoten

mairdumont.com
 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 an
z.B. für die direkte Anbindung an eine
relationale Datenquelle

mairdumont.com
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

mairdumont.com
How the development team feels.

mairdumont.com
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.

mairdumont.com
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:
Hardware
8 ES-Server
32 GB RAM
8 Kerne
POI Index
22 GB
74 Mio Dokumente
4 Replica pro Shard (88 GB)
8 Shards (~ 3GB)
Cache
Filter (~ 3 GB)
Field (~ 1 GB)

mairdumont.com
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/

mairdumont.com
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

mairdumont.com
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

mairdumont.com
Bigdesk – Live View

mairdumont.com
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

mairdumont.com
Lesson 4: Use Index-Aliases

mairdumont.com
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

mairdumont.com
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

mairdumont.com
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

mairdumont.com
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

mairdumont.com
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

mairdumont.com
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

mairdumont.com
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

mairdumont.com
Lesson 11 – Do some cool stuff

mairdumont.com
Lesson 11 – One More Thing

mairdumont.com
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
r.beutler@mairdumont.com
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/

MairDumont Switch to Elasticsearch

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (19)

Semelhante a MairDumont Switch to Elasticsearch

Semelhante a MairDumont Switch to Elasticsearch (20)

MairDumont Switch to Elasticsearch