OOP 2013 NoSQL Suche

Datensuche mit NoSQL

Kai Spichale

27.01.2013

Über mich

► Kai Spichale
► Softwarearchitekt und -entwickler bei adesso AG
► Schwerpunkt: Java-Technologien
► Autor verschiedener Fachartikel, Sprecher auf Konferenzen

► adesso gehört zu den führenden IT-Dienstleistern im deutschsprachigen Raum
► Beratung und individuelle Softwareentwicklung
► Mehr als 1000 Mitarbeiter
► Zu den wichtigsten Kunden zählen die Allianz, Hannover Rück, Union
Investment, Westdeutsche Lotterie, Zurich Versicherung, DEVK und DAK

27.01.2013 1 OOP 2013 Kai Spichale

Motivation

NoSQL Suche

► Exponentielles Datenwachstum ► Datenzugriff ändert sich:
► Semistrukturierte Daten > Volltextsuche wird wichtiger
> Benutzererwartungen steigen
► Stärker vernetzt
► Suche über bekannte
► 80% der unternehmensrelevanten Schlüsselbegriffe oder über ein
Informationen in unstrukturierter Katalogsystem sind für große
Form, hauptsächlich Text Datenbestände unpraktisch


Agenda

► Lucene Volltextsuchen
► NoSQL:
> Architekturtreiber
> MongoDB
> Neo4j
> Apache Cassandra
> Apache Hadoop
► Schlussbemerkung


Volltextsuchen

► Aufgabe: Auffinden von Texten in einer Vielzahl von Dateien oder Datensätzen

► Naiver Ansatz mit linearer Suche à la grep:
> O(n), langsam
> Negation ist schwierig
> Fehlende Unterscheidung von Phrasen und Schlüsselwörtern

► Invertierter Index:
> Term Dokument
> Jedem Term werden Informationen über das Vorkommen des Terms in den
Dokumenten zugeordnet


Apache Lucene

► Java-Bibliothek für Volltextsuchen
► De-facto-Standard im Bereich Open-Source-Suchlösungen

► Merkmale:
> Anwendungsneutral
> Gute Performance

► Funktionalität:
> Bewertete und nach Rang sortierte Suchen
> Viele Abfragetypen, Facettennavigation
> Suche nach einzelnen Feldern
> Sortierung
> Multi-Index-Suchen
> Parallele Suche und Update


Textanalyse

Extrahieren,
Parsen
Dokumente
Character
Filter

Tokenizer

Token Filter

de.GermanAnalyzer:
StandardTokenizer > StandardFilter Invertierter
> LowerCaseFilter > StopFilter > GermanStemFilter Index


Textanalyse

Stopword List
Eat your
ID Term Document
own dog
food. a 1 come 2
and
around 2 dog 1
every 3 eat 1
for
from 4 exception 3
First in
come, 5 first 2
is
first it 5 food 1
served. not
6 own 1
on
one 7 prove 3
the
to 8 rule 3
The
under 9 serve 2
exception
proves the 10 your 1
rule.


Abfragetypen

Abfrage Beispiel
Termsuche +dog –snoopy
(MUST, MUST_NOT, SHOULD)
Phrasensuche „foo bar“
Wildcard fo*a?

Fuzzy fobar~
Range [A TO Z]


NoSQL und Datensuche

„One size fits all“-Ansatz

► Welche NoSQL-Datenbank erfüllt
die Anforderungen am besten?
► Wird Volltextsuche unterstützt?
Performance Volumen

Konsistenz Datenstruktur Datenzugriff

Verfügbarkeit Änderungen


NoSQL und Datensuche

Was bieten diese Datenbanken?
► MongoDB
► Neo4j
► Apache Cassandra
► Apache Hadoop


Dokumentenorientierte Datenbanken

► Speichern Daten in Form von Dokumenten
► Semistrukturierte Inhalte
► JSON, YAML, XML

{ "_id" : ObjectId(„42"),
"firstname" : "John",
"lastname" : "Lennon",
"address" : { "city" : "Liverpool",
"street" : "251 Menlove Avenue“ }
}


MongoDB

► Ad-hoc-Abfragen für Dokumente oder einzelne Felder
db.things.find({firstname:"John"})

► Abfragen mit serverseitig ausgeführten JavaScript-Funktionen
► Aggregationen, MapReduce

► Einfache Textsuchen
> Mit Multikeys können Werte eines Arrays indiziert werden

{ article : “some long text",
_keywords : [ “some" , “long" , “text“]
}


MongoDB

► Mongo-Connector synchronisiert Daten aus MongoDB mit einem Zielsystem
(z.B.: Solr, Elastic Search)
► Architektur mit separaten Suchserver möglich

Doc
update sync erstellen indizieren suchen
1 2 3 4 5

Mongo
MongoDB Connector Solr


MongoDB

MongoDB MongoDB + Lucene Lucene
 Kein Ergebnis-Mergen  Volltextsuchen mit  Kein Ergebnis-Mergen
Stemming, Faceting

 Komplexe Queries mit  Komplexe Queries mit  Volltextsuchen mit
Aggregationen Aggregationen Stemming, Faceting

 Nur einfache  Mergen notwendig  Keine Transaktion
Textsuchen  Erhöhte Komplexität  Keine partiellen
(Entwicklung, Betrieb) Dokumentupdates
 Verwendet Schema


Graphendatenbanken

► Informationen werden als Graphen modelliert
> Knoten
> Kanten (auch Relationships)
> Eigenschaften (auch Properties)

► Universelles Datenmodell id=1 id=3
► Traversierung name=“John“ name=“Paul“

Beispiel: Neo4j

fri

d
►

en
en

fri
d
id=2
name=“George“


Neo4j

► Traversierung:
> Tiefensuche, Breitensuche
> Gremlin, Cypher

START person=node:peoplesearch(name=‘John’)
MATCH person<-[:friends]->afriend RETURN afriend

Ergebnis = George


Neo4j

► Ganze Datenbank ist natürlicher Index bestehend aus Knoten oder Beziehungen
> Beispiele: „name“, „city“

personRepository.findByPropertyValue("name", "John");

► Auto-Indexing verfolgt alle Property-Änderungen


Neo4j

► Unterstützt Lucene-basierte Volltextindizes

@NodeEntity
class Person {
@Indexed(indexName="peoplesearch", indexType=IndexType.FULLTEXT)
private String name;
..
}

Index<PropertyContainer> index = template.getIndex("peoplesearch");
index.query("name", "Jo*");


Wide Column Store

► Google BigTable: „a sparse, distributed multi-dimensional sorted map“
► Daten organisiert in Zeilen, Spaltenfamilien und Spalten
► Ideal für zeilenweises Sharding (horizontale Skalierung)

Unterschiedliche Spalten
pro Zeile möglich

address name
pmccart
„Liverpool ..“ „McCartney“

address name state
Eindeutige jlennon
Zeilenschlüssel „Liverpool ..“ „Lennon“ „UK“

name
gharris
„Harrison“


Apache Cassandra

► BigTable-Klon
► Distributed Hash Table (Amazon Dynamo)
► Schlussendlich konsistent, konfigurierbar

► Datenabfrage:
> Cassandra Query Language (CQL) = SQL-Dialekt ohne Joins

SELECT name FROM user WHERE firstname=„John“;

> Hadoop-Integration


Apache Cassandra

► Solandra: Solr mit Cassandra als Backend statt Dateisystem

► DataStax Enterprise Search
> Daten in Cassandra werden lokal in Solr indiziert und umgekehrt
> Integration durch Secondary Index API
> CQL unterstützt Solr-Queries

SELECT title FROM solr WHERE solr_query=‘name:jo*';

> Dokumentenweise werden die Cassandra Solr
Daten im Cluster verteilt
Column Family Core
> Nutzt Cassandra Ringinformationen Row Document
für Solr Distributed Search Query
Row Key Unique
Column Field
Node Shard


Apache Hadoop

► Open Source Projekt zur Verarbeitung von großen Datenmengen (BigData) im
Computercluster
► Skalierbar, ausfallsicher
► Umfangreiches Hadoop Ökosystem
► Hadoop Distributed File System, Hadoop MapReduce


Hadoop MapReduce

► Map Phase:
Persistente Daten
> Datensätze werden in Map-Funktion
verarbeitet

Map Map Map Map

► Shuffle/Combine Phase:
> Verteilte Sortierung und Gruppierung Transiente Daten

Reduce Reduce Reduce
► Reduce Phase:
> Verarbeitung des Zwischenergebnisses in
Reduce-Funktion
Persistente Daten


Hadoop MapReduce

► Allgemeine Funktionsweise eines MapReduce-Jobs

map(k, v) -> [(K1,V1), (K2,V2), ... ]
Mapper

Daten Shuffle Reducer Ergebnis

reduce(Kn, [Vi, Vj, …]) ->
(Km, R)

Wie löst man Probleme mit MapReduce?

► Problemklassen ohne Reduce-Phase
> Suchen
> Massenkonvertierung
> Sortieren
> Map-Side Join

► Problemklassen mit Reduce-Phase
> Gruppieren und Aggregieren
> Reduce-Side Join


Hadoop MapReduce: Suchen

► Suche nach „A“

Mapper emittiert nur Records
mit Suchkriterium

Daten 1

1: A,B,C 2 1
2: D,E 4
3
3: B,E 5
4
4: A,D
5: A,C,E 5
Ergebnis = 1, 4, 5


Hadoop MapReduce: Indizieren

► HDFS speichert Rohdaten
► Mapper indiziert Daten mit Lucene
> SolrInputDocument erzeugen und StreamingUpdateSolrServer
aufrufen

MapReduce
HDFS Job

Lucene Lucene
Index


Hadoop MapReduce: Indizieren
@Override
public void map(
LongWritable key, Text val,
OutputCollector<NullWritable,
NullWritable> output,
Reporter reporter)
throws IOException {
Mapper
st = new StringTokenizer(val.toString());
Daten 1 lineCounter = 0;

1: text 2 while (st.hasMoreTokens()) {

2: text doc= new SolrInputDocument();
3
3: text doc.addField("id", fileName +
4
4: text key.toString() + lineCounter++);

5: text 5 doc.addField("txt", st.nextToken());

Ergebnis try {
ist null server.add(doc);
} catch (Exception exp) {
…
}
}}


Apache Tika

► Extrahiert Metadaten und strukturierten Text aus Dokumenten:
> HTML, MS Office Dokumente, PDF, etc.
► Stream-Parser auch für große Dokumente geeignet

Tika

MapReduce
HDFS Job

Lucene Lucene
Index


Apache Solr

► Lucene ist eine Programmbibliothek, kein Suchserver
► Suchserver:
> Solr
> ElasticSearch

Tika

MapReduce
HDFS Job

Solr Lucene Lucene
Index


Apache Flume

► Verteilter Dienst zum Sammeln, Aggregieren
Web Server, und Kopieren großen Datenmengen
Applikationen
► Streaming-Techniken
► Fehlertolerant

Flume

Tika

MapReduce
HDFS Job

Solr Lucene Lucene
Index


Alternativen

► Nutch Crawler erzeugt einen Datensatz
pro URL in CrawlDB
Web Server,
Apps, DBs ► Hadoop DistCp kopiert Daten innerhalb/
zwischen Hadoop-Clustern
► Apache Sqoop transferiert Bulk-Daten
zwischen Hadoop und RDBMS
Flume Crawler DistCp Sqoop

Tika

MapReduce
HDFS Job

Solr Lucene Lucene
Index


Apache Hadoop

► Fundamentaler Mismatch:
> MapReduce ideal für Batch-Verarbeitung
Web Content, > Lucene für interaktive Suchen
Intranet
► MapReduce zum Indizieren von großen
Datenmengen
► Geeignet für (offline) Big-Data-Lösung
Loading
Werkzeug

Hadoop

Suche Analyse Export Visualisierung


Zusammenfassung

► Mehr semistrukturierte Daten
► Bedeutung von Volltextsuchen wächst

► Kombination von NoSQL-Store und Lucene:
> MongoDB: Integration mit Mongo Connector
> Neo4j: native Integration
> Cassandra: „Online BigData“
> Hadoop: „Offline BigData“

► Alternative: Suchserver als dokumentenorientierte Datenbank


OOP 2013 NoSQL Suche

Weitere ähnliche Inhalte

Andere mochten auch

Mehr von adesso AG

OOP 2013 NoSQL Suche