Search Engines - Abteilung Datenbanken Leipzig

Transcription

NoSQL-Datenbanken
Kapitel 5: Search Engines
Dr. Anika Groß
Wintersemester 2015/16
Universität Leipzig
http://dbs.uni-leipzig.de
5-1
Inhaltsverzeichnis
• Apache Lucene
• Apache Solr
• ElasticSearch
basiert auf
5-2
Quelle: http://db-engines.com/en/ranking/
DB Ranking
• Search Engines
• alle
5-3
Apache Lucene Core
• “High-performance, full-featured text search engine library
written entirely in Java” [Lucene]
– Open source
– Aktueller Release 5.4.0
– Ports/Integration andere Sprachen (C/C++, C#, Ruby, Perl, Python, PHP, …)
• Skalierbare, hoch performante Indexierung
–
–
–
–
Über 150 GB/hour auf moderner Hardware (Indexing Throughput)
Geringe RAM Anforderungen
Schnelle inkrementelle Indexierung (wie Batch Indexierung)
Indexgröße: ca. 20-30% von Größe des indexierten Texts
• Leistungsstarke, korrekte, effiziente Suchalgorithmen
–
–
–
–
•
Ranking der Ergebnisse
Versch. Query-Typen (phrase queries, wildcard queries, proximity queries…)
Sortierung nach allen Fields
…
Quelle: [Lucene]
Genutzt von Twitter, LinkedIn, CiteSeer, Eclipse, …
→ http://wiki.apache.org/lucene-java/PoweredBy
5-4
Suche mit Lucene
Index document
Users
Analyze
document
Search UI
Build document
Index
Build
query
Render
results
Acquire content
Run query
Raw
Content
http://web.stanford.edu/class/cs276/handouts/lecture-lucene.pptx
5-5
Inverted Index
• Index-Struktur für Terme einer Dokumentenkollektion
– Statt “page-centric” (page→words) → “keyword-centric” (word → pages)
– Zuordnung: Term  Liste der Dokumente, die Term enthalten
– Erweiterungen: Termhäufigkeit im Dokument, Position im Dokument, ...
• Suchanfrage nach Termen kann effizient durch Index realisiert werden
– Unterstützung von AND, OR und NOT durch Mengenoperationen
• Beispiel
Dokumente
d1:“A A B C”
d2:“B D D”
d3:“A B B E”
Inverted Index
A  d1,d3
B  d1,d2,d3
C  d1
D  d2
E  d3
5-6
Anfrage
A AND B
{d1,d3}  {d1,d2,d3}
= {d1,d3}
Inverted Index - Beispiel
http://karthikkumar.me/images/intro-to-lucene/inverted_index.jpg
5-7
Lucene Komponenten
Indexierung
• Directory: Speicherort Index
• Document: zu indexierendes Dokument
(field collection)
• Field: Abschnitt eines Dokument (name, value)
• IndexWriter: Indexerzeugung+verwaltung
(add, remove, update von Dokumenten im Index)
• Analyzer: Textanalyse zur Extraktion der
Indexterme (Tokenisierung, Stemming,
Stoppwort-Extraktion, …)
Suche
• QueryParser: Parsen der Anfrage,
Erzeugung eines Query-Objekts
• IndexSearcher: Zugriff auf Index mit Query-Objekt
• Hits (TopDocs): Gerankte Liste von
Ergebnisdokumenten
http://blogs.msdn.com/b/windows-azure-support/archive/2010/11/01/how-to-use-lucene-net-in-windows-azure.aspx
5-8
Lucene Index
•
•
Zusammengesetzt aus mehreren Sub-Indices = Segmente
Jedes Segment ist ein unabhängiger Index, der separate durchsucht werden kann
• Segment:
– Field names + values
– Term dictionary: alle Terme + Pointer auf Frequency+Proximity Data
– Term Frequency data: # Dokumente, die Term enthalten + Häufigkeit des
Terms im aktuellen Dokument
– Term Proximity data: Position eines Terms in jedem Dokument
– Normalization factors: für Score-Berechnung
– Term Vectors: Vektor mit Termtext und Termhäufigkeit für jedes Field in jedem Dokument
•
Hinzufügung neues Dokument zu Index
– Erzeugung eines neuen Segments
– Bei jedem flush von IndexWriter
•
•
Periodischer Merge existierender Segmente
Suche bezieht mehrere Segmente ein
5-9
Ranking / Scoring – Vector Space Modell
• Repräsentation von Objekten als Vektoren
• Information Retrieval
– Dokument: Term-Vektor mit Gewicht (z.B. TF*IDF)
– Finden ähnlicher Dokumente: (Fast) Duplikate (Plagiate), Clustering, Anfragen, ...
• Recommendations und soziale Netzwerke
– Nutzer-Präferenzen und Items (z.B. Filme) als Vektoren
– Finden potenziell interessanter Filme für Nutzer, potenzielle Freunde, ...
• Ähnlichkeit = Kosinus-Ähnlichkeit der Vektoren
Quelle: Wikimedia
• Beispiel:
Dokumente
d1:“A A B C”
d2:“B D D”
d3:“A B B E”
sim(d1, d3)
Vektoren
d1:[2 1
d2:[0 1
d3:[1 2
A B
1
0
0
C
0
2
0
D
0]
0]
1]
E
𝑑1 =
22 + 12 + 12 + 02 + 02 = 6
𝑑3 =
12 + 22 + 02 + 02 + 12 = 6
𝑠𝑖𝑚(𝑑1, 𝑑3) =
5-10
2∙1+1∙2+1∙0+0∙0+0∙1
6+ 6
=
4 2
=
6 3
Lucene Query Language
• Keyword matching
– Search for phrase "foo bar" in the title field
title:"foo bar"
– Search for either the phrase "foo bar" in the title field AND the phrase "quick fox" in the
body field, or the word "fox" in the title field
(title:"foo bar" AND body:"quick fox") OR title:fox
– Search for word "foo" and not "bar" in the title field
title:foo -title:bar
• Wildcard Search
– Search for any word that starts with "foo" in the title field
title:foo*
• Proximity matching
– Search for "foo bar" within 4 words from each other
"foo bar"~4
• Range searches
mod_date:[20020101 TO 20030101]
• …
http://www.lucenetutorial.com/lucene-query-syntax.html
5-11
Inhaltsverzeichnis
• Apache Lucene
• Apache Solr
• ElasticSearch
basiert auf
5-12
Apache Solr
• „Solr is the popular, blazing-fast, open source enterprise
search platform built on Apache Lucene™“[Solr]
– Open source
– Aktueller Release 5.4.0
– Java Implementierung
•
•
•
•
REST-like API, Java API (SolrJ)
System- und Workflow-Konfiguration (xml-configs)
Seit 2010 Subprojekt von Lucene
SolrCloud seit Version 4.x: Sharding, Replikation
– Performance, horizontale Skalierung, hohe Verfügbarkeit, Ausfallsicherheit &
Fehlertoleranz, Elastizität
• Anwendungen & Nutzer
– Index für Suche
– Analyse: Systemangriffe, häufigste Suchanfragen, Trends …
– Nutzer: Netflix, Instagramm, AOL …
5-13
[Solr]
Workflow
• Sammeln der Daten (Akquise)
– Zugriff auf Datenquellen und Data Processing
– Echtzeitnahe Indexierung der “Rohdaten”
• Datenanreicherung
– Weiterverarbeitung der Daten (komplexe Verfahren - längere Prozesse)
zum Erzeugen von Zusatzinformationen zur Verbesserung der Suche/Navigation
• Speicherung in zusätzlichem Datastore z.B. HDFS
– Indexierung der angereicherten Daten
Solr
Anwendung
Nutzer
Datenakquise
Datenspeicher
Anreicherung
Quelle [W15]
5-14
Index
Solr: Collection & Schema
• Collection: logischer Index
– Menge von Dokumenten mit durchsuchbaren Feldern (=Fields)
• Bsp.: Autor, Änderungsdatum, Titel, Abstract, Content …
Dokument
Field
Term … Term
Field
Term … Term
– Zugriff via Collection Name
– Definition von Regeln, nach welchen ein Field durchsucht
wird mittels Field Types
– Kann auf mehrere Shards verteilt sein (SolrCloud)
…
Dokument
…
• Schema-Definition (schema.xml)
– Definition der Fields in Dokumenten: field name, field type, uniqueKey …
<fields>
<field name="id" type="string" indexed="true" stored="true"
required="true" />
<field name="name" type="textgen" indexed="true" stored="true"/>
...
</fields>
– Dynamic Fielding: Definition von Regeln zur dynamischen Field-Erzeugung
<dynamicField name="*_i"
type="integer"
indexed="true"
stored="true"/>
Bsp: http://www.pathbreak.com/blog/solr-text-field-types-analyzers-tokenizers-filters-explained
5-15
Schema (Field Types)
– Definition von Field-Typen:
• Verschiedene Analyzer-Typen (für index, query ..)
• Workflow-Definition zur Anwendung versch. Filter Factories (Stopwords, Delimiter..),
Tokenizer (WhiteSpaceTokenizer…)
<fieldType name="textgen" class="solr.TextField" ...>
<analyzer type="index">
<tokenizer class="solr.WhitespaceTokenizerFactory"/>
<filter class="solr.StopFilterFactory" words="stopwords.txt" .../>
<filter class="solr.WordDelimiterFilterFactory" .../>
<filter class="solr.LowerCaseFilterFactory"/>
</analyzer>
<analyzer type="query">
<tokenizer class="solr.WhitespaceTokenizerFactory"/>
<filter class="solr.SynonymFilterFactory" synonyms="synonyms.txt".../>
<filter class="solr.StopFilterFactory“ .../>
...
</analyzer>
</fieldType>
•
Queries werden ebenfalls analysiert & tokenisiert und gegen Tokens des Index gematcht
Bsp: http://www.pathbreak.com/blog/solr-text-field-types-analyzers-tokenizers-filters-explained
5-16
Bild: http://image.slidesharecdn.com/solr-workshop-140604141213-phpapp01/95/apache-solr-workshop-18-638.jpg?cb=1408185803
Faceted Search
Facet
Facet value
(=constraint)
Facet
count
•
•
Suche: www.amazon.de/s/ref=nb_sb_noss_2?field-keywords=festplatte
5-17
Ziel: “Drill down” zu
Untermenge von
Ergebnissen einer Query
facet constraints in jeder
Reihenfolge
anwendbar/entfernbar
Field Faceting
•
•
•
•
Spezifiziert ein Field, das in Facet genutzt werden soll
Jeder indexierte Term ist ein Field Value/Constraint
Field muss indexiert sein
Kann mehrmals & versch. Fields genutzt werden
bzw.
Quelle: Yonik Seeley, The Many Facets of Apache Solr, Apache Lucene Eurocon, 2011
5-18
http://de.slideshare.net/lucenerevolution/seeley-solr-facetseurocon2011
Field Faceting (2)
• facet.query – verwenden eines Query Ausdrucks als Facet Constraint
– Mehrfachanwendung: Erstellung von Teilmengen / Kategorien
– Jede Query-Form möglich
Range Faceting
Außerdem
• Range Faceting
• Spatial faceting
• Date faceting
• Pivot faceting
Quelle: Yonik Seeley, The Many Facets of Apache Solr, Apache Lucene Eurocon, 2011
5-19
http://de.slideshare.net/lucenerevolution/seeley-solr-facetseurocon2011
Solr Cloud
• Menge von Features zur Konfiguration und Verwaltung von Solr
in verteilter Umgebung
– Fehlertoleranz und hohe Verfügbarkeit
– Verteilte Indexierung und Suche
– Horizontale Skalierbarkeit
Collection = verteilter Index
• Konfiguration wird in ZooKeeper
gespeichert
• Anzahl Shards: Dokumente
werden auf N Partitionen des
Index verteilt
• Document Routing Strategy:
bestimmt wie Dokumente den
Shards zugeordnet werden
• Replication Factor: Anzahl Kopien
von jedem Dokument in Collection
Cluster: Menge von SolrNodes
Node (= Solr server): JVM Instanz
a.d. Solr läuft
Core: individuelle Solr-Instanz
(repräsentiert einen logischen Index);
mehrere Cores auf einem Node
5-20
http://de.slideshare.net/saumitra121/scaling-search-with-solrcloud
Sharding & Replikation
• Shard: Teil/Partition einer Collection
– Besteht aus einem oder mehreren Replica
– Jeder Shard hat Name, Hash Range, Leader, Replication Factor
– Ein Dokument wird genau einem Shard pro Collection zugeordnet mittels
hash-basierter Document Routing Strategy
• Shard Leader: Replica, das die Leader Election gewonnen hat
– Shard Replica leiten Indizierrequest an Leader weiter
– Leader führt als erster Update auf Dokumentenbestand durch
– Weiterleitung des Indizierrequest an Shard Replica (parallel)
• Replica haben mit geringer Zeitverzögerung Stand des Leaders
• Shard Replica: Kopie von Shard
– Für Ausfallsicherheit und erhöhten Durchsatz von Suchanfragen
– Aber je mehr Replica, desto geringer ist die Indiziergeschwindigkeit
– z.B. Collection "test" mit numShards=1 und replicationFactor=2
• Zwei Cores, jeweils auf anderer Solr Instance:
• test_shard1_replica1 & test_shard1_replica2, wovon einer zum Leader gewählt wird
Bild: http://prismoskills.appspot.com/lessons/Solr/imgs/shard_split3.png
5-21
[W15]
SolrCloud Architektur
5-22
Bild: http://i.stack.imgur.com/AMwjc.jpg
ZooKeeper in SolrCloud
• Repository für Clusterzustand: Verwaltung der Konfiguration von Collections und
allen Teilen der SolrCloud
– Redundanz: mind. 3 Knoten empfohlen
– Kann auf gleicher Hardware wie Solr laufen
– Zusicherung dass ack’ed Requests verarbeitet werden (atomar & dauerhaft),
d.h. kein Datenverlust
• Zentralisierte Konfiguration
–
–
–
–
Speichern der config files in ZooKeeper
Solr nodes holen sich config während Initialisierung
Config sets können für mehrere Collections genutzt werden
Upload von Änderungen in ZooKeeper (reload collections)
• Management Clusterzustand
– Collection Metadaten und Replika Status
– Überwachen der live nodes
– Einsatz für Failover Szenarien u.a. Leader Election
• Kein Split-Brain Szenario durch Paxos Konsensus (bei Netzwerkpartitionierung
nur Major Partition verfügbar)
5-23
Document Routing
• Jeder Shard hat Hash Range
• Default: Hash ID  32-bit integer, Mappen auf Range
• Alternativ: Custom-hashing
Bild: http://prismoskills.appspot.com/lessons/Solr/imgs/document_router.png
5-24
Document Routing - Custom Hashing
• Dokumente werden spezifischen Shards basierend auf einer shardKeyKomponente (Prefix) in der Dokumenten-ID zugeordnet (Hash:
shardKey!docID)
– Jeweils 32 Bit Hash → CompositeID aus 16 Bit des ShardKey Hash
und 16 Bit des DocID Hash (ShardKey Bits entscheidend für Shard-Zuordnung)
– z.B. alle Dokumente eines Kunden in einem Shard → Custumer Name/ID als Prefix
• Kunde “IBM” mit Dokument “12345” → "IBM!12345“
– Direkte Anfragen an spezifische Shards mit Prefix und _route_ Parameter
• q=solr&_route_=IBM!
• kann Query Performance verbessern aufgrund geringerer Netzwerklatenz,
da nicht alle Shards angefragt werden müssen
– 2 Routing Level möglich: z.B. "USA!IBM!12345"
• Scale-up durch mehr Replicas für spezifische Shards mit höheren
Query- und/oder Indexierungsanforderungen
• Schlecht balancierte Shards können aufgeteilt werden (zusätzlicher /num
Parameter in Prefix)
5-25
Shard Splitting
•
Aufteilung eines existierenden Shards in zwei Teile, die als zwei neue Shards
persistiert werden: SPLITSHARD-Befehl
– /admin/collections?action=SPLITSHARD&collection=name&shard=shardID
•
Neue Shards haben Transaction Log mit Updates von Parent Shard
– In diesem Zustand nehmen sie keine Queries an!
•
•
•
•
•
Leader für beide Sub-Shards: Anwendung der gepufferten Updates aus
TransactionLog
Erstellung der Replica
Switch des Shard-Zustands: Parent Shard inaktiv, neue Sub-Shards aktiv
Parent Shard kann gelöscht werden
Zur Laufzeit ausführbar, keine Downtime
Node 1
Shard 1
Leader
Node 2
Shard 1
Replica
shard1 range:
80000000-ffffffff
Shard 2
Replica
Shard 2
Leader
shard2 range:
0-7fffffff
Node 1
Node 2
Shard 1_0
Leader
Shard 1_0
Replica
shard1_0 range:
80000000-bfffffff
Shard 1_1
Leader
Shard 1_1
Replica
shard1_1 range:
c0000000-ffffffff
Shard 2
Replica
Shard 2
Leader
shard2 range:
0-7fffffff
5-26
Timothy Potter: Introduction to SolrCloud, ApacheCon, 2014; http://events.linuxfoundation.org/sites/events/files/slides/ApacheCon_IntroSolrCloud.pdf
Transaction Log
•
•
•
•
Ziel: Update Durability, Recovey
Dokumente, die nicht committed sind, gehen nicht verloren
Jeder Node hat eigenes tlog
Bei Update: Schreiben des ganzen Dokuments in tlog
– Nicht nur das “delta” (bei atomic update)
• tlog zur Aktualisierung von Index, falls JVM gestoppt wird
bevor Segment committed
– Anwendung tlog kann sehr lange dauern
• Hard commit
– tlog wird beendet, neues tlog gestartet (alte tlogs später gelöscht)
– close und flush von aktuellem Index-Segment
– Ggf. Merge von Segmenten
• Soft commit:
– “less expensive than hard commits“
– Dokumente sind sichtbar, aber tlog wird nicht beendet!
– Cache Aktualisierung nötig
5-27
Verteilte Indexierung
Node 1
1. Hole Clusterzustand von
ZooKeeper
2. Leite Dokument direkt an
Leader (hash auf doc ID)
3. Persistiere Dokument auf
Storage (tlog)
4. Weiterleitung an Replica
5. Acknowledge write an
Client
Node 2
Shard 1
Leader
5
Shard 2
Replica
Shard 1
Replica
4
Shard 2
Leader
shard1 range:
80000000-ffffffff
shard2 range:
0-7fffffff
3
tlog
tlog
2
1
CloudSolrServer
„smart client“
View of cluster state from Zk
Zookeeper
Get current URLs of leaders?
5-28
Verteilte Anfragen
1. Query Client holt
Clusterzustand von ZooKeeper
oder via load balancer
2. Client kann Query an
irgendeinen Node senden
3. Query Controller sendet Query
an alle Shards und führt
Ergebnisse zusammen
4. Query Controller sendet
2. Query an alle Shards mit
Dokumenten des gemergten
Ergebnisses, um angefragte
Fields zu erhalten
Query controller
2
Node 1
Node 2
Shard 1
Leader
Shard 1
Replica
Shard 2
Replica
3
4
get fields
Shard 2
Leader
1
q=*.*
CloudSolrServer
View of cluster state from Zk
Zookeeper
Get current URLs of leaders?
5-29
SolrCloud und CAP
• Fokus auf Consistency (CP)
– Alle Replicas eines Shards haben die gleichen Daten
– Reduzierte Schreibverfügbarkeit: writes werden (nur) akzeptiert, solange je Shard
mind. ein aktives Replica verfügbar ist
• Skalierbarkeit
– Alle Knoten führen Indexierung und Queries aus (kein Master)
– Verteilte Indexierung: kein SPoF, hoher Durchsatz durch direkte Updates an Leader
– Verteilte Anfragen: Hinzufügen neuer Replicas für Scale-out; Parallelisierung
komplexer Queries
• Ausfallsicherheit
– Ausfall Replica: erhält keine Anfragen mehr
– Ausfall Leader: Leader Election aus Replica
• Neuer Leader nimmt Indizier- und Suchanfragen an
– Neuer Knoten/Wiederherstellung durch Synchronisation
• Transaction Log für erneutes Indizieren eines Dokuments nach Ausfall
5-30
Solr Admin UI
5-31
Solr - Kombination mit anderen Open-Source-Tools
• Datenanreicherung
– Clustering, Klassifikation, Recommendations mit Apache Mahout
vor allem für zunächst unstrukturierte Daten
– Apache OpenNLP, Apache Stanbo, Apache UMIA: z.B. für Textsegmentierung,
Named Entity Recognition (Extrahieren von z.B. Personen, Orten, Organisationen …
aus Text)
• Datenakquise
– Solr Log Manager: Logstash-Port mit Plugin, um Daten an Solr zur Indizierung zu
senden
– Apache Flume: Senden der akquirierten Daten an Solr und
Übertragen von Daten in HDFS für Anreicherungsprozesse
• Visualisierung mit Banana: Kibana Framework zum Erstellen von
Dashboards
• Einsatz von Hadoop: z.B. MapReduce Jobs / Spark
• für Index Lesen/Schreiben in/aus HDFS
• für Datenanreicherungsprozesse
5-32
Quelle [W15]
Inhaltsverzeichnis
• Apache Lucene
• Apache Solr
• ElasticSearch
5-33
Elasticsearch
• “Elasticsearch is a highly scalable open-source
full-text search and analytics engine.“[Elastic]
• Aktueller Release: 2.1
• Apache 2.0 Lizenz
• Elasticsearch/Logstash/Kibana (ELK) stack
– Datenverarbeitung, Analyse, Visualisierung …
• Nutzer: GitHub, SoundCloud, Stackoverflow, …
– https://www.elastic.co/use-cases
[Elastic]
5-34
Mapping
•
Definition wie Dokument mit seinen Fields
gespeichert und indexiert werden soll
– Volltext-Fields, Numbers, Dates,
Geolocations…
•
•
Definition von Regeln für dynamisch
hinzugefügte Fields
Mapping Typen zur Unterteilung der
Dokumente in logische Gruppen
– z.B. User documents in User type, Blog
posts in Blogpost type
•
•
•
Meta-Fields: z.B. Dokument _index,
_type, _id ..
Fields: je Mapping Type Liste spezifischer
Fields (user type: title, name, age fields..)
Indexierung des gleichen Fields für
versch. Zwecke (Volltextsuche,
Sortierung, Aggregationen…)
PUT my_index
{
"mappings": {
"user": {
"_all":
{ "enabled": false },
"properties": {
"title":
{ "type": "string" },
"name":
"age":
{ "type": "integer" }
}
},
"blogpost": {
"properties": {
"title":
"body":
"user_id": {
"type":
"string",
"index": "not_analyzed"
},
"created": {
"type":
"date",
"format":
"strict_date_optional_time||epoch_millis"
}
}
}
}
}
5-35
Index API
• Hinzufügen oder Ändern eines JSON Dokuments in Index
• Beispiel: Einfügen eines Dokuments in den Index "twitter“
unter dem Typ "tweet" mit id=1
$ curl -XPUT 'http://localhost:9200/twitter/tweet/1' -d '{
"user" : "kimchy",
"post_date" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}'
• Ergebnis
{
"_shards" : {
"total" : 10,
"failed" : 0,
"successful" : 10
},
"_index" : "twitter",
"_type" : "tweet",
"_id" : "1",
"_version" : 1,
"created" : true
}
5-36
Sharding
• Horizontale Partitionierung
– Verteilung des Index auf mehrere Server
– Parallelisierung von Operationen auf Dokumenten
(Indizierung, Aktualisierung, Löschen, Auslesen)
• Verteilte Ausführung von Suchanfragen
– Alle Shards können relevante Dokumente enthalten
• Routing
– shard = hash(routing) % number_of_primary_shards
• routing = Shard key = Dokumenten-ID (default) oder Custom Value
• Range von 0 bis number_of_primary_shards - 1
→ Einschränkung ElasticSearch:
– Kein Shard Splitting: Anzahl der Shards eines Index lässt sich nach initialer
Erstellung nicht ändern
– Hinreichende Anzahl von Shards durch Voranalysen einplanen
5-37
Replikation
Primary 1
Primary 3
• Vorteile
Primary 2
Replica 1
Replica 3
Replica 2
Node 1
Node 2
– Ausfallsicherheit: Failover bei
Ausfall des Primary
– Performanz bei Suchanfragen
• N Replikate pro Shard
– Primary Shard + N-1 Replica
– Anzahl ist dynamisch änderbar
• Index-Operation wird an Primary Shard geleitet (basierend auf Routing)
und ausgeführt
• Anschließend wird update an Replicas verteilt
5-38
Konsistenz
• Synchrone Replikation (sync)
– Aufwendigere Index-Operationen: Änderungen müssen auf allen Kopien
durchgeführt werden
– Alternativ async: ack nach erfolgreicher Ausführung auf Primary
• Inkonsistenzen bei Lesezugriffen auf versch. Kopien desselben Shards
• Near-Realtime Suche: Definition eines Refresh-Intervals: default 1 Sek. bis neu
indexierte Dokumente in Suche erscheinen
• Gelöschte Dokumente tragen zu Index-Statistiken bei
– Löschung von Dokumenten in Lucene: zunächst logische Löschung im Index,
erst später physische Löschung
– Berechnung der Relevanz von Dokumenten wird verfälscht
– Prinzipiell wenig problematisch, aber:
• Physische Löschung auf Replica findet zu unterschiedlichen Zeitpunkten statt
• N-mal hintereinander gleiche Suchanfrage: Ergebnis enthält immer die gleichen
Dokumente, aber jeweils in unterschiedlicher Reihenfolge (je nach Replica)
• Kann über Stunden so bleiben
[P15]
– ElasticSearch: preference-Parameter
• z.B. Nutzer-ID: alle Suchanfragen des
5-39Nutzers landen immer bei dem/den selben Replika
Write Consistency
• Verhindern, dass writes in “falscher” Partition stattfinden
• One, quorum, all
• Default quorum: Indexoperationen nur erfolgreich, wenn ein
Quorum (>replicas/2+1) aktiver Shard Replicas verfügbar ist
(d.h. bevor write überhaupt versucht wird)
• Erfolgreicher write, erst wenn alle aktiven Replicas des Shards
erfolgreich die Änderung durchgeführt haben (sync replication)
5-40
Zen Discovery
• Default, built in Discovery Modul für Elasticsearch
• Discovery: Ping / Gossip Mechanismus zum Auffinden anderer Knoten
• Master Election
– Master: Handling von Knoten, Allokation der Shards
• Einziger Knoten, der Cluster-Zustand ändern kann
• Kein SPoF: bei Ausfall Neuwahl
• Kein Bottleneck: Knoten müssen nicht bei jedem Request mit Master
kommunizieren
– Netzwerkpartitionierung: SplitBrain-Problem
5-41
Split Brain
Netzwerkpartitionierung
• Beide Knoten, denken der andere
Knoten ist nicht verfügbar
→ Node 2 wählt sich als Master
• Beide Knoten nehmen Requests an
→ inkonsistenter Cluster-Zustand
• Minimum_master_nodes = # „master-wählbarer“ Knoten,
die ein Knoten sehen muss, um selbst als Master
gewählt werden zu können
• Quorum (mehr als die Hälfte der Clusterknoten) als
Schutz vor SplitBrain, da max. in einer Partition mehr als
die Hälfte der „master-wählbaren“ Knoten
(nur eine Partition funktionsfähig)
• ABER: schützt nur im Falle vollständiger
Netzwerkpartitionierung vor SplitBrain
– z.B. nur eine Verbindung zw. 2 Knoten gestört
– C sieht A nicht mehr und hat mit B Quorum an Masterwählbaren
Knoten (SplitBrain A + C)
Master
A
B
[P15]
C
5-42
Bilder: http://blog.trifork.com/2013/10/24/how-to-avoid-the-split-brain-problem-in-elasticsearch/
ELK Stack
• Logstash: Data Pipeline zur Prozessierung von Logs u.a. Event-Daten
• Elasticsearch: Speicherung und Indexierung von Daten, komplexe Queries
• Kibana: Erstellen von Custom Dashboards, Datenvisualisierung
5-43
Solr vs. ElasticSearch
Feature
APIs
Format
Third party
Integrations
Schema
Suche
Cluster
Management
Skalierbarkeit
Replikation
Sharding
Failover
Fehlertoleranz
http://solr-vs-elasticsearch.com/
Apache Solr
Elasticsearch
Java, PHP, Ruby, Rails, AJAX, Perl, Scala, Java, Groovy, JavaScript, .NET, PHP, Perl,
Python, .NET, JavaScript, HTTP RESTful API Python, and Ruby, HTTP RESTful API
XML, JSON, CSV
XML, JSON
Kommerziell + Open source
Schema + Schema-frei
Dynamic fields support, Synonyms , Multiple indexes, Faceting, Rich documents support,
Auto Suggest, Highlighting, Default/Custom Analyzers/Tokenizers/Token filters, Fuzzy
Logic, "Did you mean", Stopwords, Geosearch
ZooKeeper
Built-in
Vertikal + Horizontal
+
+
+ (wenn set up im Cluster Replica mode)
+ (wenn set up im Cluster mode)
5-44
Solr vs. Elasticsearch
Feature
Self-contained
cluster
Automatic node
discovery
Partition
tolerance
Automatic
failover
Automatic
leader election
Shard
replication
Sharding
Automatic
shard
rebalancing
Apache Solr
Elasticsearch
o (separater ZooKeeper Server)
+ Nur ElasticSearch Nodes
+ ZooKeeper
+ internes Zen Discovery
o. ZooKeeper
+ Partition mit ZooKeeper Quorum ist
- SplitBrain teilweise verhindert durch
funktionsfähig; P. ohne Quorum nimmt
Min-Anzahl MasterNodes ≥ N/2+1 (N =
keine Indexierrequests o. ClusterClustergröße)
zustandsänderungen an
+ Requests müssen mit shards.tolerant=
+
true Parameter gestellt werden
+
+
+
+ Zuordnung von Tags zu Nodes +
+
Konfig., dass Replicas eines Shards
nicht zu Knoten mit gleichen Tags
zugeordnet werden
5-45
Solr vs. Elasticsearch
Feature
Apache Solr
Elasticsearch
- Keine Änderung der # Shard Primarys
+ Shards können hinzugefügt o. gesplittet
nach initialer Indexerstellung möglich
Change #
werden (Replicas können immer
(Replicas können immer hinzugefügt
shards
hinzugefügt werden)
werden)
Shard Splitting
+
- (Re-indexierung in neuen Index)
+ Erstellung Shard Replica auf
+ Verschieben von Shards and Replicas
Relocate shards
gewünschtem Knoten, anschließend
on demand
and replicas
Löschen des „Source Shards“
+ routing Parameter
Shard routing
+ shards or _route_ Parameter
Synchrone Replikation für IndexierSynchrone Replikation (default),
Requests (Antwort aller Replicas), neue
Consistency
asynchrones Setting möglich
Replicas antworten erst, wenn
Indexreplikation fertiggestellt ist
Data
Rivers modules, Logstash Input Plugins,
Default import/export Handler,
import/export
Custom programs / Snapshot API
Custom import/export Handler
Web Interface
Sense
Solr Admin
5-46
Referenzen
•
•
•
•
[Lucene] https://lucene.apache.org/core/
[Solr] http://lucene.apache.org/solr/
[Solr2] https://cwiki.apache.org/confluence/display/solr/Apache+Solr+Reference+Guide
[W15] Daniel Wrigley: Wer suchet, der findet – Wie Apache Solr und Big
Data unter einen Hut passen. iXDeveloper, Big Data, 02/2015.
• [Elastic] https://www.elastic.co/guide/en/elasticsearch/reference/2.1/index.html
• [P15] Patrick Peschlow: Gesucht, gefunden – Elasticsearch erfolgreich
skalieren. iXDeveloper, Big Data, 02/2015.
• http://solr-vs-elasticsearch.com/
5-47

Search Engines - Abteilung Datenbanken Leipzig

Transcription

Similar documents

Key-Value Stores - Abteilung Datenbanken Leipzig

Vortrag - HTW Dresden

Aktives Management von US-Aktien WERTZUWACHS MIT DEM

Band 2 als PDF herunterladen