Wie kombiniert man NoSQL mit Volltextsuchen?

Teil 2

26. Februar 2013Kai Spichale

Im Mittelpunkt des zweiten Teils steht der Wide Column Store Apache Cassandra und die BigData-Plattform Apache Hadoop. Volltextsuchen mit der Lucene-Bibliothek und Suchmaschinen, wie Apache Solr oder elasticsearch, wurden in Kombination mit MongoDB und Neo4j bereits in Teil 1 vorgestellt.

Wide Column Stores

Wide Column Stores, zu denen Apache Cassandra gezählt werden kann. Vorbild für diese NoSQL-Variante ist BigTable, eine proprietäre, nichtrelationale Datenbank von Google, die gebaut wurde, um die besonderen Skalierungs- und Performanceanforderungen von Google erfüllen zu können. Cassandra verwendet ein flexibles Datenmodell, das zeilenweise um (fast) beliebig viele Spalten erweitert werden kann. Weil es keine Referenzen zwischen verschiedenen Datensätzen unterstützt, können diese Datensätze unabhängig voneinander auf unterschiedlichen Speicherknoten verteilt gespeichert werden. Zur Verwaltung der Daten auf mehrere Speicherknoten setzt Apache Cassandra einen DHT (distributed hash table) ein. Die Architektur dieser Verteilung wurde durch Amazon Dynamo inspiriert. Einige Beispiele für den Einsatz von Cassandra sind:

  • Ooyala, eine Online-Video-Plattform mit umfangreichen Analysefunktionen,
  • SimpleGeo, eine Plattform zur Entwicklung standorterkennender Applikationen,
  • und Digg, ein Anbieter für Social Bookmarks.

Cassandra bietet eine SQL-ähnliche Abfragesprache, genannt CQL (Cassandra Query Language). Aufgrund der skalierbaren Architektur kann Cassandra keine Aggregationen und Join-Operationen durchführen, denn diese Operationen würden die unabhängige Speicherung der Datensätze auf unterschiedlichen  Speicherknoten aushebeln. Auch Volltextsuchen werden von Cassandra nicht standardmäßig unterstützt, doch DataStax Enterprise Search kombiniert Solr mit Cassandra. Die Integration basiert auf der Secondary Index API von Cassandra und dem Near Real Time Indexing, einem Feature des Lucene IndexWriter ab Version 2.9. Das Near Real Time Indexing wird von Solr 4.0 unterstützt und stellt sicher, dass neue oder veränderte Dokumente fast unmittelbar nach ihrer Indizierung in Suchen sichtbar sind. Die sog. „soft commits“ vermeiden die zeitaufwändigen Operationen der Standardcommits.

Die Synchronisation von Cassandra und Solr funktioniert in beide Richtungen. Wenn Daten in Cassandra geändert werden, führt dies zu einem automatischen Update des Solr-Index. Und wenn umgekehrt die Dokumente in Solr geändert werden, wird Cassandra nachgezogen. Die Volltextsuchen können nahtlos in CQL genutzt werden. Die Daten in Cassandra werden in einem jeweils lokalen Solr indiziert. Die Verteilungs- und Replikationseinstellungen von Cassandra haben Einfluss auf den Speicherort der Solr Dokumente. Falls Cassandra die Datensätze mit einem RandomPartitioner zufällig im Cluster verteilt, werden ebenfalls die Solr Dokumente zufällig verteilt. Eine Solr Query kann zu jedem Server des Clusters gesendet werden, denn die Verteilungskonfiguration von Cassandra wird transparent für den Client verwendet, um eine passende verteilte Suchanfrage (distributed search query) abzuleiten.

Apache Hadoop

Das Open Source-Projekt Apache Hadoop dient als Grundlage für verschiedene BigData-Lösungen. Es besteht im Kern aus einem verteilten Dateisystem (HDFS) und MapReduce (MR), einem Framework für die Verarbeitung große Datenmengen im Computercluster. Die Weiterentwicklung des umfangreichen Ökosystems wird durch das Projekt Apache Bigtop koordiniert. Weitere Distributionen werden u.a. von Cloudera und Hortonworks angeboten. Hive und Pig bieten eine höhere Abstraktion als native MR-Programme zur Datenanalyse. Hive macht Hadoop zugänglich für Benutzer, die bereits mit SQL vertraut sind. Pig bietet eine Datenflusssprache, mit der Daten schrittweise durch Funktionen wie filter, union, group und join transformiert werden können. Hive und Pig werden zur Ausführung in ein oder mehrere verkettete MR-Jobs übersetzt.

Ein natives MR-Programm kann zum Filtern von Datensätze verwendet werden, um eine einfache Textsuche zu implementieren. Dazu emittiert die Map-Funktion nur dann einen Datensatz, wenn dieser das Suchkriterium erfüllt. Alle Datensätze, die das Suchkriterium nicht erfüllen, werden nicht emittiert und folglich gefiltert. Hadoop durchsucht den gesamten Datenbestand parallel auf mehreren Speicherknoten. Durch diese Parallelität können sehr große Datenmengen in relativ kurzer Zeit durchsucht werden, ohne dass zuvor ein spezieller Index aufgebaut werden muss. Jedoch ist MR im Allgemeinen nicht für interaktive Anwendungen geeignet. Für interaktive Suchen sollte eine Textanalyse durchgeführt und ein invertierter Index aufgebaut werden. Aus diesem Grund könnte Hadoop statt zur direkten Suche, zur Indizierung eingesetzt werden. Mithilfe eines MR-Programms wird der Datenbestand geparst und der zu indizierende Text extrahiert. Das gebildete Dokument wird an eine separate Suchmaschine zur Indizierung übermittelt. Zur Extraktion des Textes könnte beispielsweise Apache Tika verwendet werden, das PDF, HTML und andere Formate lesen kann. Bevor die Daten mit Hadoop verarbeitet werden können, müssen diese in das Hadoop-System importiert werden. Für diese Aufgabe eignen sich verschiedene Technologien, wie Apache Flume, Apache Sqoop oder Hadoop DistCp. Apache Flume ist ein verteilter Dienst zum Transport großer Datenmengen. Flume kann beispielsweise eingesetzt werden, um umfangreiche Logdaten von Webservern in ein Hadoop-System zu kopieren. Apache Sqoop kann Daten aus strukturierten Speichersystemen nach Hadoop migrieren. Hadoop DistCp ist ein hilfreiches Werkzeug zum Kopieren von Daten zwischen verschiedenen Hadoop-Cluster oder innerhalb eines Hadoop-Clusters.

Fazit

Schnelle Volltextsuche à la Lucene ist eine unverzichtbare Technik zum Zugriff auf Daten. Insbesondere in umfangreichen unstrukturierten Daten kann mit Volltextsuchen effizient gesucht werden. Ein Kerngedanke der NoSQL-Bewegung ist, dass keine einzelne Datenbank alle Anforderungen optimal erfüllen kann, sondern dass in Abhängigkeit des Anwendungsfalls eine oder mehrere passende Datenbanken auszuwählen sind. Suchmaschinen sind da keine Ausnahme. Falls Volltextsuchen, wie sie Lucene bietet, notwendig sind, sollte ein dafür spezialisiertes Werkzeug eingesetzt werden. Jede zusätzliche Technologie hat jedoch Einfluss auf die Komplexität der Architektur.

In diesem Beitrag wurden verschiedene Szenarien beschrieben. Neo4j besitzt eine sehr gute Lucene-Integration, so dass für Volltextsuchen keine zusätzliche Technologie hinzugefügt werden muss. Auch MongoDB bietet eine Volltextsuche. Falls diese jedoch nicht ausreicht, empfiehlt sich eine komplementäre Suchmaschine. Allerdings stellt sich dann die Aufgabe, beide Systeme synchron zu halten und durch eine Integrationsschicht sinnvoll miteinander zu verbinden.  Mit dem Ziel die Architektur möglich schlank zu halten, ist zu prüfen, ob eine Lösung ohne MongoDB vielleicht auch ausreichend wäre. Vorgestellt wurde auch Cassandra, die keinerlei Volltextsuchen bietet. Aber dank DSE Search müsste trotzdem keine eigene Solr-Integration gebaut werden. Auch Hadoop kann für Suchen eingesetzt werden. Entweder könnten die Daten mit einem MR-Programm nach bestimmten Suchkriterien filtern oder mithilfe einer externen Suchmaschine indizieren.

Kai Spichale Kai Spichale ist Software Architect bei der adesso AG. Sein Tätigkeitsschwerpunkt liegt in der Konzeption und Implementierung von Softwaresystemen auf Basis von Spring und Java EE. Er ist Autor verschiedener Fachartikel und regelmäßiger Sprecher auf Konferenzen.
Artikel bewerten:
1 Star2 Stars3 Stars4 Stars5 Stars
Loading...Loading...

Kommentar hinzufügen:

Ihr Kommentar: