1 Einführung in die Welt der NoSQL

Hochschule für Technik und Wirtschaft Dresden
Fakultät Geoinformation
Bachelorstudiengang Geoinformation und Vermessungswesen
Bachelorarbeit
Einsatz von NoSQL-Datenbanksystemen für Geodaten
Eingereicht von
Benjamin Thurm
Seminargruppe: 08/061/61
Matrikelnummer: 27021
1. Gutachter: Prof. Dr.-Ing. F. Schwarzbach
2. Gutachter: Prof. Dr. oec. G. Gräfe
Eingereicht am: 23.02.2012
Inhaltsverzeichnis
II
Inhaltsverzeichnis
Inhaltsverzeichnis ....................................................................................................... II
Einleitung ..................................................................................................................... 1
1
Einführung in die Welt der NoSQL-Datenbanken ........................................... 2
1.1
Historischer Abriss ............................................................................................. 2
1.2
„NoSQL“ ............................................................................................................. 3
1.3
Scaling Up/Out ................................................................................................... 4
1.4
CAP-Theorem .................................................................................................... 4
1.5
ACID & BASE ..................................................................................................... 5
1.6
MapReduce ........................................................................................................ 6
1.7
Schemalosigkeit von Daten ................................................................................ 7
2
Allgemeiner Überblick...................................................................................... 8
2.1
Kategorisierung .................................................................................................. 8
2.2
2.2.1
2.2.2
2.2.3
Key/Value Stores................................................................................................ 8
Datenhaltung ...................................................................................................... 9
Redis .................................................................................................................. 9
Spatial Extension.............................................................................................. 10
2.3
2.3.1
2.3.2
2.3.3
Wide Column Stores ........................................................................................ 10
Datenhaltung .................................................................................................... 11
Apache Cassandra ........................................................................................... 12
Spatial Extensions ............................................................................................ 13
2.4
2.4.1
2.4.2
2.4.3
Document Stores.............................................................................................. 13
Datenhaltung .................................................................................................... 14
CouchDB .......................................................................................................... 14
Spatial Extensions ............................................................................................ 15
2.5
2.5.1
2.5.2
2.5.3
Graphdatenbanken........................................................................................... 16
Datenhaltung .................................................................................................... 17
Neo4j................................................................................................................ 19
Spatial Extensions ............................................................................................ 19
3
Anwendungspotential für Geodaten ............................................................. 21
3.1
Definition Geodaten .......................................................................................... 21
3.2
Die Haltung von Geodaten in SQL-Datenbanken ............................................. 22
3.3
Skalierbarkeit vs. Komplexität ........................................................................... 23
3.4
Positionsdaten in NoSQL-Datenbanksystemen ................................................ 24
3.5
Komplexe Geodaten in NoSQL-Datenbanksystemen ....................................... 26
3.6
Rasterdaten...................................................................................................... 30
3.7
Zukünftige Entwicklungen ................................................................................. 30
Inhaltsverzeichnis
III
4
Implementierung einer Webpräsenz für Geodaten mit CouchDB und
GeoCouch ....................................................................................................... 32
4.1
Vorbereitung der Daten für CouchDB ............................................................... 33
4.2
Abfrage der Datensätze aus CouchDB ............................................................. 34
4.3
Abfrage von Datensätzen als FeatureCollection ............................................... 36
4.4
Integration der GeoCouch-Daten in eine Website............................................. 37
4.5
Fazit ................................................................................................................. 39
5
Navigationsanwendung mit Neo4j Spatial .................................................... 41
5.1
Vorbereitungen ................................................................................................. 41
5.2
Datengrundlage ................................................................................................ 42
5.3
Auffinden des nächsten Knoten zu einer beliebigen Koordinate ....................... 44
5.4
Berechnung des kürzesten, befahrbaren Weges .............................................. 46
5.5
Ergebnis ........................................................................................................... 47
5.6
Fazit ................................................................................................................. 48
6
Zusammenfassung und Ausblick.................................................................. 50
Literaturverzeichnis .................................................................................................. VI
Abbildungsverzeichnis .............................................................................................. X
Tabellenverzeichnis ................................................................................................... X
Anlagenverzeichnis................................................................................................... XI
Anhang 1 .................................................................................................................. XIII
Anhang 2 .................................................................................................................. XIV
Erklärung über die eigenständige Erstellung der Arbeit ....................................... XV
Einleitung
1
Einleitung
Google, Amazon und Facebook teilen sich nicht nur den Status, eine der zehn am besten verdienenden Webseiten der Welt zu sein (Bellon 2012), sie haben auch etwas
anderes gemeinsam: Alle drei Großkonzerne haben NoSQL-Datenbanken und die
Nutzung von Geodaten für sich entdeckt. Gerade solche Dienste, die sich Geodaten in
direkter oder indirekter Art zunutze machen haben in letzter Zeit große Aufmerksamkeit
erlangt. So ermöglicht beispielweise mittlerweile jedes Social Network, allen voran Facebook, seinen Nutzern, ihre Position anderen mitzuteilen. Anwendungen wie „Foursquare“ bauen sogar in erster Linie auf die Verknüpfung von sozialer Interaktion und
Geodaten und die W3C Implementierung der Geolocation API mit HTML5 macht es
mittlerweile fast jedem internetfähigem Gerät möglich, ebenfalls seine aktuelle Position
mitzuteilen. Damit steht diese Entwicklung klar im Trend und verursacht dadurch ein
immenses Daten- und Nutzeraufkommen. NoSQL-Datenbanken stellen in diesem Zusammenhang möglicherweise eine Option dar, bisher verwendete SQL-Datenbanken
abzulösen und die so entstandenen „Big Data“ besser zu verwalten.
Das Ziel dieser Arbeit soll darum sein, den aktuellen Entwicklungsstand von FOSSNoSQL-Datenbanksystemen darzustellen und deren Anwendungsmöglichkeiten für
Geodaten zu untersuchen. Dazu soll im ersten Kapitel eine zweckmäßige Zusammenfassung der Historie der NoSQL-Bewegung gegeben werden. Nach einer Erläuterung
des Begriffs „NoSQL“ werden dann grundlegende Konzepte nichtrelationaler Datenbanken eingeführt. Das zweite Kapitel schließt mit einem allgemeinen Überblick zu den
heute frei verfügbaren NoSQL-Datenbanken an. Die aktuell dafür gebräuchlichste Kategorisierung soll darin vorgestellt und jeweils ein Vertreter dieser Kategorien näher
betrachtet werden. Insbesondere soll hier auf die für Geodaten interessante Eigenschaften und Standards eingegangen werden, um davon ausgehend eine Einschätzung zum aktuellen Entwicklungsstand zu treffen. Eventuell verfügbare Spatial Extensions werden in die Betrachtungen entsprechend mit einbezogen und in ihrem Funktionsumfang beleuchtet. Daran anschließend soll eine Diskussion des Anwendungspotentials von NoSQL-Datenbanken vorgenommen werden, bei der die in Kapitel zwei
vorgestellten Systeme wieder aufgegriffen und exemplarisch auf ihre Tauglichkeit für
Geodaten untersucht werden. Davon abgeleitet soll es möglich sein, eine Einschätzung
über das theoretische Anwendungspotential der verschiedenen NoSQL-Datenbanken
geben zu können. Kapitel fünf und sechs stellen zwei unterschiedliche exemplarische
Implementierungen vor, die jeweils mit einem für sie geeigneten Vertreter der NoSQLDatenbanken verwirklicht wurden. Insbesondere geht es hier darum, die Eignung der
Datenbank zur Haltung geografischer und topologischer Daten auch praktisch unter
Beweis zu stellen und eine begründete abschließende Aussage zu deren Eignung treffen zu können.
1 Einführung in die Welt der NoSQL-Datenbanken
1
2
Einführung in die Welt der NoSQL-Datenbanken
Um in die Welt der NoSQL-Datenbanken einsteigen und ihren Wert für Geodaten
schlüssig beurteilen zu können, ist es nötig, sich einen kurzen Überblick über die wichtigsten Konzepte zu verschaffen. Im folgenden Kapitel soll dazu zunächst ein historischer Abriss zur Entstehung der NoSQL-Bewegung gegeben werden. Anschließend
folgt eine kurze Auseinandersetzung mit Konzepten, die für viele der NoSQLDatenbanken eine wichtige Rolle spielen und außerdem die Grundgedanken hinter den
Entwicklungen nachvollziehbar machen.
1.1
Historischer Abriss
Der Begriff „NoSQL“ wurde in Zusammenhang mit Datenbanken zum ersten Mal 1998
von Carlo Strozzi genutzt (Edlich 2011: 1). Es handelte sich dabei um ein System, das
zwar auf einem relationalen Datenmodell basierte, aber ganz bewusst kein SQL als
Abfragesprache zur Verfügung stellte. Auf seiner Website betont Strozzi, dass sein
System mit der aktuellen NoSQL-Bewegung nichts zu tun hat und dass sie eher die
Bezeichnung „NoRel“ verdient hätte, womit er auf die Abkehr vom relationalen Datenmodell anspielt (Strozzi 2010).
Erste wirklich als NoSQL-Datenbanken zu bezeichnende Systeme entstanden mit Einzug der Web 2.0 Welle und der damit verbundenen Datenflut. Um den exponentiellen
Wachstumsraten digitaler Informationen Herr zu werden, begann der Suchmaschinenriese Google 2004 mit der Arbeit an „BigTable“ (Hitchcock 2005), einer nichtrelationalen Datenbank, optimiert zur verteilten Haltung exzessiver Datenmengen im PetabyteBereich. BigTable nutzt eine Kombination aus Reihen/Zellen-Schlüsseln und Zeitstempeln, um Daten lose zu strukturieren, und baut auf das hauseigene Dateisystem
„Google File System“ (GFS) auf (Chang 2006: 1). Seit der öffentlichen Präsentation der
Ergebnisse 2006 im BigTable Whitepaper und dessen Präsentation auf der OSDI '06
erfuhr die Entwicklung von nichtrelationalen Systemen einen sprunghaften Anstieg. So
finden sich heute beispielsweise Eigenschaften von BigTable in Apache HBase oder
Apache Cassandra. Die Qualität dieses neuen Konzepts ist dabei nicht allein die Fähigkeit, große Datenmengen zu verwalten, sondern auch die Ausrichtung auf ein verteiltes System aus kostengünstigen Standardservern („commodity server“), die zu leistungsfähigen und fehlertoleranten Clustern zusammengeschlossen werden können.
Damit war es nun auch möglich, dynamisch auf wachsende Datenmengen und steigende Nutzerzahlen einzugehen und die Kapazitäten entsprechend anzupassen. (Edlich 2011: 2)
Auch andere Unternehmen, deren Geschäft primär auf der Hochverfügbarkeit ihrer
Dienste beruht, haben ähnliche Anwendungsfälle für nichtrelationale Datenbanken ge-
1 Einführung in die Welt der NoSQL-Datenbanken
3
funden. Aufgrund der Tatsache, dass der Versandkonzern Amazon zur Weihnachtszeit
ein stark erhöhtes Nutzeraufkommen zu verzeichnen hatte, die technologischen Grenzen der eingesetzten Datenbanksysteme nach eigenen Aussagen 2004 aber ausgereizt waren, kam es zu Einbrüchen in der Verfügbarkeit der Dienste. Daraufhin setzte
Amazon mit der Entwicklung von Dynamo ebenfalls auf ein skalierendes, nichtrelationales System aus der Eigenentwicklung (Vogels 2012).
Obwohl von Google so nicht propagiert, steht das proprietäre BigTable heute als Begriffspate für eine ganze Kategorie der NoSQL-Datenbanken – die sogenannten „Wide
Column Stores“. Vermutlich setzte sich der Begriff im Juni 2009 durch, nachdem eine
mit „NoSQL“ betitelte Konferenz in San Francisco auf der Plattform Eventbride.com
angekündigt wurde. Sie umfasste Präsentationen zu mehreren Datenbankenkategorien
wie Voldemort, Cassandra, Dynomite, HBase, Hypertable und CouchDB (Evan 2009).
Seitdem ist NoSQL zu einer Art Sammelbegriff für diese verschiedenen Datenbankengeworden und wird gerade aus Marketinggründen gern genutzt (Edlich 2011: XV).
1.2
„NoSQL“
Während der Wiedererkennungswert des Wortes „NoSQL“ unumstritten hoch ist, ist
der Begriff selbst eher irreführend. Es hat den Anschein, dass SQL als Datenbankabfragesprache kategorisch abgelehnt wird, was jedoch nicht der Fall ist. Es gibt zum
einen Systeme, die SQL in verschiedenen Qualitäten selbst implementieren, wie z.B.
OrientDB und GenieDB. Außerdem haben die neuen Datenmodelle zu einer ganzen
Reihe von Abfragesprachen geführt, die sich an der Semantik von SQL, und nicht zuletzt an der englischen Sprache, orientieren. Die „Cassandra Query Language“ (CQL)
ist einer dieser Vertreter. „SQL“ wird vielmehr als Synonym für (objekt-)relationale Datenbanksysteme verstanden. Dies ist damit auch die vielleicht wichtigste und einende
Eigenschaft der als NoSQL proklamierten Datenbanksysteme. Sie brechen mit dem
Status Quo der relationalen Datenhaltung in vordefinierten, zeilenorientierten Tabellen.
Carlo Strozzi hat in diesem Sinne also Recht, wenn er behauptet, „NoRel“ wäre unter
Umständen die treffendere Bezeichnung gewesen. Dementsprechend wird NoSQL
mittlerweile mit „Not-only-SQL“ gedeutet, was auch in dem gemeinschaftlich entworfenen Definitionsvorschlag für NoSQL-Datenbanken von Prof. Stefan Edlich deutlich
wird:
„Unter NoSQL wird eine neue Generation von Datenbanksystemen verstanden, die
meistens einige der nachfolgenden Punkte berücksichtigen:
1. Das zugrundeliegende Datenmodell ist nicht relational.
2. Die Systeme sind von Anbeginn an auf eine verteilte und horizontale Skalierbarkeit ausgelegt.
3. Das NoSQL-System ist Open Source.
4. Das System ist schemafrei oder hat nur schwächere Schemarestriktionen.
5. Aufgrund der verteilten Architektur unterstützt das System eine einfache
Datenreplikation.
1 Einführung in die Welt der NoSQL-Datenbanken
4
6. Das System bietet eine einfache API.
7. Dem System liegt meistens auch ein anderes Konsistenzmodell zugrunde:
Eventually Consistant und BASE, aber nicht ACID […].” (Edlich 2011: 2).
Der Begriff NoSQL bezieht sich also nicht nur auf die Abfragesprache der relationalen
Datenbanken. Gerade die Skalierbarkeit und der Aufbau als verteiltes System scheint
eine große Bedeutung im Umfeld der NoSQL-Systeme zu spielen und soll
anschließend Gegenstand dieser Betrachtungen sein.
1.3
Scaling Up/Out
Technisch gesehen wird den Anforderungen unserer vernetzten Welt bisher mit der
unter „Scaling Up“ oder „vertikaler Skalierung“ bekannten Vorgehensweise begegnet.
Server, deren Kapazitäten erreicht sind und die Clientanfragen nicht mehr ausreichend
bedienen können, werden durch neue Technik ersetzt oder aufgerüstet. Die entsprechend leistungsstarke Hardware ist teuer. Trotzdem ist dies für die meisten Anwendungen ein ausreichendes Mittel (Edlich 2011: 377).
Eine Alternative zu einer Vertikalen Skalierung stellt die sogenannte „Horizontale Skalierung“ oder „Scaling Out“ dar. Darunter versteht man „das Erweitern des Systems
durch Einfügen zusätzlicher Computerressourcen“ (ebd.). Der Vorteil dabei liegt in der
Möglichkeit, aus einem Verband aus Mittelklasse-Hardware einen leistungsfähigen
Cluster zu bilden. Dies ist in der Regel kostengünstiger und ermöglicht eine dynamische Einflussnahme auf die Leistung des Systems durch Hinzufügen weiterer Rechner.
Den aktuellen Gipfel der Horizontalen Skalierung stellt das sogenannte „Cloud Computing“ dar (ebd.). Der Versanddienstleister Amazon etwa bietet auf Grundlage seiner
eigenen Datencenter die „Amazon Web Services“ an und erlaubt so eine Nutzung seiner Rechenkapazitäten. Der gewillte Kunde kann Rechenzeit kaufen und eigene virtuelle Server betreiben, deren Rechenleistung vom Cluster bereitgestellt wird.
(Amazon.com 2012)
Im Zusammenhang mit der Horizontalen Skalierung spielt das in Brewers CAPTheorem erfasste Problem der Unvereinbarkeit von Verfügbarkeit und Konsistenz eine
wichtige Rolle. Darauf soll im nächsten Abschnitt eingegangen werden.
1.4
CAP-Theorem
Allgemein beruhen alle relationalen Datenbanksysteme, die im Einsatz sind, auf Entwicklungen, die in ihren Paradigmen über 25 Jahre alt sind (Stonebraker 2007: 1). Im
Vergleich zu damals, hat sich das Spektrum für den Einsatz von Datenbanken jedoch
vergrößert. Zumeist bedeutet dies die Integration in Web Services als verteilte Systeme, die einer viel größeren Zugriffslast unterliegen und dabei Hochverfügbarkeit bieten
sollen. Eric A. Brewer stellte in diesem Zusammenhang eine gemeinhin als „CAP-
1 Einführung in die Welt der NoSQL-Datenbanken
5
Theorem“ bekannte Theorie auf, welche besagt, dass die gewollten Eigenschaften
Konsistenz, Verfügbarkeit und Partitionstoleranz für solche Dienste nicht gleichzeitig zu
gewährleisten sind (Brewer 2000). Zwei Jahre später wurde dieses Theorem durch
Seth Gilbert und Nancy Lynch für verteilte Web Services formal bestätigt (Gilbert
2002).
Ein praktisches Beispiel dafür ist ein verteiltes System bestehend aus drei Servern. Da
Netzwerkpartitionen eine Voraussetzung für ein solches System sind, gelingt es nicht,
gleichzeitig Verfügbarkeit und Konsistenz aller drei Server zu wahren. In einem
Konsistenz vernachlässigenden System würde zwar hohe Verfügbarkeit erreicht
werden können, während eines Lesevorgangs jedoch könnte eventuell nicht der
aktuellste Stand reflektiert werden. Soll andererseits Konsistenz garantiert werden,
kann ein nicht verfügbarer Datenbankserver einen Schreibvorgang unterbinden, da er
z.B. durch Transaktionierung gesperrt ist (Vogels 2009: 41).
Ein nicht partitioniertes System hingegen bestehend aus Client und Speichereinheit
könnte Verfügbarkeit und Konsistenz durch Transaktionierungsmechanismen garantieren. In dieser Umgebung würde der Ausfall einer Komponente jedoch zum Totalausfall
führen, was bedeutet, dass für ein solches System das CAP-Theorem nicht gilt (ebd.).
1.5
ACID & BASE
Aus dem CAP-Theorem lässt sich schließen, dass aufgrund des hohen Datenzugriffsbedarfs durch steigende Nutzerzahlen das ursprünglich verwendete sogenannte „ACID-Paradigma“ nicht mehr uneingeschränkt anwendbar ist. Unter dem Begriff „ACID“
sind die vier Eigenschaften Atomicity, Consistency, Isolation und Durability zusammengefasst, welche durch Transaktionierung in RDBMS durchgesetzt werden (Kemper
2011: 289).
Viele NoSQL-Datenbanken setzen daher auf ein alternatives Modell, welches gemeinhin als „BASE“ bezeichnet wird und auf Transaktionierung verzichtet. BASE ist ein Akronym für:

Basically Available

Soft-State

Eventually Consistent
Der Grundgedanke beruht darauf, Hochverfügbarkeit für gelockerte Konsistenzbedingungen einzutauschen. Bei „Eventual Consistency“ handelt sich also um einen optimistischen Ansatz, bei dem darauf verzichtet wird, alle im Cluster beteiligten Knoten durch
Transaktionierung vor Inkonsistenzen zu sichern. Konsistenz der Daten wird so zu einem fließenden, sich über ein Zeitfenster ausbreitenden Zustand (Edlich 2011: 33).
Zwar besteht so die Gefahr, dass für einen kurzen Zeitpunkt auf einigen Servern
1 Einführung in die Welt der NoSQL-Datenbanken
6
veraltete Daten zur Verfügung stehen, jedoch kann der hohe Bedarf an Zugriffen auf
dieselben Datensätze eher gedeckt werden.
Es ist offensichtlich, dass dieses Vorgehen nicht für jeden Einsatzzweck geeignet ist.
Eine finanziellen Transaktion ließe ein solches Konzept nicht zu, da der richitge
Kontostand nicht zu jedem Zeitpunkt garantiert wäre. Da die
Konfigurationsmöglichkeiten zwischen ACID und BASE mittlerweile fließend sind und
manche Datenbanken sogar eine Kombination der Paradigmen unterstützen, ist es
sinnvoll, Vor- und Nachteile für die jeweilige Anwendung im Voraus abzuwägen (Edlich
2011: 34).
1.6
MapReduce
Mit der starken Orientierung der nichtrelationalen Datenbanken nach verteilten Systemen und neuen Datenmodellen mussten auch neue Algorithmen erdacht werden, welche diese Anforderungen unterstützen. Einer der bekanntesten Algorithmen dieser Art
ist MapReduce, welcher durch die Google-Ingenieure Jeffrey Dean und Sanjay Ghemawat für Google BigTable umgesetzt wurden (Edlich 2011: 12). Es handelt es sich
dabei um ein Verfahren zur massiv parallelen Datenverarbeitung auf großen, verteilten
Systemen. Die Parallelisierung beruht dabei auf den aus der funktionalen Programmierung abgeleiteten Methoden map() und reduce(), welche Abbildungsvorschriften darstellen, die auf Grundlage einer Kopie der Originaldaten in eine neue Datenstruktur
überführen (Dean 2004: 1). Bei der Anwendung durch NoSQL-Datenbanken wie
HBase, Cassandra oder BigTable erfolgt die Abarbeitung von Map und Reduce dabei
in zwei Phasen. Die erste Phase ist die Map-Phase, bei der aus einer Liste von Werten
in eine neue Liste von Werten überführt wird (ebd.: 2). Die Ausgangsliste stellt dabei
den kompletten Datenbestand in der Datenbank dar. Da die Funktion auf Kopien der
Originaldaten angewendet wird bzw. das Ergebnis eine neue Datenstruktur darstellt,
beeinflussen sich mehrere gleichzeitige Aufrufe der Funktion nicht gegenseitig. Dies
ermöglicht eine parallele Abarbeitung (s. Abbildung 1). Die optionale Reduce-Phase
kann das Ergebnis der Map-Phase anschließend aggregieren. Die Funktion setzt voraus, dass sie rekursiv definiert ist, was sie so ebenfalls parallel ausführbar macht
(Edlich 2011: 13).
1 Einführung in die Welt der NoSQL-Datenbanken
7
Abbildung 1: Datenfluss des MapReduce-Verfahrens (Edlich 2011: 17).
Auf einem Computercluster, der die vielen Einzelprozesse der beiden Phasen auf die
einzelnen Knoten verteilt, entsteht so ein enormes Potenzial für beschleunigte Berechnungen, die aufgrund der großen Datenmenge auf einem einzelnen Computer unter
Umständen gar nicht möglich wären (Edlich 2011: 13).
1.7
Schemalosigkeit von Daten
Neben den unterschiedlichen Herangehensweisen bei Konsistenz und Skalierung ist
ein weiterer wesentlicher Unterschied zwischen den SQL- und NoSQL-Datenbanken,
dass das Datenbankmodell selbst nicht vor dem Einfügen der ersten Datensätze definiert sein muss. Während vor dem Anlegen eines Datenbankmodells für SQLDatenbanksystems eine genaue Kenntnis über die zu erwartenden Daten vorliegen
muss, um davon ein Datenbankschema abzuleiten, ist dies mit NoSQL allgemein nicht
nötig. Dadurch fällt auch ein eventuelles Umstrukturieren der Tabellen weg, wie es bei
relationalen Datenbanken vonnöten sein kann, sobald sich die Ansprüche an die Datenhaltung ändern oder Informationen mit aufgenommen werden sollen, die beim Anlegen der Tabellen so nicht vorgesehen waren.
2 Allgemeiner Überblick
2
8
Allgemeiner Überblick
In der kurzen Zeit seit der Veröffentlichung des BigTable Whitepapers 2006 sind viele
NoSQL-Datenbanksysteme entstanden. Darüber hinaus qualifizieren sich auch bestehende Systeme, wie beispielsweis Lotus Notes oder Oracle Berkeley DB, als nichtrelationale Systeme und sind zusammen mit derzeit mehr als 122 weiteren Datenbanken
auf http://nosql-database.org/ gelistet (Edlich 2012). Neben wenigen kommerziellen
Anbietern handelt es sich dabei meist um Free and Open Source Projekte (FOSS) unterschiedlicher Größe. Aufgrund der schieren Größe des Angebots, kann hier nicht auf
jede dieser Datenbanken eingegangen werden. Im Folgenden sollen deshalb die vier
wichtigsten Kategorien nichtrelationaler Datenbanken vorgestellt werden und je ein
typischer Vertreter genauer betrachtet werden, der diese repräsentiert.
2.1
Kategorisierung
Eine Kategorisierung der Datenbanken erscheint zunächst schwierig, da die Eigenschaften der Systeme einerseits drastisch variieren, sich andererseits aber auch nur in
Detailfragen unterscheiden. Der beste Weg, sich dem Angebot zu nähern, ist es, die
Datenbanken nach Art der Datenhaltung zu unterscheiden. Die Website „NOSQL
Databases“ schlägt hier seit 2009 eine durch die Open Source Gemeinde diskutierte
Ordnung vor, die sich weitgehend durchgesetzt hat. (Edlich 2012). Die Kategorisierung
der nichtrelationalen Datenbanken basiert auf den ihnen zugrundeliegenden Datenmodellen und umfasst folgende Hauptkategorien:

Key/Value Stores

Wide Column Stores

Document Stores und

Graphdatenbanken.
Die Einordnung der Systeme in die einzelnen Kategorien kann sich mitunter als
schwierig erweisen, da hybride Lösungen beispielsweise Eigenschaften aus
Key/Value-Stores und Document Stores mischen (z.B. Riak) (Edlich 2011: 179) oder
Features mehrerer Kategorien implementieren (z.B. OrientDB). (Garulli 2011).
2.2
Key/Value Stores
Die erste Gruppe der Key/Value Stores ist in den letzten Jahren sehr gewachsen. Seit
den 70er Jahren bekannt, hat sich ihre Anzahl mit dem Erscheinen des Amazon Dynamo Whitepapers 2007 vervielfacht. Sie sind prädestiniert für Daten, die keine Relation zueinander aufweisen, da es sich um ein sehr einfaches Datenmodell handelt
(Edlich 2011: 151).
2 Allgemeiner Überblick
9
2.2.1 Datenhaltung
Das Prinzip der Datenhaltung in einem Key/Value Store ähnelt einer Hash Table, also
einer Zuordnungstabelle der objektorientierten Programmierung bestehend aus zwei
Spalten. Eine Spalte enthält dabei den über eine Hash-Funktion abgebildeten Schlüssel („Key“) über den der Zugriff erfolgt (s. Abbildung 2). Die zweite Spalte führt den
assoziierten Wert, genannt „Value“, welcher als einzige Bedingung den Datentypen
entsprechen muss, die durch die Datenbank unterstützt werden. Die einzelnen Einträge in die Zeilen der Tabelle sind dabei ohne weitere Relation zueinander (Edlich 2011:
36). Die Verantwortung der Beziehungen zwischen den Einträgen obliegt damit voll der
Clientanwendung.
Abbildung 2: Hashfunktion. Eingangswerte werden über eine bestimmte Funktion auf einen
Werteraum abgebildet (Edlich 2011: 36).
2.2.2 Redis
Ein beliebter Vertreter der Key/Value Stores ist das Datenbanksystem „Redis“. Es startete 2009 als Entwicklung von Salvatore Sanfillippo und ist in ANSI-C programmiert
(Edlich 2011: 152). Es steht für POSIX-kompatible Plattformen in einer New-BSDLizenz zur Verfügung und kann direkt aus dem Quellcode kompiliert werden. (Edlich
2011: 152).
Im Gegensatz zur weit verbreiteten Caching-Lösung „Memchached“, bietet Redis drei
Persistenz-Modi, aus denen frei gewählt werden kann. Der erste Modus besteht darin,
in fest definierten Intervallen Snapshots des Datensatzes abzulegen (RDB Modus).
Alternativ kann auch jeder Schreibzugriff geloggt und bei Bedarf wieder in die Datenbank eingespielt werden (AOF Modus). Es ist ebenfalls möglich RDB und AOF-Modi
zweckmäßig zu kombinieren oder komplett auf die nachhaltige Speicherung zu verzichten. Daten, die bei einem Ausfall ausschließlich im flüchtigen Arbeitsspeicher vorhanden waren, wären in einem solchen Fall jedoch verloren (Edlich 2011: 152f).
Redis bietet die Möglichkeit, Operationen in einer Transaktion zusammenzufassen.
Dies spart Verbindungszeit bei der Abarbeitung und schützt durch die atomare Reihenabarbeitung des Operationssatzes vor Inkonsistenz gegenüber weiteren Zugriffen
(Edlich 2011: 156f.). Auf Konsolenebene geschieht dies mit dem Befehl MULTI. Zu
beachten ist dabei, dass das Scheitern einer der Operationen, nicht das Scheitern der
2 Allgemeiner Überblick
10
restlichen durch MULTI zusammengefassten Operationen bedingt. Dies muss in der
Anwendungsebene entsprechend berücksichtigt werden (VMWare 2011d).
Um Redis zu skaliert, kann in einer Master-Slave-Schaltung über mehrere Knoten repliziert werden. Dies kann dazu dienen, die Leseleistung zu erhöhen oder Daten redundant vorzuhalten (ebd.). Zu beachten ist, dass zum gegenwärtigen Zeitpunkt (Version 2.4.7) kein Sharding mit Bordmitteln möglich ist. Der dazu notwendige Redis Cluster steht bisher nur als Developer Preview zur Verfügung und wird mit Version 2.6. erwartet (Sanfilippo 2011). Das bedeutet, dass der gesamte Datenbestand in den Arbeitsspeicher passen muss. Davon Daten in den virtuellen Speicher auszulagern wird
abgeraten (VMWare 2011e).
Auch wenn alle Datentypen die durch Redis unterstützt werden auf Strings basieren,
werden komplexe Strukturen wie Listen, unsortierte und sortierte Sets und Hashes
bereitgestellt (Edlich 2011: 153). Darüber hinaus werden Interaktionen, wie beispielsweise UNION und DIFF bei Sets, oder links- oder rechtsseitige PUSH und POPBefehle bei Lists geboten, die einer Clientanwendung weitreichende Optimierungsmöglichkeiten bieten. Der Zugriff auf die Datenbank erfolgt dabei über die mitgelieferte
Konsole oder über eine entsprechende Client-API. Die Auswahl ist sehr groß und umfasst alle verbreiteten hohen Programmiersprachen (VMWare 2011a).
2.2.3 Spatial Extension
Zum gegenwärtigen Zeitpunkt ist für keinen Key/Value Store eine Spatial Extension
verfügbar (s. Anhang 2). Dies trifft auch für Redis zu. Da durch Redis binärsichere
Strings unterstützt werden, ist es jedoch möglich, jede Art von Daten binärcodiert abzulegen und auszulesen.
2.3
Wide Column Stores
Bei der zweiten großen Gruppe der NoSQL-Datenbanken, den „Wide Column Stores“
(auch „Column Family Store“), handelt es sich um spaltenorientierte, nichtrelationale
Datenbanken. Sie könnten als „Nachkommen“ des proprietären Google BigTable gesehen werden, da die Open-Source-Community vielfach begonnen hat, auf Basis der
von Google veröffentlichten Forschungsunterlagen Eigenschaften von BigTable zu
klonen und gewünschte hinzuzufügen. Ein sehr erfolgreiches Beispiel dafür ist die Datenbank „HBase“, die Teil des Apache Frameworks Hadoop ist (The Apache Software
Foundation 2012). Auch der Social Network Riese Facebook hat einen Wide Column
Store entwickelt. Dieser wurde unter dem Namen „Cassandra“ 2008 der Open-SourceCommunity übergeben (Cassandra Wiki 2012c).
Entsprechend des proprietären Vorreiters Google stellt auch das Open Source Framework Apache Hadoop das verteilte Dateisystem Hadoop Distributed File System
2 Allgemeiner Überblick
11
(HDFS) zur Verfügung und setzt als Apache Hadoop MapReduce eine quelloffenes
Variante des Programmier-Paradigmas um auf das Cassandra und HBase zurückgreifen können (The Apache Software Foundation 2011).
2.3.1 Datenhaltung
Google selbst beschreibt das Datenmodell der Wide Column Stores als „[…] sparse,
distributed, persistent multidimensional sorted map“ (Chang 2006: 1). Dabei handelt es
sich um eine sehr eng gepackte Definition, die zusammengefasst Folgendes beschreibt:
Die oberste Ordnungseinheit ist, so wie in einem Key/Value Store, der Zeilenschlüssel.
Der Value ist in diesem Fall eine Map, wie sie aus der objektorientierten Programmierung bekannt ist. Diese zeigt wiederrum auf eine Zuordnungstabelle von Spaltenfamilien, daher auch der alternativer Name „Column Family Store“. Diese Verschachtelung
von Zuordnungstabellen kann als „multidimensional“ bezeichnet werden. Die Column
Family verweist letztendlich auf Spalten, also „columns“, die versionierte Werte enthalten, welche wiederum ein nicht interpretiertes Byte-Array darstellen (Wilson 2008).
Abbildung 3: Konzeptuelles Schema eines Wide Column Stores nach BigTable White Paper
(Chang 2006: 2).
{
...
"com.cnn.www": {
"anchor" : {
"cnnsi.com" : {
T9 : "CNN"
},
"my.look.ca" : {
T8 : "CNN.com"
},
"contents" : {
"" : {
T6 : "<html>...",
T5 : "<html>...",
T3 : "<html>..."
}
}
}
...
//Row Key
//Column Family
//Column
//Version & Value
//Column mit leerem Bez. ""
}
Abbildung 4: Konzeptuelles Schema eines Wide Column Stores in JavaScript-naher Notation
(Wilson 2008).
2 Allgemeiner Überblick
12
Das Konzept der spaltenorientierten Datenhaltung der Wide Column Stores hat Vorteile bei der Kompression und Analyse der Daten gegenüber den zeilenorientierten
RDBMS. Andererseits ist das Lesen und Schreiben von Objektstrukturen aufwändiger
(Edlich 2011: 63). Durch die sortierte Speicherung von Row Keys, Column Families
und Columns (vgl. „multidimensional sorted map“ bzw. Abbildung 4 ist es außerdem
leichter, eine horizontale Partitionierung der Daten einzurichten und so Zugriffe auf
mehr als einen Datenbankserver pro Abfrage zu reduzieren (ebd.).
2.3.2 Apache Cassandra
Das von Facebook entwickelte und mittlerweile als „Apache Top Level Project“ gelistete Cassandra leitet seine Eigenschaften sowohl von BigTable als auch Amazon Dynamo ab. Cassandra ist damit auch ein gutes Beispiel für die eingangs erwähnte Vielfalt
der NoSQL-Datenbanken, die durch Kombination von Konzepten entsteht. In erster
Linie handelt es sich um einen BigTable-Klon der um eine weitere Organisationsebene,
die „Super-Column“, erweitert ist (Edlich 2011: 83). Vorbild für die Skalierung ist das
Amazon Dynamo Whitepaper welches unter anderem das „Consistent Hashing“ beschreibt. Es ermöglicht, per horizontaler Fragmentierung („Sharding“) den Datenbestand über eine große Menge von Datenbankservern zu verteilen. Das Grundprinzip
besteht darin, den Hash-Wertebereich der Schlüssel über alle beteiligten Knoten zu
verteilen und in einem Ring zu schließen. Jeder Rechner übernimmt die Schreibverantwortung für je eine dieser Partitionen. Außerdem wird diese Partition auf weitere
Server repliziert, um so die Fehlertoleranz zu erhöhen. Sie ist dort als Schattenkopie
vorgehalten und kann bei einem Ausfall neu im Ring verteilt werden. (Vogels 2007).
Abbildung 5: Consistant Hashing-Ring. (Vogels 2007).
2 Allgemeiner Überblick
13
Die im Cluster verbundenen Knoten befinden sich also in einer Master-MasterKonfiguration, wodurch einem „Single-Point-of-Failure“ vorgebeugt werden soll. Um
dies umzusetzen, basiert die Kommunikation der beteiligten Datenbankserver auf dem
Peer-to-Peer Protokoll „Gossip“, mit dem die Instanzen ihren Status periodisch mitteilen und empfangen (ebd.).
Als Schnittstelle steht Cassandra „Thrift“ zur Verfügung, ein Framework, welches den
plattformunabhängigen Austausch von Objekten ermöglicht (Slee 2007). Auf Grundlage der reinen Thrift API sind viele High Level-Clients verfügbar, der Zugriff auf ein
Cassandra-Cluster ist also nativ in vielen Programmiersprachen wie Java, C++ und
Ruby möglich (Cassandra Wiki 2012a).
2.3.3 Spatial Extensions
Derzeit steht, wie für Key/Value Stores, für keinen Wide Column Store eine Spatial
Extension zur Verfügung (Stand Februar 2012). Die Schachtelung von Column Familys
und Columns erlaubt strukturiertere Daten als dies bei einem reinen Key/Value Store
möglich ist. Dass die Haltung von Geodaten in einem Wide Column Store nicht grundlegend unmöglich ist, zeigt Google durch die Nutzung von BigTable für den Großteil
seiner Dienstleistungen, wozu auch die Bereitstellung der Google Earth Satellitenbildern per Desktop- und Webinterface gehört. (Chang 2006: 11f) Die gleichen
technischen Grundlagen werden außerdem eingesetzt, um mit Google Earth Builder
Geodaten für Unternehmen in der Cloud bereitzustellen (Google 2012).
Apache Cassandra kommt außerdem bei der Firma SimpleGeo zum Einsatz, welche
auf dem Wide Column Store aufbauende Point-of-Interest-Services und einen StorageService anbietet. Der Zugang erfolgt dabei über eine Web-API. SimpleGeo bietet
grundlegende räumliche Abfragen auf Punktmengen durch Implementierung eines eigenen Zugriffsmechanismus (Finley 2011 und Malone 2010).
2.4
Document Stores
Wie der Name bereits andeutet, handelt es sich bei den „Document Stores“, um in erster Linie dokumentenbasierte Datenbanken. Ein konzeptueller „Vater“ der Document
Stores ist Lotus Notes, das neben der Integration des relationalen IBM RB2 ebenfalls
eine dokumentenzentrische Datenhaltung anbietet. Die Entwicklung ist also nicht
grundlegend neu, hat aber durch CouchDB und dessen Begründer Damien Katz eine
Wiederbelebung erfahren. Da sich die schemalose Dokumentenstruktur gerade für
agile Webanwendungen eignet, wird CouchDB und auch die größte Konkurenz, das
Document Store MongoDB, von der Entwicklergemeinschaft sehr gut angenommen
(Edlich 2011: 117).
2 Allgemeiner Überblick
14
2.4.1 Datenhaltung
Das zugrundeliegende Datenmodell eines Document Stores wird als „dokumentenzentrisch“ oder „dokumentenorientiert“ bezeichnet. Unter Dokumenten verstehen sich dabei
Daten im JSON-Format (JavaScript Object Notation) oder in der binärenkodierten Variante „BSON“. Um die Typen von Dokumenten zu unterscheiden, werden entsprechende Eigenschaften in ihnen definiert, die sie „implizit“ unterscheiden (Scheliga 2010: 81).
JSON ist ein Austauschformat, das auf einer Untermenge der JavaScriptProgrammiersprache basiert und der textlichen Repräsentation von Objekten dient.
Gegenüber der Auszeichnungssprache XML (Extensible Markup Language) ergibt sich
damit eine einfachere Lesbarkeit. Außerdem ist JSON in fast allen Programmiersprachen leicht zu verarbeiten (Scheliga 2010: 45.f).
{
"_id": "5633855b3772c8426e77a4e2c7000de8",
"_rev": "4-17aaa5b24954e6c6245381670fda8b88",
"name": "Ruby",
"implementations": [
"Ruby",
"JRuby"
]
}
Abbildung 6: Beispiel eines einfachen JSON-Dokuments.
2.4.2 CouchDB
CouchDB ist eine schemafreie, dokumentenorientierte Datenbank in der die Daten in
Form von JSON-Datenstrukturen abgelegt werden. Der Zugriff auf CouchDB per
HTTP-Protokoll orientiert sich eng an den durch Roy Fielding zusammengestellten Kriterien des „Representational State Transfer“, womit es sich bei CouchDB wohl um die
am besten ans Web angepasste Datenbank handeln dürfte (Tiwari 2011).
RESTful bedeutet, dass CouchDB alle REST Operationen (GET/HEAD, PUT, DELETE, POST) unterstützt und dabei die Konzepte der Sicherheit und Idempotenz einhält.
Zu verstehen ist darunter, dass beispielsweise eine simple GET-Operation keine Daten
in der Datenbank ändert. Die Operation ist also sicher. Idempotent bedeutet, dass bei
der Nutzung des PUT-Befehls das mehrfache Schreiben des gleichen Dokuments immer zum gleichen Ausgang führt. So kann verhindert werden, dass die gleiche Operation unwillentlich zu doppelten Dokumenten führt (Fielding 1999). Datenbank und Dokumente stellen die Ressourcen dar, auf die die Operationen angewandt werden können. Sie besitzen eine eindeutig zu identifizierende Uniform Ressource Identifier (URI).
Außerdem setzt CouchDB eine zustandslose Anfrage durch den Client voraus. Jede
Anfrage muss also alle Informationen zur Abarbeitung enthalten und kann nicht auf
Kontextinformationen in der Datenbank vertrauen. Die Integration in Web Services ist
so besonders einfach (Fielding 2000 und Edlich 2011: 51ff.).
2 Allgemeiner Überblick
15
Neben der Funktion als Dokumentdatenbank integriert CouchDB so einen vollwertigen
HTTP-Server, deren Ressourcen per HTTP-REST-„API“ aufrufbar sind. Dazu gehört
auch eine Administrationskonsole, die per Browser aufgerufen werden kann und über
die, neben der Verwaltung von Datenbanken und Dokumenten auch Konfigurationen
vorgenommen und Zugriffsrechte geregelt werden können.
In der Arbeit Roy Fieldings ist die Zustandslosigkeit der Ressourcen des HTTPProtokolls als einer der Hauptgründe für den Erfolg des World Wide Web beschrieben
(Fielding 2000). Einerseits ist es möglich, Informationen einer Ressource einfach auszulesen, andererseits kann die Ressource auch in verschiedensten Ausprägungen
dargestellt werden. Diesem Konzept folgt auch CouchDB und implementiert bestimmte
„Sonderdokumente“, die durch einen führenden Unterstrich auszumachen sind. Das
wichtigste Dokument stellt dabei „_design“ dar. Hier lassen sich neben anderen folgende Funktionen als JSON-Objekte definieren:

Views

Lists

Validierungsfunktionen (Scheliga 2010)
Views stellen dabei die Abfragemöglichkeit auf CouchDB-Dokumente dar, welche per
Map- und Reduce-Funktionen in JavaScript formuliert wird. Der Grundgedanke ist dabei analog zu dem des MapReduce-Verfahrens, welches in 2.6 beschrieben ist. Es
werden also alle Datensätze der Datenbank durchlaufen und geprüft. Die Antwortmenge wird anschließend indexiert und ist unter der URI des Views verfügbar. ListFunktionen dienen als „Render-Funktionen für Views“ (ebd.: 140) und verarbeiten die
Ergebnismenge eines Views weiter (ebd.). Sie eignen sich beispielsweise zum Umformen des JSON-Objekts in ein anderes Format. Über die Validierungsfunktion lassen
sich die Benutzerrechte für verschiedene Nutzergruppen steuern (ebd.: 149f.).
CouchDB setzt statt auf pessimistische Transaktionierung auf die Versionierung von
Schreibzugriffen durch Multi Version Concurrency Control (MVCC). Das heißt, dass
„mehrere unveränderliche Versionen eines Datensatzes“ (Edlich 2011:41) vorgehalten
werden. Jeder Schreibzugriff erstellt eine neue Version die eine eindeutig
identifizierbare Revisionsnummer trägt. Treffen konkurrierende Schreibzugriffe auf
einem Datensatz zusammen, wird durch vergleichen der Revisionsnummern bestimmt,
ob die Schreiboperation zu diesem Zeitpunkt zulässig war. Im Konfliktfall muss diese
„optimistische“ Transaktion zurückgerollt und unter Umständen von vorn begonnen
werden. (ebd.)
2.4.3 Spatial Extensions
Für CouchDB steht die Spatial Extension GeoCouch zur Verfügung. Sie wird durch den
Couchbase-Entwickler Volker Mische koordiniert und gepflegt. Im Februar 2012 war
2 Allgemeiner Überblick
16
ausschließlich eine Bounding Box Abfrage auf geometrische Objekte möglich, welche
sich auf den zweiten Entwurf der OpenSearch-Spezifikation für Geodaten stützt. Nach
eigenen Aussagen sollen zukünftige Implementierungen ebenfalls diesen Standard
bedienen (s. Anhang 1).
Für die Strukturierung der Daten bietet sich die GeoJSON-Spezifikation an, die mit
dem 16. Juni 2008 in die Version 1.0 überführt wurde. Es handelt sich dabei um ein
Schnittstellenformat für geographische Datenstrukturen, das ebenfalls auf der JavaScript Object Notation beruht. Die geometrischen Objekte der Spezifikation orientieren sich an der Simple Feature Specification und umfassen neben simpler Geometrie
auch die Definition eines FeatureObject und einer FeatureCollection. Außerdem ist es
möglich, direkt oder indirekt ein CRS, bevorzugt notiert nach den Empfehlungen für
OGC Universal Ressource Names für Koordinatenreferenzsysteme, als Attribut zu definieren (Butler 2008).
{ "type": "MultiLineString",
"coordinates": [
[ [100.0, 0.0], [101.0, 1.0] ],
[ [102.0, 2.0], [103.0, 3.0] ]
]
}
Abbildung 7: Beispiel eines GeoJSON GeometryObjects des Typs MultiLineString.
Durch die Aufnahme von GeoJSON und CouchDB als Schnittstellenformate in die
Geospatial Data Abstraction Library (GDAL) bzw. in die Sub-Bibliothek OGR Simple
Features Library der OGC ab Version 1.9 aufwärts, können alle durch die Simple
Feature Specification definierten Geometrien in CouchDB importiert und durch
GeoCouch indexiert werden (GDAL 2011).
Neben CouchDB bietet auch der Document Store MongoDB, entwickelt durch die Firma 10gen, eine native räumliche Indexierung, welche allerdings auf die Abfrage von
Punktgeometrie beschränkt ist (10gen 2011). Trotz dieser Einschränkungen listet
10gen auf seiner Website mindestens zwölf Anbieter die MongoDB primär für
webbasierende Geolocation Services nutzen, darunter auch „FourSquare“ mit nach
eigenen Aussagen 15 Millionen Nutzern im Dezember 2011 (Heine 2011).
2.5
Graphdatenbanken
Die letzte hier vorgestellte Gruppe der NoSQL-Datenbanken unterscheidet sich deutlich von den vorherigen. Während Key/Value Stores, Wide Column Stores und
Document Stores unstrukturierte Datensätze speichern und diese für Suchanfragen zur
Verfügung stellen, beschreibt eine Graphdatenbank „die Art und Weise der Verknüpfungen dieser Datensätze untereinander“ (Edlich 2011: 207). Das Grundkonzept der
Graphdatenbanken basiert auf der Graphentheorie der Mathematik, welche das
2 Allgemeiner Überblick
17
allgemeine Graphenmodell bestehend aus einer Knoten- und einer Kantenmenge
definiert. Eine Kante stellt eine Beziehung zwischen zwei Knoten dar und kann sowohl
gerichtet als auch ungerichtet sein (Edlich 2011: 209f.).
Abbildung 8: Einfacher Graph bestehend aus drei Knoten und ungerichteten Kanten.
Auch im Hinblick auf das Schlagwort „Semantic Web“ spielen Graphdatenbanken eine
bedeutende Rolle. Um den Datenaustausch im Web zu standardisieren, baut man hier
auf das Ressource Description Framework (RDF), das das Konzept des einfachen
„Verlinkens“ von Informationen per URI zu einer benannten Kante mit Anfangs- und
Endpunkt ausbaut. Das resultierende Triple entspricht einem gerichteten und
benannten Graphen (RDF Working Group 2012). Graphdatenbanken, die zu diesem
Zweck die Abfragesprache SPARQL implementieren, werden gemeinhin als „RDFStores“ bezeichnet und können als Untermenge der Graphdatenbanken angesehen
werden (Edlich 2011: 228).
2.5.1 Datenhaltung
Das wichtigste Konzept der NoSQL-Graphdatenbanken stellt das „Property-GraphModell“ dar (Rodriguez 2012a). Es handelt sich dabei um eine Erweiterung des
allgemeinen Graphmodells, in dem jede Kante ein Label trägt, die den Typen der
Relation zwischen den Knoten beschreibt. Außerdem erhalten sowohl Knoten als auch
Kanten einen eindeutigen Identifikator und können Eigenschaften („properties“) tragen,
welche durch eine Zuordnungstabelle des Typs <String, Objekt> verkörpert werden. Je
nach Implementierung können Knoten und Kanten streng typisiert werden, sodass der
Typ des Knotens oder der Kante explizit erfasst oder implizit aus seinen Eigenschaften
bestimmt werden kann. Wie sich Abbildung 8 entnehmen lässt, kann einer Kante auch
ein „Gewicht“ zugeordnet werden, weshalb man auch von einem gewichteten Graph
spricht (Edlich 2011: 211f.).
2 Allgemeiner Überblick
18
Abbildung 9: Gewichteter Property Graph zwischen Personen und Programmen (Rodriguez
2012a).
Gegenüber den relationalen Datenbanken ergeben sich einige Parallelen. Während
alle anderen hier vorgestellten NoSQL-Vertreter keine Beziehungen zwischen den Datensätzen modellieren, gehört dies zur natürlichen Struktur eines Graphen. Auch in
einer relationalen Datenbank lassen sich diese Vernetzungen abbilden. Während es
bei einer SQL-Datenbank mit einigem Aufwand verbunden sein kann, die einzelnen
Tabellen per (rekursivem) JOIN zu durchlaufen, um komplexe Beziehungen herzustellen, gestaltet sich die Traversierung eines Graphen schon bedeutend intuitiver (Edlich
2011: 225f.).
Aufgrund der Komplexität des Datenmodells, müssen ähnlich wie bei den SQLDatenbanken, Abstriche bei der Skalierbarkeit des Systems gemacht werden. Um die
Leistung eines Graphdatenbankservers zu erhöhen, bietet sich die Replikation der
Datenbank über mehrere als Slave-Server konfigurierte Rechner an. Schreibzugriffe
werden dabei ausschließlich auf dem Master-Server zugelassen und auf die
hierachisch niederen Rechnerknoten übertragen. Müssen die Daten allerdings
partitioniert werden, weil der Umfang für einen Rechner zu groß geworden ist,
entstehen ganz ähnliche Probleme wie in einer relationalen Datenbank. Auch hier stellt
sich die Frage, an welchem Punkt der Datensatz getrennt werden soll. Traversierungen
der Datensätze über den lokalen Datenbestand hinaus müssen dabei minimiert
werden, um die Abfragekomplexität über das Netzwerk nicht unnötig zu erhöhen. Das
Finden der passenden Partitionierungsregel ist damit nicht trivial (Edlich 2011: 222).
2 Allgemeiner Überblick
19
2.5.2 Neo4j
Neo4j ist seit 2007 als Java Open-Source-Datenbank nutzbar und wird auch in einer
kommerziellen Lizenz angeboten.
Wie die meisten NoSQL-Graphdatenbanken implementiert Neo4j die Bausteine des
De-facto Standards Tinkerpop Graph Processing Stack, ein Java-Framework, welches
in erster Linie eine einheitliche Schnittstelle namens Tinkerpop Blueprints zwischen
Graphdatenbanken bietet (Edlich 2011: 230). Blueprints fungiert hier analog zu der
JDBC-API der relationalen Datenbanken (Rodriguez 2012b). Hinzu kommt die
Unterstützung von Tinkerpop Gremlin, einer Graph-Traversierungssprache, die auch
eine Manipulation des Graphen zulässt. Neben Gremlin steht außerdem die
Traversierungssprache „Cypher“ zur Verfügung, die für Neo4j entwickelt wurde. Sie
zeichnet sich durch eine einfache Syntax aus, die das durchlaufen des Graphen gut
nachvollziehbar macht. (Neo Technology 2012b) Neben dem Auffinden von Knoten
und Kanten via Traversierung, findet außerdem die Suchengine Apache Lucene
Anwendung, über die Indexierungen über die Attribute der Kanten und Knoten
eingerichtet werden können.
Neo4j kann sowohl als „EmbeddedGraphDatabase“ in ein Programm eingebettet, als
auch im Servermodus ähnlich CouchDB über eine REST-Schnittstelle angesprochen
werden. Wird der Datenbankserver gestartet, ist er ebenfalls über den Port 7474 über
eine Webkonsole zugänglich, welche neben Statusinformationen auch eine eigene
Shell bietet, über die der Graph manipuliert bzw. traversiert werden kann.
gremlin> node = g.addVertex("name":"Gremlin")
==> v[2093]
gremlin> g.addEdge(g.v(500), node, 'TEST', [:])
==> e[3114][500-TEST->2093]
Abbildung 10: Hinzufügen eines Knotens und einer Kante mit Gremlin.
Eine weitere Besonderheit im Umfeld Neo4js unter den NoSQL-Datenbanken ist die
Unterstützung von Transaktionen. Neo4j arbeitet nach dem ACID-Paradigma. Das
sperren der Daten geschieht dabei auf Level der Knoten und Kanten.
2.5.3 Spatial Extensions
Aus der Graphentheorie geht hervor, dass Topologie gut durch Graphen modelliert
werden kann. Ändern sich nämlich in einem solchen Graphen die Koordinaten, also
eine metrische Eigenschaft eines Knotens, so ist die Topologie davon nicht betroffen.
Im Grunde lässt sich schon mit den „Bordmitteln“ einer Graphdatenbank komplexe Topologie einpflegen. Darüber hinaus bietet Neo4j die Spatial Extension „Neo4j Spatial“.
Dieser steht bisher lediglich als Development Version zur Verfügung, kann aber in seinem tagesaktuellen Stand vom öffentlichen Git-Repository geladen werden (Neo
2 Allgemeiner Überblick
20
Technology 2012a). Neo4j Spatial stellt auf Grundlage des GeoTools „GIS Toolkits“ der
Open Source Geospatial Foundation (OSGeo) für die Graphdatenbank optimierte GIS
Funktionalität bereit die als Java-Bibliothek in Projekte eingebunden werden kann. Außerdem steht eine Erweiterung für die Neo4j Server Variante zur Verfügung, die Abfragen auf Geodaten per REST-Schnittstelle erlaubt.
Durch den Aufbau auf das GeoTools Framework ist es möglich, Neo4j als Datenhaltungskomponente für OpenGIS-Produkte zu nutzen. Interessant ist dies speziell für
GeoServer, dem es damit möglich ist WFS und WMS auf Grundlage der Graphdatenbank bereitzustellen. Darüber hinaus implementiert die Erweiterung die WKT bzw.
OSM und ESRI Shapefiles Encoder zum Im- und Export von Daten. Neo4j Spatial kann
mit allen Geometrietypen umgehen, die durch die OGC Simple Feature Specification
definiert sind und bietet weitreichende Operationen auf die Geometrien, die durch die
Spezifikation vorgegeben sind.
3 Anwendungspotential für Geodaten
3
21
Anwendungspotential für Geodaten
“In summary, one can leverage at least the following ideas to get superior performance:
A non-relational data model. If the user’s data is naturally something other than tables and if simulating his natural data model on top of tables is awkward, then
chances are that a native implementation of the natural data model will significantly
outperform a conventional RDBMS.” (Stonebraker 2009).
Das obige Zitat einer der Gallionsfiguren der relationalen Datenbanken, Michael
Stonebraker, hat mit seinem Erscheinen für einige Aufmerksamkeit gesorgt. Mittlerweile steht Stonebraker eher für eine defensive Haltung gegenüber der NoSQL-Bewegung
und kritisiert die vollkommene Abkehr von bewährten Konzepten. Nichtsdestotrotz
spricht er einen Punkt an, der gerade auch für Geodaten diskutiert werden muss. Die
Haltung von Geodaten in Tabellen ist nicht intuitiv oder natürlich und erfordert weitreichende Kenntnisse zur Strukturierung der Daten. Dieses Kapitel soll zeigen, ob sich in
den NoSQL-Datenbanksystemen Alternativen dazu finden lassen.
3.1
Definition Geodaten
Um die Komplexität von Geodaten selbst zu erfassen, ist es hilfreich eine genaue Definition zu betrachten. Ralf Bill gibt dafür folgenden Vorschlag:
„Geodaten sind Daten über Gegenstände, Geländeformen und Infrastrukturen an der
Erdoberfläche, wobei als wesentliches Element ein Raumbezug vorliegen muss. […]
Geodaten lassen sich über den Raumbezug miteinander verknüpfen, woraus insbesondere unter Nutzung von GIS-Funktionalitäten wiederum neue Informationen abgeleitet werden können […]“ (Bill 1999: 167). Besonders im Zusammenhang mit
Datenbanken spricht man auch von Geoobjekten - elementaren oder auch
zusammengesetzten Einheiten mit sowohl quantitativen (geometrischen und
topologischen) als auch qualitativen (thematischen) Komponenten. „Ein Objekt ist
dabei eine konkrete, physisch, geometrisch oder begrifflich begrenzte Einheit der Natur
und besitzt eine individuelle Identität.“ (ebd.: 10f.) Die Geometrie eines Objekts kann
dabei sowohl in Vektor- als auch Rasterdarstellung vorliegen, ihr Raumbezug indirekt
oder direkt hergestellt sein. (ebd.: 11)
Durch die weitreichende Definition von Geodaten unterscheidet sich auch die
Komplexität der unter Geodaten verstanden Informationen. Insbesondere Geoobjekte
in Vektordarstellung stellen eine Herrausforderung für die Wahl eines passenden
Datenmodells dar. Das verbreitetste ist dabei das (objekt-)relationale Datenmodell.
3 Anwendungspotential für Geodaten
3.2
22
Die Haltung von Geodaten in SQL-Datenbanken
Für die Verwaltung von Geodaten in einer relationalen Datenbank bestehen zwei
grundlegende Lösungen. Zum einen ist eine Speicherung der Geometrie in der unstrukturierten Form eines Binary Large Objects (BLOB) möglich, zum anderen kann sie
strukturiert unter Nutzung der numerischen Datentypen, die durch die Datenbank angeboten werden gespeichert werden. Beide Methoden haben dabei Vor- und Nachteile:
Die Speicherung als BLOB ist zwar einfach, der Zugriff muss aber in diesem Fall über
eine externe Anwendung sichergestellt werden und kann nur über eine eigene API
erfolgen. Es „handelt sich um solche Anwendungsdaten, die vom Datenbanksystem
gar nicht interpretiert, sondern nur gespeichert bzw. archiviert werden sollen“ (Kemper
2011: 421). Außerdem muss die Sicherung der Konsistenten zwischen der Geometrie
und den Sachdaten geregelt sein.
Die Speicherung der Geometrie in strukturierter Form stellt die zweite Möglichkeit dar,
bei der Topologie und Metrik mittels Normalisierung in Tabellenform abgebildet wird.
Durch einen hohen Grad an Normalisierung ist es möglich Anomalien im Datenbestand
Größtenteils vorzubeugen (ebd.: 179f.). Ein Nachteil ist jedoch, dass das Datenmodell
damit sehr umfangreich wird und das Antwortverhalten auf komplexe räumliche Abfragen nicht optimal ist (Bill 1999: 318). Möchte man Geodaten in einer relationalen
Datenbank in Abfragen zusätzlich mit Sachdaten verknüpfen führt dies je nach
Anwendungsfall zu komplizierten Statements.
Mit dem zunehmenden Erfolg objektorientierter Programmiersprachen haben Konzepte
der Objektorientierung auch Einzug in die relationalen Datenbanken gehalten. Durch
Typendeklaration und die Möglichkeit, Operationen auf diese Typen zu definieren,
ergaben sich damit auch für die Geodatenhaltung Vorteile, die in objektrelationelen und
objektorientierten Datenbanken umgesetzt werden konnten. Als Standard hat sich in
der GIS-Welt seit dem die „OGC Simple Features Specification for SQL“ durchgesetzt
welche von den verbreiteten Geodatenbanken wie Oracle Spatial oder PostGIS umgesetzt wird. Zunehmend wird dieses um Bestandteile des bedeutend umfangreicheren
konzeptuellen Schema ISO 19107 erweitert.
Der Entwicklungsstand dieser Geodatenbanken ist sehr hoch und stellt den aktuellen
Stand der Technik dar, wozu insbesondere die weitreichenden
Standardisierungbemühungen der OGC und der International Organisation for
Standardisation (ISO) mit beigetragen haben. Soll die Eignung von NoSQLDatenbanken für Geodaten eingeschätzt werden, muss also an den Qualitäten der
aktuellen objektrelationalen Datenbanken Maß genommen werden, das heißt, sie
sollten zumindest diesen Stand erreichen oder andere Qualitäten aufweisen, die sie für
die Nutzung interessant machen.
3 Anwendungspotential für Geodaten
3.3
23
Skalierbarkeit vs. Komplexität
In Hinblick auf die der NoSQL-Datenbanken zugrundeliegenden Datenmodelle fällt die
zunehmende Komplexität auf, mit der Daten strukturiert abgelegt werden können. Die
Ordnung in der die Datenbanken in Kapitel 2 vorgestellt wurden, ist dabei kein Zufall.
Emil Eifrem, ebenfalls beteiligt am Dialog zur Kategorisierung der NoSQLDatenbanken (s. Anhang 2), stellte dazu in einem Blog-Eintrag fest, dass die Komplexität des Datenmodells der NoSQL-Datenbanken beginnend bei den Key/Value und Wide Column Stores, über die Document Stores und schließlich bis hin zu den Graphdatenbanken zunimmt. Daraus ergibt sich eine Wechselwirkung mit der Skalierbarkeit der
Datenbank. Da Key/Value Stores und Wide Column Stores auf ein einfaches Datenmodell bauen, in denen die Datensätze keine bzw. geringe Beziehungen zueinander
haben, ist es besser möglich, die Daten horizontal zu Partitionieren und auf mehrere
Datenbankserver auszubreiten. Wie auch bei den SQL-Datenbanken ist dies beispielsweise für Graphdatenbanken schwieriger, da engere Verknüpfungen zwischen
den Daten bestehen (Eifrem 2009). Um Leseleistung zu erhöhen, bietet sich hier eher
eine Replikation auf mehrere Server an, womit jedoch die Größe der Datenbank auf die
„Größe“ des kleinsten Servers beschränkt bleibt.
Abbildung 11: Die Komplexität des untersetzten Datenmodells der NoSQL-Datenbanken unterscheidet sich stark und steht in Wechselbeziehung mit der zu erwartenden Skalierbarkeit.
(veranschaulichende Darstellung aus der Präsentation Emil Eifrems. (Eifrem 2009)
Es muss allerding betont werden, dass diese Überlegungen in vielerlei Hinsicht theoretischer Natur sind, da die Anforderungen sehr hoch sein müssen, um die Kapazität
eines Servers zu überschreiten (Edlich 2011: 377). Außerdem verschiebt ein einfaches
3 Anwendungspotential für Geodaten
24
Datenmodell die „Komplexität“ eine Stufe höher in die Anwendungsebene und erschwert so die Implementierung. Dementsprechend sollte die Wahl der richtigen Datenbank nach dem Zweck ihrer Anwendung erfolgen. (Eifrem 2009). Dies gilt insbesondere auch für die Verwaltung von Geodaten, denn der Nutzen, der aus Geodaten
gezogen werden soll, ist jeweils sehr unterschiedlich.
Wenn Web Services wie „FourSquare“ oder „Twitter“ Positionsdaten speichern und
diese mit Beiträgen und Fotos koppeln, dann dient dies in erster Linie zur reinen Präsentation des Ortes. Die weitreichendste Analyse, die auf diese Daten angewandt wird,
ist eine einfache Umkreissuche. Die Fragestellung „Wer hält sich in meiner Umgebung
auf?“ oder „Wo wurde dieses Foto aufgenommen?“ ist dabei keine zeitkritische, die
immer korrekt beantwortet werden muss. Viel wichtiger ist es für einen solchen Dienstleister, alle zur Verfügung gestellten Informationen zu speichern und dabei auch zu
Spitzenzugriffszeiten eine angenehme Nutzererfahrung zu gewährleisten. Die quantitative Komponente des Geoobjekts „Position“ beschränkt sich in diesem Fall lediglich auf
Punkte auf der Erde von denen anzunehmen ist, dass sie immer im gleichen Referenzsystem vorliegen werden, also keine weitere Informationen gesammelt werden muss.
In vielen Fällen ist die Positionsangabe auch nur optional und stellt so nur ein weiteres
Attribut der eigentlichen Informationseinheit „Statusmitteilung“ dar. Die Struktur der
Daten ist hier also wenig komplex.
Soll die Datenbank hingegen als Datenhaltungskomponente eines wertigen Geoinformationssystems eingesetzt werden, stellen sich andere Anforderungen, denn allgemein haben Geodaten eine viel komplexere Struktur. Außerdem ist hier der Anspruch
an standardisierte Schnittstellen viel größer.
Es soll gezeigt werden, wie diesen Ansprüchen gerecht zu werden ist. Dazu wird im
Folgenden in drei Ausprägungen von raumbezogenen Objekten unterschieden. Zum
einen ist unter „Positionsdaten“ eine Basisklasse von Objekten gemeint, dessen Geometrie lediglich aus einem Punkt besteht. Im speziellen bezieht sich dies auf eine Position, analog der Definition einer direkten Position in der „Simple Feature Specification“
(OGC 2011: 9). Des Weiteren sollen „komplexe Geodaten“ raumbezogene Daten nach
dem Vektormodell beschreiben. Dies sind Daten, die im eigentlichen Sinne komplexe,
auf punkt- und linienhaften Beschreibungen beruhende Datenstrukturen (Bill 1999: 21)
darstellen. Abschließend sollen Geodaten in einer Rasterdarstellung gesondert betrachtet werden.
3.4
Positionsdaten in NoSQL-Datenbanksystemen
Lässt man in einem Vektormodell lediglich Punkte, also die Träger der geometrischen
Information, zu, beschränkt also die topologische Dimension auf 0-Zellen (Nullzellen),
so liegen in diesem Modell keine topologischen Beziehungen zwischen Objekten vor.
3 Anwendungspotential für Geodaten
25
Die Kante, als Träger der topologischen Information, fehlt (Bill 1999: 15,18). Nach Ralf
Bill kann erst die „Vereinigung von metrischen und topologischen Daten […] zu […]
umfassenden räumlichen Datenmodellen führen, die in der Lage sind, auf einen
breitgefächerten Abfrageraum zu antworten“ (edb.: 255). Das im vorherigen Kapitel
gezeigte Beispiel zur Anwendung in Web Services hat aber gezeigt, dass solch ein
breitgefächerter Abfrageraum nicht unbedingt nötig ist, um Anforderungen bestimmter
Anwendungen zu befriedigen. Ist ein Modell ausschließlich bestehend aus
Punktobjekten ausreichend, so erleichtert dies die Organisation in einer Datenbank
enorm. Es handelt sich im Grunde genommen um ungeordnete raumbezogene Daten
ohne „die logische Zuordnung der Nachbarschaft“ wie sie durch Ralf Bill beschrieben
sind (edb.: 241).
Zu beachten ist, dass sich die Beschreibung für „ungeordneten raumbezogene Daten“
eigentlich auf Geometrieinformationen aus verschiedenen Quellen, wie beispielsweise
Koordinatenlisten, bezieht. Deren Attribute bzw. Sachdaten könnten in
unterschiedlicher Ausdehnung vorliegen. Dies ist durchaus ein Fall, der für dynamische
Webanwendungen eine Rolle spielen kann, beispielsweise um in einem neuen
Konzept auch Bilder mit einer Georeferenz zu versehen. Sollen diese Daten in eine
objektrelationale Geodatenbank geführt werden, so muss diese Ausdehnung der
Attribute durch Normierung in eine „einheitliche Dimension bzgl. der Tabellengröße“
gebracht werden. (edb.: 241f.) Dabei bestehen zwei grundlegende Probleme, die
bereits in Kapitel 1.7 angesprochen wurden:

Neue Attribute machen eine Schemaänderung der Relationen nötig, können
aber zu vielen leeren Zellen im Datenbestand führen.

Referenzierungen führen zu mehr Relationen und erschweren die Abfrage.
Hier kann sich also ein Vorteil ergeben, wenn von Seiten der Datenbank kein Schema
für die Struktur der Daten vorrausgesetzt wird. In jener Hinsicht kommen NoSQLDatenbanksysteme für die Lösung der Aufgabe in Frage.
Ein wesentlicher Nachteil der dabei jedoch berücksichtigt werden muss, ist, dass es für
Key/Value Stores und Wide Column Stores bis dato keine Spatial Extension gibt und
das keiner der Vertreter dieser Kategorien eine native multidimensionale Indexierung
unterstützt. (s. Anhang 2) Aus Kapitel 2 wissen wir allerdings, dass Document Stores
wie CouchDB/GeoCouch oder MongoDB einen zweidimensionalen Index für
Punktgeometrien bieten.
Die Implementierung ist bei beiden sehr unterschiedlich. Die CouchDB-Erweiterung
berechnet einen persistenten R-Tree-Index auf Grundlage der Bounding Box der
Geometrie (s. Anhang 1 und Katz 2012), MongoDB hingegen setzt auf einen
Algorithmus namens „GeoHash“ (Chodorow 2011). Das Grundprinzip beruht dabei auf
einer hierachischen Teilung der Eroberfläche in zunehmend kleinere Quadranten,
3 Anwendungspotential für Geodaten
26
indem Längen- und Breitengrad immer durch die Zahl 2 geteilt und so sukzessive
einem Binärcode zugewiesen werden. Die Besonderheit des entstehenden Hashcodes
ist dabei, dass die Auflösung der Quadranten durch die Anzahl der Stellen des
Hashwerts beeinflusst werden kann und dass nah beeinander liegende Punkte meist
den gleichen Prefix tragen. Wird die hinterste Stelle des Hashs gestrichen, vergrößert
sich so der durch den Wert dargestellte Quadrant (edb.). Der Geohash-Index ist bei
einer Umkreissuche in den Grenzbereichen eines Quadranten nicht schlüssig. Es kann
also nicht immer angenommen werden, dass die ersten Stellen zwei sich nahe
liegender Punkte den gleichen Prefix teilen. Dieses Problem kann allerdings
weitestgehend ausgeglichen werden, indem die acht umliegenden Quadranten
ebenfalls für den Test genutzt werden.
MongoDB nutzt dieses Prinzip sehr erfolgreich und konnte in der Vergangenheit viele
Kunden gewinnen, die die Datenbank für Geolocation Services einsetzen.
Abbildung 12: Visualisierung der "Geohash Quadranten". (Troy 2008)
3.5
Komplexe Geodaten in NoSQL-Datenbanksystemen
Unter „komplexen Geodaten“ sollen hier räumliche Objekte verstanden werden, deren
Geometrie in Vektordaten beschrieben ist. „Ihre Grundelemente sind der Punkt, die
Linie und die Fläche […]“ (Bill 1999: 21), wobei die graphische Grundstruktur aus
Punkten und Linien besteht durch welche Flächen als geschlossener Linienzug darge-
3 Anwendungspotential für Geodaten
27
stellt werden (ebd.). Ohne die im vorherigen Kapitel vorgestellten Beschränkungen
besteht die Geometrie von raumbezogenen Objekten nicht nur aus der metrischen Information des Punktes, sondern ist um topologische Beziehungen zwischen den Punkten bereichert.
Die Haltung von solch komplexen raumbezogenen Daten in Datenbanken ist bekanntermaßen nicht trivial. Diese Aufgabe wird allgemein zu den „Nichtstandardanwendungen (NSA) von Datenbankmanagementsystemen (DBMS)“ gezählt (Bill 1999: 327). Die
Nichtstandardanwendung für Geodaten hat dabei unter anderem die folgenden
Charakteristiken:

Die Daten sind typischerweise mehrdimensional und

sollen durch räumliche Bereichsabfragen aufrufbar sein.

Die Geometrien der Objekte können dabei aus einer Vielzahl logischer
Verknüpfungen bestehen, sie besitzen eine komplexe Struktur.

Außerdem werden für die Analyse raumbezogener Daten komplexer
Operationen vorrausgesetzt.

Aufgrund der Struktur und Größe der Objekte können Operationen auf
raumbezogene Daten deshalb zu langen Transaktionen führen (ebd.: 330).
Um eine grobe Einschätzung treffen zu können, inwiefern diesen Anforderungen
entsprochen werden kann, ist es hilfreich, einen kurzen Vergleich anzustellen.
Mehrdimensionalität: Das offensichtlichste Problem, das für Geodaten geklärt werden
muss, ist die Indexierung des multidimensionalen Raums. Die bereichsbezogene
Abfrage stellt hier mehr die Regel als die Ausnahme dar, also sollte die Indexierung
mindestens in X- und Y-Richtung möglich sein (Bill 1999: 330). Dieses Kriterium
beschränkt die Anzahl der Vertreter der NoSQL-Datenbanken auf sehr wenige die
entsprechende Erweiterungen anbieten. In der hier getroffenen Auswahl bieten nur
CouchDB mit den Spatial Extensions GeoCouch und Neo4j Spatial einen
mehrdimensionalen Index, der räumliche Abfragen über ihre API ermöglicht. Alternativ
können auch eigene Zugriffsmechanismen für die Datenbank der Wahl konstruiert
werden, allerdings ist dies auch mit einem gehörigem Mehraufwand für die Umsetzung
verbunden.
Komplexe Strukturen: Der Umsetzung einer Vielzahl logischer Verknüpfungen von
Geodaten steht außerdem das zugrundeliegende Datenmodell der meisten NoSQLDatenbanken entgegen, das auf Relationen zwischen den Datensätzen betont
verzichtet. Das gilt insbesondere für Key/Value und Wide Column Stores.
Konsequenter ist hier die Speicherung im Binärformat oder in einer textlichen
Repräsentation. Dies impliziert aber auch die gleichen Nachteile, wie sie bereits in
Kapitel 3.2 für SQL-Datenbanken in Bezug auf die Speicherung als BLOB beschrieben
3 Anwendungspotential für Geodaten
28
worden sind. Wieder ist es die der Datenbank übergeordnete Ebene, die diese Daten
interpretieren muss. Wie bereits durch Emil Eifrem festgestellt, verlagert sich die
Komplexität damit in die Anwendungsebene (Eifrem 2009). Es gilt die Entscheidung zu
treffen, ob die damit verbundenen Nachteile für die jeweilige Anwendung Sinn machen.
Die Nutzung des MapReduce-Paradigmas für exzessiv große Datenmengen kann
beispielsweise von Interesse sein und so die Nachteile aufwiegen. Document Stores
bieten hingegen die Möglichkeit, Daten denormalisiert in einem Dokument abzulegen.
Das macht die Datenverwaltung übersichtlicher und durch die Implementierung des
MapReduce-Paradigmas können diese effektiv auf Sachdaten durchsucht werden.
Graphdatenbanken beiten die weitreichste Möglichkeit Daten logisch zu Verknüpfen
und können durch Traversierungsalgorithmik auftrumpfen. Das macht sie für komplexe
Strukturen interessant.
Komplexe Operationen: Neben den einfachen den CRUD-Operationen (Create,
Read, Update, Delete) versteht man unter komplexen Operationen für Geodaten
bespielsweise das Verschneiden, die Ein- und Ausschlussberechnung oder das
Clipping von raumbezogenen Objekten (Bill 1999: 330). Nach der Definition der
NoSQL-Datenbank bieten diese aber ganz bewusst nur eine sehr einfache API an, um
so den Zugang für die Programmierung zu erleichtern (Edlich 2011: 2). Auf Grundlage
dieser APIs kann es möglich sein, Operationen auf die in der
Datenhaltungskomponente abgelegten Objekte zu implementieren, aber auch das ist
mit dem nötigen Aufwand verbunden. Die Spatial Extension Neo4j Spatial bietet hier
weitreichende Funktionalität, um raumbezogene Analysen durchzuführen und kann
diesen Punkt als einzige bedienen.
Lange Transaktionen: Das Thema der langen Transaktionen spielt auch für NoSQLDatenbanken eine entscheidene Rolle. Es findet eher der optimistische Ansatz per
Versionierung der Datensätze Anwendung. Dadurch ist der Zugriff auf den
Datenbestand nicht für weitere Nutzer gesperrt. Andererseits muss auch hier von der
Anwendungsebene bestimmt werden, wie mit Konflikten umgegangen wird. Aber auch
pessimistische Transaktionen werden durch NoSQL-Datenbanken bedient. Neo4j
erlaubt beispielsweise sowohl eine Lese- als auch Schreibsperre auf die betreffenden
Knoten und Kanten. Das entspricht weitesgehend der Umsetzung durch die meisten
SQL-Datenbanken. Eine optimale Lösung ist hier nicht zu erreichen.
3 Anwendungspotential für Geodaten
29
Tabelle 1: Eigenschaften von NoSQL-Datenbanken in Relation zu Charakteristiken von Nichtstandardanwendungen.
Key/Value
Store Redis
(VMWare
2011b und
2011d)
Wide Column
Store Cassandra
Document
Store
CouchDB mit
GeoCouch
(Katz und
Mische 2012)
Graphdatenbank
Neo4j mit Neo4j
Spatial
(NeoTechnology
2012 und Edlich
2011: 291)
Mehrdimensionaler
Index
Nein
Nein
Ja
Ja
Bereichsabfragen
Nur in Listen
& Sets
Ja, Columns und
Column Families
sortiert
Ja
Ja
Vielfache logische
Verknüpfung
Nein,
binärsichere
Speicherung
von Objekten
Nein, einfache
Strukturierung
und binärsichere
Speicherung von
Objekten
Nein,
schemafreie
Dokumente
Ja, durch
Traversierung
Komplexe
Operationen
Nein
Nein
Nein
Ja
Transaktionen
Ja
Nein
Ja, MVCC
ACID und Bulk
Betrachtet man die Eigenschaften der NoSQL-Datenbanken bzw. hier spezieller der
vorgestellten Vertreter der Datenbankkategorien, sieht man sich bestätigt, dass das
Datenmodell einen erheblichen Einfluss auf die Eignung für die
Datenhaltungskomponente in einem Geodatenbanksystem hat. Mangels
entsprechender Erweiterungen kommen Key/Value und Wide Column Stores leider nur
in Frage, wenn die zu erwartende Datenmenge wirklich dem Vielfachen entspricht, das
mit einer herkömmlichen Geodatenbank verarbeitet werden kann. Zugegebener Maßen
ist der Aufwand, die Datensätze in ihnen zu pflegen bedeutend höher, als der Nutzen
für ein mittelgroßes GIS sein kann.
Für Document Stores sieht das schon anders aus. Sie bieten durch das Konzept
schemaloser Dokumente zusammen mit einer multidimensionalen Abfragemöglichkeit
via Spatial Extension und der Implementierung von MapReduce eine interessante
Alternative zur Haltung von Geodaten in einer SQL-Datenbank. Um sich dem
umfassender zu widmen, soll die Implementierung einer Anwendung mit CouchDB und
GeoCouch in Kapitel 4 gesondert betrachtet werden.
Auch Graphdatenbanken nehmen in diesem Vergleich eine gewisse Sonderstellung
ein. Sie ermöglichen eine ebenso komplexe Strukturierung von Daten wie dies die
relationalen Datenbanken tun. Darüber hinaus bieten sie ein Datenmodell das diese
besser nachvollziehbar macht. Gerade für die Geodatenhaltung ist das Modellieren von
Topologie eine bedeutende Herrausforderung. Deshalb soll die Implementierung einer
Anwendung zur Analyse von Geodaten in Kapitel 5 eine weitere Rolle spielen.
3 Anwendungspotential für Geodaten
3.6
30
Rasterdaten
Neben den bereits besprochenen Vektordaten nimmt die Verwaltung von Rasterdaten
in Geoinformationssystemen eine wichtige Rolle ein. Die graphische Grundstruktur von
Rasterdaten ist das Pixel „welches zeilen- und spaltenweise in einer Matrix
gleichförmiger, quadratischer oder rechteckiger Elemente angeordnet ist“ (Bill 1999:
22). Es gibt „keine Unterscheidung nach Punkt, Linie oder Fläche, das heißt, es
existieren keine logischen Verbindungen zwischen den einzelnen Bildelementen“
(ebd.). Die Datenstruktur ist also bedeutend einfacher als die der strukturierten
Vektordaten und Analysen basieren auf simpleren Algorithmen. Da der Speicherbedarf
von Rasterdaten den von Vektordaten aber typischerweise bei weitem übertrifft, ist die
Ausführung von Berechnungen deshalb nicht schneller (Schneider 1993: 7). Die Daten
können beispielsweise als Satellitenaufnahmen der Fernerkundung vorliegen oder als
Scans bestehender Kartenwerke.
Ein interessantes Beispiel für die Handhabe von Rasterdaten in einer NoSQLDatenbank gibt Google durch sein Produkt Google Earth. Die Haltung und Aufbereitung wird nach eigner Aussage in Google BigTable verwirklicht. 2006 ist die Tabellengröße allein mit 70 Terrabyte angegeben. Während allein das Speichern einer solchen
Datenmenge auf einem Rechner unmöglich ist, sind Berechnungen auf eine solch
enorme Menge von Daten nur durch massive Parallelisierung möglich. Um die Satellitenbilder letztendlich für die Darstellung im Browser oder der Clientanwendung Google
Earth aufzubereiten, wird das MapReduce Framework eingesetzt, welches die Daten
bereinigt und letztendlich in geographische Segmente teilt. Eine weitere, bedeutend
kleinere Tabelle von 500GB hält außerdem die Indexierung des Bildmaterials im verteilten Dateisystem GFS vor und dient zur Interaktion mit dem Nutzer. Allein diese Tabelle ist über hunderte von Server gehostet, um zehntausende Anfragen pro Sekunde
zu befriedigen (Chang 2006: 10f.). Während die Haltung von solchen Datenmengen
eher die Ausnahme ist, verdeutlicht Google damit aber das enorme Leistungspotential
das von verteilten Systemen ausgeht.
3.7
Zukünftige Entwicklungen
Neben der eigentlichen Datenhaltung spielt gerade auch die Interoperabilität von georeferenzierten Daten zwischen verschiedenen Systemen eine wichtige Rolle und stellt
ein altes Problem dar (de Souza Baptista 2011). Durch die Entwicklung der NoSQLDatenbanken ist denkbar, dass etwa CouchDB, Neo4j oder MongoDB zu einer heterogeneren Landschaft im Umfeld der Geoinformation führen können. Darüber hinaus ist
es auch für die Nutzer klassischer SQL-Geodatenbanken interessant, Informationen
aus dem Umfeld der Social Networks in Analysen einzubeziehen, denn hier hat NoSQL
bereits viel Anwendung gefunden. Es wird also in Zukunft unumgänglich sein, sich um
3 Anwendungspotential für Geodaten
31
Schnittstellen zwischen den Welten zu bemühen, um so den Informationsfluss zu fördern.
Der wohl überzeugendste Weg, ist es auf bereits bestehende Standards zurückzugreifen. Neben dem Im- und Export über bekannte Formate, ist die Implementierung von
Web Services wie dem OGC Web Map Service (WMS) und dem Web Feature Service
(WFS) die lohnenswerteste, da so jeder Client mit Unterstützung dieser Services Zugriff auf die Daten erhalten kann. Cláudio de Souza Baptista et al. haben mit dieser
Begründung einen ersten erfolgreichen Vorschlag geleistet, wie eine solche Schnittstelle für GeoCouch aussehen kann. Sie nutzten den modularen Aufbau CouchDBs, um
einen Service Layer für die NoSQL-Datenbank zu integrieren.
Nicht zuletzt zeigt auch die Integration des CouchDB-Treibers in die GDAL-Bibliothek
ab Version 1.9 (GDAL 2011), dass gerade von Seiten der OpenGIS-Bewegung reges
Interesse an solchen „Speziallösungen“ bestehen muss. GDAL dient vielen OpenSource-Projekten wie QGIS und uDIG als abstraktes Datenmodell für den Zugriff
auf Geodaten. So kann erwartet werden, dass über kurz oder lang auch CouchDB in
diese Lösungen integriert werden wird. Wünschenswert ist, dass auch andere NoSQLDatenbanken sich diesem Trend in Zukunft anschließen.
Interessant ist in diesem Zusammenhang auch, dass am 1. November 2011 das Open
Geospatial Consortium die Gründung einer Arbeitsgruppe zur Ausarbeitung eines OGC
Standards für RESTful Web Services verkündet hat. Das erwartete Ergebnis dieser
Arbeitsgruppe ist eine formalisierte Regelung für die standardisierte Implementierung
von REST-Services für geographische Abfragen (Open Geospatial Consortium 2011)
Während auch kommerzielle Anbieter wie ESRI Interesse an einer solchen
Standardisierung haben dürften, kann dies auch für Vertreter der NoSQL-Datenbanken
von Interesse sein.
4 Implementierung einer Webpräsenz für Geodaten mit CouchDB und GeoCouch
4
32
Implementierung einer Webpräsenz für Geodaten
mit CouchDB und GeoCouch
Geodaten dienen vielen verschiedenen Zwecken. Neben der Pflege komplexer Daten
in den Vermessungsverwaltungen und der Analyse von Raumdaten durch Spezialisten
dienen sie häufig zur anschaulichen Präsentation von Sachverhalten unserer Umwelt.
Eine typische Lösung einer solchen Präsentation besteht in der Bereitstellung einer
Website, die einen WFS oder WMS-Service via Geoserver abruft. Dieser liest Daten
aus einer objektrelationalen Geodatenbank wie PostGIS.
Da CouchDB einen HTTP-Server integriert und GeoCouch grundlegende räumliche
Abfragen erlaubt, soll diese Pilotanwendung zeigen, wie die Umsetzung einer solchen
Präsentation stark vereinfacht ablaufen kann. Zweck der Aufgabe ist es, auf einen
WFS oder WMS-Server zu verzichten und sowohl Webseite als auch Geodaten über
eine CouchDB-Instanz zur Verfügung zu stellen. Die einzelnen Schritte umfassen dabei:

Geodaten in CouchDB einlesen

Mit der Erweiterung GeoCouch vertraut machen und einen Abfragemechanismus definieren

Webseite über CouchDB hosten
Datengrundlage sollen dabei öffentlich verfügbare Geodaten sein, wie sie von öffentlichen Trägern angeboten werden. Dies umfasst insbesondere Informationen zu Landespflege und Naturschutz, wie sie beispielsweise auch in den Beständen des Landes
Brandenburg zu finden sind. Sie können unter der Website
http://www.mugv.brandenburg.de/cms/detail.php/bb2.c.515599.de (Lukas 2012) abgerufen werden und sollen in diesem Entwurf als Datengrundlage für eine digitale Übersichtskarte dienen, die es Interessierten ermöglicht, sich über Naturschutz im Land
Brandenburg zu erkundigen.
Zur Umsetzung kommt CouchBase Single Server Version 1.2 als vorkompiliertes Packet aus CouchDB 1.1.0 und GeoCouch zum Einsatz. Außerdem findet die Folgende
Software Anwendung:

GDAL Library 1.9

jQuery 1.7.1

Leaflet.js 0.3.1
4 Implementierung einer Webpräsenz für Geodaten mit CouchDB und GeoCouch
4.1
33
Vorbereitung der Daten für CouchDB
Wie bereits in Kapitel 2.4.2 vorgestellt, erwartet CouchDB Daten im JSON-Format. Die
vom Brandenburger Ministerium bereitgestellten Daten liegen allerdings als Shapefiles
vor und müssen zunächst entsprechend umgewandelt werden. Außerdem ist es sinnvoll, vom durch das Land Brandenburg genutzten Koordinatenreferenzsystem ETRS89
BB in WGS84 zu transformieren. Dies erleichtert später die Integration in bestehende
Mapping-Frameworks, ist aber ein optionaler Schritt. Beide Operationen sind mit dem
durch die Open Source Geospatial Foundation (OSGEO) beförderten Framework
GDAL (Geospatial Data Abstraction Library) bzw. der enthaltenen Sub-Library OGR
möglich. Mit Version 1.9 wurde die OGR Simple Feature Library um eine Schnittstelle
für CouchDB erweitert, die die bereits bestehende GeoJSON Unterstützung nutzt, um
Geodaten so per HTTP-PUT auf eine CouchDB zu übertragen.
Die Transformation mit dem Konsolentool OGR2OGR sieht dabei folgendermaßen aus:
$ ogr2ogr -t_srs EPSG:4326 output_4326.shp input.shp
Beim Übertragen der Daten auf eine CouchDB-Instanz kann außerdem ein AdminZugang spezifiziert werden:
$ ogr2ogr -f couchdb "couchdb:http://user:pwd@host:port" output_4326.shp
OGR2OGR legt pro Feature je ein JSON-Dokument in die Datenbank, welches die
Geometrie als GeoJSON-Objekt enthält. Im Beispiel wird dieses Dokument in die Datenbank „output_4326“ hinterlegt. Bestehende Attribute und Metadaten werden im
JSON-Objekt „properties“ abgelegt, wodurch das Dokument nun über die URI
http://host:pwd/output_4326/_id verfügbar ist. Mit dem erstmaligen Speichern des
JSON-Dokuments wird durch CouchDB ebenfalls eine Revisionsnummer „_rev“ angelegt, die für die MVCC-Versionierung genutzt wird.
4 Implementierung einer Webpräsenz für Geodaten mit CouchDB und GeoCouch
34
{
"_id": "000000202",
"_rev": "1-57b1dffc6a3c47d428252db519fad50f",
"type": "Feature",
"properties": {
"AST__NR": "1068456000",
"NAME": "Global Wind Power A/S",
"ANL__NR": "4016",
"BEZEICHNUN": "WKA NEG Micon NM 82/1500",
[…]
"ROTORDURCH": "82",
"NABENHOEHE": "108"
},
"geometry": {
"type": "Point",
"coordinates": [
12.271748312990185,
52.895952732225524
]
}
}
Abbildung 13: JSON-Dokument eines Features des Typs Point. (gekürzt)
4.2
Abfrage der Datensätze aus CouchDB
Die einfachste Abfragemöglichkeit ist der direkte Zugriff auf ein Dokument über den
Namen der Datenbank und den Identifikator in der Form:
http://host:port/db/_id
Die Antwort erfolgt als HTTP-Response, dessen Körper das Dokument als JSONObjekt enthält.
Um umfangreichere Abfragen auf Grundlage der Dokumente zu verwirklichen, kann ein
„View“ eingesetzt werden. Sie werden in Design-Dokumenten als JavaScriptFunktionen definiert und unter dem Attribut „views“ gespeichert. Dadurch sind sie unter
der URI des Designdokuments und dem Zusatz „_view/viewname“ identifizierbar. So ist
es möglich, per MapReduce-Verfahren nach Untermengen des Datenbestands zu filtern und die Ergebnismenge als Ressource des HTTP-Servers abzufragen.
function(doc) {
if(doc.properties) {
emit(doc.properties.BEZEICHNUN, doc.properties.LEISTUNG)
}
}
Abbildung 14: Eine einfache Map-Funktion. Sie durchläuft jedes Dokument der Datenbank,
testet, ob das JSON-Objekt „properties“ vorhanden ist und emittiert das Attribut „BEZEICHNUN“
als Key bzw. „LEISTUNG“ als Value. Über eine optionale Reduce-Funktion ließe sich das Ergebnis der Map-Funktion aggregieren.
4 Implementierung einer Webpräsenz für Geodaten mit CouchDB und GeoCouch
35
Die Ergebnismenge einer MapReduce-Funktion wird durch CouchDB mit der ersten
Abfrage indexiert. Später hinzugefügte Datensätze werden mit jeder weiteren Abfrage
sukzessive im Index eingepflegt.
function(doc) {
if(doc.geometry) {
emit(doc.geometry, doc.properties);
}
}
Abbildung 15: „Geometrie“ emittierende Map-Funktion. Sofern vorhanden, wird das
(GeoJSON) Objekt "geometry" als Schlüssel emittiert. Die Eigenschaften „properties“ schließen
als Values der Ausgabeliste an.
Diese Map-Funktion allein unterstützt noch keine räumlichen Suchanfragen. Würde sie
in einem Designdokument einfach als „View“ gespeichert werden, wäre mit dem ersten
Abrufen ein B-Tree-Index angelegt, wie er auch für jeden anderen eindimensionalen
View eingesetzt wird. Die Spatial Extension GeoCouch erweitert hier die Indexierungsfähigkeiten um einen R-Tree-Index. Um diesen zu nutzen, wird die Mapping-Funktion
im Designdokument unter dem Attribut „spatial“ gespeichert.
{
"_id": "_design/technik",
"_rev": "1-b5319680744d68d3a7ab145623fc18a9",
"spatial": {
"pos":
"function(doc) {
if (doc.geometry){
emit(doc.geometry, doc.properties);
}
}"
}
}
Abbildung 16: Design-Dokument. Das Dokument "technik" umfasst nur den Spatial-View "pos".
Um anschließend eine räumliche Abfrage durchzuführen, wird die URI, welche auf das
definierte Design-Dokument zeigt, um den Parameter „_spatial“, den Namen des Spatial Views sowie die gesuchte Bounding Box ergänzt. Eine räumliche Abfrage der enthaltenen Features im umschließenden Rechteck mit den Koordinaten [(52°,13°),
(53°,14°)] auf das Designdokument „technik“ und dessen Spatial-View „pos“ würde wie
folgt lauten:
http://host:port/wka_4326/_design/technik/_spatial/pos?bbox=13,52,14,53
Zu beachten ist, dass die Implementierung dem Entwurf der OpenSearch Spezifikation
für Geodaten folgt. Auch dieser empfiehlt die Nutzung des EPSG:4326 und setzt die
4 Implementierung einer Webpräsenz für Geodaten mit CouchDB und GeoCouch
36
Konstruktion des umschließenden Rechtecks in der Form minX, minY, maxX, maxY
voraus. Achtung muss hier beim Überspannen der Datumsgrenzen geboten sein. In
der aktuellen Version von GeoCouch für CouchDB 1.2.x steht die Bounding Box Suche
als einzige räumliche Funktion zur Verfügung.
Die nachfolgende Antwort der CouchDB-Instanz entspricht einem JSON-Dokument,
das die ermittelten Datensätze im Objekt „rows“ als Array von JSON Objekten enthält:
{
"update_seq":3475,
"rows":[{
"id":"000000989",
"geometry":{
"type":"Point",
"coordinates":[13.53925025567202,52.60986928248099]
},
"value":{
"AST__NR":"2060379000",
"NAME":"Phase 5 GmbH & Co Lindenberg 4 KG",
"ANL__NR":"0001",
[…]
"GEN_NIB":"ja",
"GEPLANT":null,
"ROTORDURCH":"92",
"NABENHOEHE":"100"
}},
[…]
]
}
Abbildung 17: Antwortdokument eines Bounding Box Querys. (Gekürzt)
4.3
Abfrage von Datensätzen als FeatureCollection
Bei dem im HTTP-Body erhaltenen JSON-Dokument einer CouchDB-Abfrage handelt
es sich nicht um ein GeoJSON-Objekt, sondern um ein valides JSON. Das heißt, dass
die gewonnen Datensätze in dieser Form nicht weiter für Mapping-Aufgaben genutzt
werden können, ohne dass GeoJSON-Objekt („geometry“) zu extrahieren und die gewünschten Attribute mit anzuführen.
CouchDB bietet hier mit der Funktion „List“ ein mächtiges Werkzeug. Sie verarbeitet
die Zeilen der Ergebnisliste einer Mapping-Funktion und formatiert sie nach einer gewählten Vorschrift in eine Liste von Objekten. Abbildung 18 zeigt hierfür eine JavaScript-Funktion, welche eine Ergebnisliste mit den Spalten „geometry“ und „value“ in
eine GeoJSON-FeatureCollection wandelt.
4 Implementierung einer Webpräsenz für Geodaten mit CouchDB und GeoCouch
37
function(head, req) {
var row, out, sep = '\\n';
if (typeof(req.headers.Accept) != "undefined"
&& req.headers.Accept.indexOf('application/json')!=-1)
start({"headers":{"Content-Type" : "application/json"}});
else
start({"headers":{"Content-Type" : "text/plain"}});
if ('callback' in req.query)
send(req.query['callback'] + "(");
send('{"type": "FeatureCollection", "features":[');
while (row = getRow()) {
out = '{"type": "Feature", "id": ' + JSON.stringify(row.id);
out += ', "geometry": ' + JSON.stringify(row.geometry);
delete row.geometry;
out += ', "properties": ' + JSON.stringify(row.value) + '}';
send(sep + out);
sep = ',\n';
}
send("]}");
if ('callback' in req.query) send(")");
};
Abbildung 18: List-Funktion. Sie wandelt die Ergebnisse eines GeoCouch Spatial-Views in
eine GeoJSON-FeatureCollection. (Ogden 2011)
4.4
Integration der GeoCouch-Daten in eine Website
Um die Geodaten verfügbar zu machen, sollen sie als ein Vektorlayer auf einer Karte
dargestellt werden. Die Implementierung erfolgte in HTML und JavaScript, wobei die
Leaflet-Karte in einen div-Block eines einfachen *.html-Dokuments eingebunden wurde. Das Abrufen der Kartenwerke und weitere Zusatzfunktionen sind ebenfalls mit
Leaflet implementiert und hier nicht weiter beschrieben.
Um den Datenfluss auf ein Minimum zu reduzieren und so den Kartenaufbau zu beschleunigen, ist es möglich, über die Methode getBounds() der Leaflet-Karte die aktuelle Ausbreitung der Karte abzufragen. Diese können als Parameter im AJAX-Request
an die CouchDB übergeben werden, wie es in 5.3.3 bereits beschrieben wurde. Die in
der aktuellen Ausbreitung befindlichen Features können auf diese Weise bestimmt und
durch die in Abbildung 19 gezeigte Map-Funktion „pos“ als Ergebnisliste emittiert werden. Die Liste wird anschließend durch die in Abbildung 18 vorgestellte List-Funktion in
eine GeoJSON-FeatureCollection gewandelt und so als Antwort übertragen.
4 Implementierung einer Webpräsenz für Geodaten mit CouchDB und GeoCouch
38
function loadPlacesWka(bounds) {
$.ajax( {
type: 'GET',
url: 'http://localhost:5984/wka_4326/' +
'_design/simplegeo/_spatial/_list/geojson/pos?bbox='
+ bounds._southWest.lng + ','
+ bounds._southWest.lat + ','
+ bounds._northEast.lng + ','
+ bounds._northEast.lat,
dataType: 'json',
success: function (data) {
[…]
wkaGeoJSON.on("featureparse", function (e) {
var popupContent = '<p>';
if (e.properties && e.properties.NAME){
popupContent+='Name: ' + e.properties.NAME + '<br />'
}
[…]
popupContent+='</p>';
if (popupContent!='<p></p>') {
e.layer.bindPopup(popupContent);
}
});
wkaGeoJSON.addGeoJSON(data);
map.addLayer(wkaGeoJSON);
layersControl.addOverlay(wkaGeoJSON, "Windkraftwerke");
},
error: function (req, status, error) {
alert('Unable to get data:' + error);
}
});
Abbildung 19: AJAX-Request an eine CouchDB. Hier wird das Design-Dokument „simplegeo“
in der Datenbank „wka_4326“ angefragt. Die darin gespeicherte List-Funktion „geojson“ wandelt
dann das Ergebnis des Spatial-View „pos“, der mit den Parametern einer Bounding Box aufgerufen wurde, um. Die nachfolgenden Methoden im Körper der „success“-Funktion sind Bestandteil des Leaflet.js-Frameworks und parsen die gewonnene FeatureCollection für die Darstellung.
Da neben der eigentlichen Geometrie auch die Sachdaten im JSON-Objekt „properties“
übermittelt werden, können diese als interaktive Marker auf der Karte eingebunden und
dem Nutzer verfügbar gemacht werden. Mit einem Mausklick auf das zu untersuchende Feature lassen sich so weitere Informationen abrufen (s. Abbildung 19).
Die Webseite und alle referenzierten JavaScript-Dateien wurden anschließend als Attachement an ein Design-Dokument angehangen. So ist der Zugriff per URI der Webseite als Anhang des Designdokuments in der Form
http://host:port/db/_design/technik/index.html möglich.
4 Implementierung einer Webpräsenz für Geodaten mit CouchDB und GeoCouch
39
Abbildung 20: Screenshot der Konzeptanwendung "Brandenburger Schutzgebiete". Durch
Klicken auf eines der Features wurden hier Zusatzinformationen zu einem Wasserschutzgebiet
aufgerufen. Außerdem sind Windkraftwerke (blaue Marker) und ein Schutzgebiet (grünes Polygon) in der näheren Umgebung eingeblendet.
4.5
Fazit
Das Aufsetzen einer Webpräsentation von Geodaten hat sich als sehr einfach und
praktikabel erwiesen. Der Verwaltungsaufwand ist gering, da für die zu verwaltenden
Dokumente kein Schema angelegt werden muss. Im Ergebnis sind alle Komponenten
dieser Anwendung über einen einzige Server verfügbar die beginnend mit der Webseite aus der CouchDB-Instanz geladen werden. Die Reihenfolge sieht dabei folgendermaßen aus:

Anfrage des index.html-Dokuments über die URI

Referenzierte JavaScript-Bibliotheken werden nachgeladen

Interaktive Karte wird initialisiert und Features werden asynchron abgefragt und
als Vektorlayer auf die Karte gemappt
Durch die Formatierungsmöglichkeiten der List-Funktion bieten sich vielfältige Schnittstellen, da Geodaten, wenn auch mit einem höheren ersten Aufwand, an das gewünschte Mapping-Framework angepasst werden können.
Zu beachten ist, dass die erste Indexierung als R-Tree für große Datenbestände zeitaufwändig ausfallen kann. Dies sollte beim Erstellen einer Webpräsens berücksichtigt
werden, um Nutzern die Wartezeit zu ersparen. Nachdem der Index bereitsteht, werden neue Features mit dem ersten Aufruf in den Index eingepflegt, er muss also nicht
komplett neu generiert werden. Des Weiteren fiel im Testbetrieb und speziell beim Testen verschiedener Spatial Views auf, dass der Index eines Views sehr schnell viel
4 Implementierung einer Webpräsenz für Geodaten mit CouchDB und GeoCouch
40
Speicherplatz in Anspruch nehmen kann. Um Speicherplatz zu sparen, ist es sinnvoll,
alte Views durch den „Compaction“-Befehl zu entfernen, der durch CouchDB bereitgestellt wird.
Die Abfragemöglichkeiten beschränken sich im Moment auf einfache Bounding Box
Queries. In Kombination mit dem angewandten MapReduce-Verfahren und den Formatierungsmöglichkeiten lässt sich dies für mächtige Sachabfragen mit geographischem
Bezug einsetzen. Für umfangreiche Analysen ist GeoCouch aber zum gegenwärtigen
Zeitpunkt nicht einsetzbar. Es ist auch fraglich, ob dies ein erklärtes Ziel für das GeoCouch-Team sein wird. Nichtsdestotrotz sind nach eigenen Aussagen des GeoCouch-Programmierers Volker Mische weitere Funktionen in Arbeit (s. Anhang 1).
5 Navigationsanwendung mit Neo4j Spatial
5
41
Navigationsanwendung mit Neo4j Spatial
Die Suche nach einem Weg zwischen zwei Punkten ist eine der grundlegenden Fragen, die durch Geodaten beantwortet werden können. Die Suche lässt sich durch Bedingungen, wie das Finden des kürzesten oder schnellsten Weges, beliebig erweitern.
Die Beschreibung eines solchen Weges wird sich allgemein auf die einzelnen Wegpunkte und die Folgerichtung beziehen die dabei passiert werden müssen. Im Grunde
lässt sich dieses Problem also auf einen Graphen reduzieren, dessen Knoten die
Wegpunkte und dessen Kanten die Wege zwischen diesen Punkten beschreibt. Entscheidend für das Traversieren eines solchen Graphen ist in erster Linie nicht die Metrik der Punkte, sondern ihre Topologie. Diese sollte sich in einer Graphdatenbank wiedergeben lassen.
Im Folgenden soll ein Beispiel für eine solche Problemlösung gegeben werden, bei
dem topologisch strukturierte Geodaten in die Graphdatenbank Neo4j importiert werden und anschließend zwischen gegebenen Start- und Zielkoordinaten der kürzeste
„befahrbare“ Weg ermittelt wird.
Für die Implementierung in Java kommt Neo4j Community Edition in der Version 1.6
und die Spatial Extension Neo4j Spatial als Development Snapshot Version 0.8 zum
Einsatz. Beide stehen unter der GPL. Neo4j Spatial baut auf das OpenGIS GeoTools
Toolkit auf, welches in Version 8.0 Milestone 4 bereitsteht.
5.1
Vorbereitungen
Neo4j implementiert beruhend auf der Graphentheorie bereits umfassende Algorithmen, um die Datensätze im Graphen zu traversieren. Am einfachsten ist dies in der
Webkonsole des Datenbankservers zu testen (s. Kapitel 2.5.2). Die Abfrage erfolgt mit
der Traversierungssprache Cypher.
neo4j-sh (0)$ START a=node(2093), x=node(6)
MATCH p = shortestPath( a-[*..15]-x ) RETURN p
==> +----------------------------------------------------+
==> | p
|
==> +----------------------------------------------------+
==> | (2093)<--[TEST,3114]--(500)--[CHANGESET,499]-->(6) |
==> +----------------------------------------------------+
==> 1 rows, 1 ms
Abbildung 21: Abfrage des kürzesten Pfads der Länge 2 zwischen den Knoten mit der ID 2093
und 6. Das MATCH-Statement gibt hier Bedingungen für die Traversierung der Kanten im
Graph. Da nicht explizit ein Label in der Form [:LABEL] angegeben ist, werden alle in Frage
kommenden Beziehungen durchlaufen. Der Parameter *..15 beschränkt die Suche dabei auf
maximal 15 Schritte.
Die in Abbildung 21 gezeigte Berechnung des kürzesten Pfades bezieht sich auf einen
ungewichteten Graphen und zählt lediglich die zurückgelegten Schritte. Soll sich die
5 Navigationsanwendung mit Neo4j Spatial
42
Auswertung auf die tatsächliche geometrische Länge beziehen, wie es von einer Navigationsanwendung erwartet werden würde, so müsste das Gewicht der Kante also
entweder implizit aus den Eigenschaften der Knoten berechnet werden oder explizit als
Gewicht der Kante verfügbar sein.
5.2
Datengrundlage
Als Datengrundlage für den Prototypen einer Navigationsanwendung sollen die Vektordaten des OpenStreetMap-Projekts dienen. Sie können direkt auf der Website
http://www.openstreetmap.org/ im OpenStreetMap-XML-Format exportiert werden.
Alternativ bieten andere Webseiten Datensätze, an die das Downloadlimit des OpenStreetMap-Projekts überschreiten. Unter http://download.geofabrik.de/osm/ sind tagesaktuelle Datensätze ganzer Kontinente und Staatsgebiete sowohl als OSM (OpenStreetMap-XML) als auch Shapefiles verfügbar (Geofabrik GmbH 2012). Das Standardformat
für Geo-Vektordaten ESRI Shapefile bietet allerdings keine persistente Speicherung
von Topologien. Das bedeutet, dass sie durch die verarbeitende Anwendung erzeugt
werden muss. Für diese Pilotanwendung kommt deshalb das semi-strukturierte OSMFormat in Frage, welches die von Nutzern gesammelten Informationen in folgender
Gestalt aufbereitet darstellt:
<osm version="0.6" generator="CGImap 0.0.2">
<bounds minlat="54.0" minlon="12.2" maxlat="54.0" maxlon="12.2"/>
<node id="298884269" lat="54.0" lon="12.2"
user="SvenHRO" uid="46882" visible="true" version="1"
changeset="676636" timestamp="2008-09-21T21:37:45Z"/>
...
<way id="26659127" user="Masch" uid="55988" visible="true" version="5"
changeset="4142606" timestamp="2010-03-16T11:47:08Z">
<nd ref="292403538"/>
...
<tag k="highway" v="unclassified"/>
<tag k="name" v="Pastower Straße"/>
</way>
<relation id="56688" user="kmvar" uid="56190" visible="true"
version="28" changeset="6947637" timestamp="2011-01-12T14:23:49Z">
<member type="node" ref="294942404" role=""/>
...
<tag k="type" v="route"/>
</relation>
...
</osm>
Abbildung 22: Gekürztes Beispiel einer OSM-XML-Datei. (OpenStreetMap Wiki 2011).
Neo4j Spatial implementiert in der aktuellen Version mehrere Möglichkeiten, Geodaten
einzupflegen. Neben dem Einlesen der Geometrie als Well-known Text oder Wellknown Binary steht die Möglichkeit des Imports von Shapefiles und OSM-Dateien bereit.
5 Navigationsanwendung mit Neo4j Spatial
43
GraphDatabaseService databaseService = new EmbeddedGraphDatabase(storeDir);
…
OSMImporter importer = new OSMImporter(layerName);
…
importer.importFile(db, osmPath);
importer.reIndex(db, 1000);
…
Abbildung 23: Import einer OSM-Datei in eine eingebettete Graphdatenbank.
Der entstandene Graph lässt sich mit dem Programm Neoeclipse visualisieren und auf
seine Struktur untersuchen. Besonders interessant ist es hier zu erkennen, wie die
Topologie der Pfade in der Datenbank repräsentiert ist. In Abbildung 24 ist der SubGraph eines OSM-Weges des Typs „highway: residential“ zu sehen. Die Kante mit dem
Label „FIRST_NODE“ ist auf den ersten Knoten gerichtet, welcher selbst keine Eigenschaften trägt. Jeder dieser Stützpunkte eines Weges besitzt genau eine Kante des
Typs „NODE“, dessen Endpunkt Träger der Informationen des Wegpunktes, wie
Rechts- und Hochwert, sowie der „node_osm_id“ ist. Um dem Weg zu folgen, kann
entlang der Kanten mit dem Label „NEXT“ traversiert werden. Neben dem eigentlichen
Label zeichnet sich diese Kante durch die Eigenschaft „lenght“ aus, welche beim Importieren aus den gegebenen Koordinaten berechnet wird. Es handelt sich also um
einen gewichteten Sub-Graphen.
Abbildung 24: Visualisierung in Neoclipse.
5 Navigationsanwendung mit Neo4j Spatial
44
Die Nachbarschaftsbeziehungen zu angrenzenden Pfaden lassen sich über die „NODE“-Relationen herstellen. Punkte, an denen sich die Wege kreuzen, zeigen auf den
gleichen Knoten. Die Beziehung wird hier über die „node_osm_id“ hergestellt, welche
in der OSM-XML enthalten ist. Die Kanten sind gerichtet, so dass neben dem eigentlichen Label „NEXT“ bzw. „NODE“ und der Eigenschaft „length“ auch die Richtung der
Kante genutzt werden kann, um den gesuchten Pfad über mehrere OSM-Wege hinweg
zu identifizieren. Eine Kreuzung zwischen zwei OSM-Wegen ist in CypherSchreibweise also immer von der Form:
a-[:NODE]->()<-[:NODE]-b
Abbildung 25: Cypher MATCH-Statement welches vom Knoten "a" ausgehend genau zwei
gerichtete Kanten mit dem Label "NODE" traversiert und den Knoten "b" erreicht. Die Richtung
ist dabei intuitiv durch die Pfeile gekennzeichnet. Der im Pfad enthaltene Knoten wird durch das
Klammerpaar als beliebig interpretiert.
Ein Beispiel für solch eine Kreuzung von zwei Wegen wird an dem in Abbildung 24 hell
hervorgehobenen Knoten deutlich. Er ist Träger der metrischen Information der anliegenden Geoobjekte. Es zeigen daher zwei Kanten mit dem Label „NODE“ auf ihn. Wird
eines der Objekte gelöscht, ist die Topologie des angrenzenden Objekts trotzdem noch
voll erhalten.
5.3
Auffinden des nächsten Knoten zu einer beliebigen
Koordinate
In einer Navigationsanwendung ist die Definition des Start- und Zielpunkts bekanntlich
beliebig durch den Nutzer einzugeben und geschieht im Allgemeinen über die Angabe
einer Adresse. Um das Programm „NeoGIS“ zu vereinfachen, wird davon ausgegangen, dass die Adresse bereits auf eine Koordinate im vorliegenden Referenzsystem
zurückgeführt ist. Das Problem reduziert sich also hier auf die Suche des „Nearest
Neighbor“ zu dieser Koordinate.
Für die Analyse von Geodaten stellt Neo4j Spatial Operationen zur Verfügung. Diese
sind mit Hilfe des „Pipes“-Framework implementiert, welches ebenso wie Blueprints
Teil des Tinkerpop Processing Stacks für Graphdatenbanken ist. Die Besonderheit ist
hier, dass Operationen datenflussorientiert abgearbeitet und miteinander verknüpft
werden können, um Filter und Operationen auf die Ausgangswerte zu kombinieren.
Eine simple Suche nach dem nächsten Nachbarn zur Koordinate „point“ sieht dabei
folgendermaßen aus:
5 Navigationsanwendung mit Neo4j Spatial
45
Layer layer = db.getSpatialService().getLayer(layerName);
…
Coordinate point = new Coordinate(13.84, 51.03);
GeoPipeline pipeline = GeoPipeline
.startNearestNeighborLatLonSearch(layer, point, 0.5)
.sort("Distance");
…
List<Node> foundGeometries = pipeline.toNodeList();
Abbildung 26: Nearest Neighbor-Suche mit Hilfe einer GeoPipeline. Die Methode startNearestNeighborLatLonSearch() nimmt den zu durchsuchenden Layer, die Koordinate und einen
Grenzwert entgegen. Die Suche ist hier auf einen Umkreis von 500m begrenzt. Das Ergebnis
wird sortiert in eine Liste von Knoten übergeben.
Die Suche mit der „GeoPipeline“ beruht dabei auf dem R-Tree-Index, der durch den
SpatialService (s. Abbildung 26, Zeile 1) mit dem Layer übergeben wurde. Das besondere an einer Graphdatenbank ist, dass die Indexierung Teil des eigentlichen Graphen
sein kann, welcher zur Suche traversiert wird (s. Abbildung 27).
Abbildung 27: R-Tree-Index in Neo4j. Der importierte Datensatz bestand lediglich aus zwei
kurzen Wegen, deren umschließendes Rechteck hier indexiert ist.
5 Navigationsanwendung mit Neo4j Spatial
46
Ein OSM-Datensatz ist nicht auf einen Geometrietyp beschränkt. Um dies in der Suche
zu berücksichtigen, muss nach „befahrbaren“ Geometrien gefiltert werden. Aus Abbildung 27 lässt sich entnehmen, dass das Ergebnis einer Suche mit GeoPipeline auf die
RTREE_REFERENCE einer Geometrie zeigt. Dieser Knoten enthält das Attribut
„gtype“, dass Auskunft über den referenzierten Geometrietypen gibt. Die Konstante
Integer 2 entspricht dabei dem OpenGIS GeometryType GTYPE_LINESTRING, welcher potentiell eine Straße darstellen kann.
Um die Suche weiter zu verfeinern, wird ausgehend vom Referenzknoten über die
Kante „GEOM“ traversiert und dieser somit auf den OSM-Parameter „highway“ getestet. Für diese Anwendung wurde vereinfachend angenommen, dass folgende Attribute
eine befahrbare Straße beschreiben: motorway, trunk, primary, secondary, tertiary,
motorway_link, primary_link, road, residential und unclassified.
Um nun auf die Graphentheorie zurückgreifen zu können, muss das aus 6.2 gewonnene Wissen auf die Konfiguration der zur Traversierung des Graphen genutzten Klasse
angewandt werden. Hier ergab sich ein grundlegendes Problem bei der aktuellen Implementierung für OSM-Daten: Die NearestNeighbor-Suche erwidert den Referenzknoten der gesamten Geometrie und nicht den Stützpunkt des Pfades, der der gegebenen
Koordinate am nächsten ist. Deshalb muss im Sub-Graphen der Geometrie gesondert
nach dem gesuchten Stützpunkt gesucht werden. Dazu entstand das folgende CypherSkript, das eine Liste aller Knoten die auf die gerichtete Kante „NODE“ folgen erstellt.
Diese Knoten entsprechend dabei den Trägern der metrischen Information der Geometrie (vgl. Abbildung 28):
START a=node(" + /*ID Referenzknoten*/ + ")
MATCH a<-[:GEOM]-()-[:FIRST_NODE]->()-[:NEXT*0..]->()-[:NODE]->b
RETURN b
Abbildung 28: Sammeln aller Stützpunkte mit Cypher.
Die so entstandene Liste kann durch einfaches Vergleichen der Raumstrecke zum gesuchten Punkt auf den nächsten Stützpunkt untersucht werden.
5.4
Berechnung des kürzesten, befahrbaren Weges
Nachdem nun die Knoten der Geometrie gefunden wurden, welche am ehesten der
gesuchten Koordinate entsprechen, kann der kürzeste Weg zwischen diesen berechnet werden. Zum Einsatz kommt hier der Dijkstra-Algorithmus, der, neben anderen
Traversierungsalgorithmen für gerichtete und ungerichtete Graphen, durch die Neo4jBibliothek bereits integriert ist. Wie schon vorher festgestellt, besteht der Graph nicht
nur aus der Topologie der Geoobjekte, sondern enthält weitere Daten des Layers, wie
beispielsweise den R-Tree-Index selbst. Um also nur entlang der Knoten und Kanten
5 Navigationsanwendung mit Neo4j Spatial
47
zu traversieren, die für diese Aufgabe von Bedeutung sind, müssen bestimmte Kriterien erstellt werden. Dafür dient die Klasse des „Expander“:
Expander
expander
expander
expander
expander = Traversal.emptyExpander();
= expander.add(RelTypes.NODE);
= expander.add(RelTypes.NEXT);
= expander.addRelationshipFilter(relFilter);
Abbildung 29: Konfiguration des Expanders. Relationen des Typs „NODE“ und „NEXT“ werden
zum Expander hinzugefügt. Alle anderen Kanten, deren Label nicht den gegeben entspricht,
werden ignoriert. Der hinzugefügte „Relationship Filter“ ist gesondert definiert und testet auf
weitere Bedingungen. Hier speziell, ob es sich beim Wechsel von einem OSM-Weg auf den
angrenzenden um eine für PKW befahrbare Straße handelt.
Um den gesuchten Dijkstra-Pfad letztendlich zu berechnen, dient die Klasse des PathFinder, welche mit Hilfe des zuvor definierten Expanders und einer Vorschrift zur Interpretation des Kantengewichts instanziiert wird.
CostEvaluator<Double> costEvaluator =
CommonEvaluators.doubleCostEvaluator("length", 0);
PathFinder<WeightedPath> finder = GraphAlgoFactory.dijkstra(expander,
costEvaluator);
WeightedPath path = finder.findSinglePath(node1, node2);
Abbildung 30: Berechnung des kürzesten Wegs nach Dijkstra. Die Gewichtung des Graphs
basiert hier auf der Eigenschaft "length" und wird für eine Kante 0 gesetzt, wenn diese
Eigenschaft nicht vorhanden ist. Dies ist genau dann der Fall, wenn eine Kreuzung zweier
Wege über die Kanten des Typs „NODE“ traversiert wird (vgl. Abbildung 24).
5.5
Ergebnis
Abschließend wurde die Anwendung „NeoGIS“ konstruiert, um das Ergebnis zu visualisieren. Es besitzt die grundlegenden Fähigkeiten, OSM-Dateien zu importieren und auf
einer interaktiven Karte darzustellen. Die Darstellung der OSM-Daten beschränkt sich
auf Straßen, da nur diese für die Navigation in Frage kommen. Da auch das verwendete Framework GeoTools typenreine Layer zur korrekten Darstellung voraussetzt, kam
hier eine Funktion Neo4j Spatials zum Einsatz, mit dessen Hilfe sich eine dynamische
Layerkonfiguration anlegen lässt, welche GeoTools nur einen FeatureType pro Layer
offenbart. Dies ist die gleiche Herangehensweise durch die Neo4j als „DataStore“ für
andere GeoTools-Produkte fungieren kann.
5 Navigationsanwendung mit Neo4j Spatial
48
Abbildung 31: Die Programmoberfläche von NeoGIS mit einem importierten OSM-Layer des
Verkehrsnetz der Innenstadt Dresdens.
Abbildung 32: Ergebnis der Berechnung einer kürzesten Route. Die Auswahl des Start- und
Zielpunkts erfolgt per Mausklick auf die Karte. Die Wegberechnung kann manuell gestartet werden.
5.6
Fazit
Dieser Prototyp demonstriert die Eignung von Graphdatenbanken zur Analyse von Topologie. Durch die implizite Identifikation von Kanten und Knoten über deren Eigenschaften bietet das Property-Graph-Modell eine große Vielseitigkeit. Für die Berech-
5 Navigationsanwendung mit Neo4j Spatial
49
nung von gewichteten und ungewichteten Pfaden stehen neben Dijkstra weitere Algorithmen zur Verfügung, die sehr frei und beliebig komplex konfiguriert werden können.
Darüber hinaus können aus der Traversierung des Graphen weitere Fragestellungen
über Nachbarschaft und Erreichbarkeit beantwortet werden.
Da der Index Teil des Graphen selbst ist, kann dieser beliebig angepasst werden. Außerdem besteht so die Möglichkeit, den Zugriffsmechanismus auf die Abfrage zu perfektionieren. Beispielsweise wäre es denkbar, einen Sub-Graphen wie den einer Geometrie durch einen eigenen Zugriffsmechanismus zu ergänzen. Das in Kapitel 5.3 vorgestellte Problem der Stützpunktsuche ließe sich so eventuell effektiver lösen.
Bei der Konzeption fiel auf, dass speziell die Implementierung des OSM-Modells in
Neo4j ist zum gegenwärtigen Zeitpunkt nicht optimal ist, da das Gewicht der Kanten
zwischen Stützpunkten beim Import aus den Koordinaten berechnet wird. Ändern sich
die Koordinaten der Stützpunkte, kann dies zu Updateanomalien führen. Wünschenswert wäre außerdem eine topologische Dekodierung bekannter Schnittstellenformate,
so dass diese in einen Graph eingefügt werden können. Im Moment beschränken sich
die Möglichkeiten hier auf die Dekodierung von OSM-Daten. Der Import von Geometrien im WKT oder WKB-Format führt lediglich zu einem Knoten, der die Geometrie als
Array enthält. An dieser Stelle bietet sich spannendes Potential für die zukünftige Entwicklung.
Im direkten Vergleich mit den bestehenden Lösungen zur Geodatenhaltung muss ein
evolutionärer Vorteil für Systeme wie PostGIS oder Oracle Spatial bestätigt werden.
Neben dem größeren Feature Set an Operationen und einer wohlbekannten, standardisierten Abfragesprache steht für diese etablierten Systeme auch eine zentrale Dokumentation zur Verfügung, auf die bei der Arbeit zurückgegriffen werden kann. Das
modellieren von Topologie ist hier aber schwieriger. Das proprietäre Oracle Spatial
bietet hierfür umfangreiche Funktionen und integriert eigene Datentypen (Oracle 2006).
PostGIS wird ähnliche Funktionalität voraussichtlich mit dem Erscheinen in Version 2.0
beinhalten (PostGIS Tracker and Wiki o.J.). Durch diese Lösungen entsteht aber ein
Mehraufwand, der bei der Haltung von Geodaten in einer Graphdatenbank nicht
vorliegt.
6 Zusammenfassung und Ausblick
6
50
Zusammenfassung und Ausblick
Der Inhalt dieser Arbeit sollte es sein, den Entwicklungsstand der NoSQL-Datenbanken
aufzuzeigen und ihr Anwendungspotential für Geodaten zu werten. Dazu wurde zuerst
ein Überblick über die Geschichte, grundlegende Konzepte und die vier wichtigsten
Kategorien der NoSQL-Datenbanksysteme gegeben. Einzelne Vertreter dieser Kategorien wurden mit ihren Spatial Extensions und Anwendungen vorgestellt. Danach wurden zunächst Geodaten definiert, um deren Komplexität darzulegen und davon ausgehend die konventionelle Verarbeitung in SQL-Datenbanken mit ihren Vor- und Nachteilen grob zu umreißen. Anschließend wurde gezeigt, wie die Komplexität des Datenmodells in Wechselwirkung mit der Skalierbarkeit der Datenbank steht. Es ging hervor,
dass, da Geodaten sich als unterschiedlich komplex erwiesen haben, es viel wichtiger
ist, Datenbanken nach dem Zweck ihrer Anwendung zu wählen als ausschließlich auf
die Skalierbarkeit des Systems zu achten. Es wurde nämlich ersichtlich, dass das
Datenmodell einen erheblichen Einfluss auf die Eignung für die
Datenhaltungskomponente in einem raumbezogenen Informationssystem hat. Im weiteren Verlauf zeigte eine Unterteilung in einfache Positionsdaten, komplexe Geodaten
und Rasterdaten exemplarisch, wie diese Anwendungsfelder aussehen können und
wie ihre Struktur Einfluss auf die Wahl der Datenbank haben muss. Dabei fiel auf, dass
der Aufwand für das Einpflegen von White Column und Key/Value Stores für komplexe
Daten zu groß ist, als dass es Sinn macht, sie für kleine bis mittelgroße Projekte zu
benutzen. Document Stores hingegen, welche eine denormalisierte Dokumentenstruktur unterstützen, bieten eine interessante Alternative zu SQL-Datenbanken mit ihrer
Kombination aus Schemalosigkeit, 2D-Indexierung und MapReduce an. Auch Graphdatenbanken haben sich im Laufe der Arbeit als interessant erwiesen, da sie eine
ebenso komplexe Strukturierung der Daten wie SQL-Datenbanken erlauben, intuitive
Traversierungsalgorithmik anbieten und Topologie so direkt und intuitiv in einem Graph
modellieren können. Aufbauend auf diesen Erkenntnissen wurden zwei Prototypen
erstellt, die die theoretische Eignung dieser Datenbanken für Geodaten praktisch überprüfen sollten. Das Ergebnis unterstütze letztendlich die theoretische Vorüberlegung,
dass der Nutzen einer NoSQL-Datenbank auch schlicht die Vereinfachung bekannter
Vorgänge sein kann, die es auch Interessierten aus GIS-fremden Fachgebieten erlaubt, einen Geodienst nicht nur zu konsumieren, sondern selbst zu pflegen. Die Berechnung des kürzesten zwischen zwei Wegpunkten bestehenden Pfads anhand eines
intuitiv erfassbaren Graphen zeigte, dass es natürlichere Wege gibt, topologische
Sachverhalte schon im Datenbankschema abzubilden.
Allgemein kann gesagt werden, dass die Haltung von Geodaten in allen Datenbanktypen möglich ist. Durch die hohe Komplexität, die Geodaten im Allgemeinen jedoch
aufweisen, ist genau abzuwägen, welche Datenbank zum Einsatz kommen soll. Aufgrund des überlegenen Entwicklungsstands der objektrelationalen Geodatenbanken,
6 Zusammenfassung und Ausblick
51
wie PostGIS oder Oracle Spatial, sind diese jedoch bei komplexen Projekten vorzuziehen.
Zu beachten ist, dass es sich bei dieser Arbeit lediglich um eine momentane Einschätzung der NoSQL-Systeme und ihrer Eignung für Geodaten handelt. Die Bewegung ist
vergleichsweise jung und gerade die hier vorgestellten Lösungen für Geodaten entwickeln sich erst seit kurzem. Trotzdem haben NoSQL- Systeme innerhalb ihrer kurzen
Bestehenszeit bereits so viel Raum in Gebieten der Datenanalyse, der verteilten Web
Services und der Biotechnologie gut gemacht, dass sich auch in Zukunft die Frage
stellen wird, ob die Geoinformation von den neuen Entwicklungen profitieren kann.
Literaturverzeichnis
VI
Literaturverzeichnis
Monographien, Zeitschriftenaufsätze
ANDRAE, C. (2009): Spatial Schema. Heidelberg.
BILL, R. (1999): Grundlagen der Geoinformationssysteme. Heidelberg.
DE SOUZA BAPTISTA, C. ET AL.
(2011): Using OGC Services to Interoperate Spatial Data
Stored in SQL and NoSQL Databases. Proceedings XII GEOINFO: 61-72.
EDLICH, S. ET AL. (2011): NoSQL. München.
GILBERT, S., UND N. LYNCH. (2002): Brewer's Conjecture and the Feasibility of
Consistent, Available, Partition-Tolerant Web Services. ACM SIGACT News 33
(2): 51-59.
KEMPER, A., UND A. EICKLER (2011): Datenbanksysteme. München.
KOCH, T. (2008): Verwaltung von Geodaten in Oracle. Saarbrücken.
SCHELIGA, M. (2010): CouchDB. kurz & gut. Köln.
SCHNEIDER, R. (1993): Geo-Datenbanksysteme. Mannheim.
STONEBRAKER, M. ET AL. (2007): The End of an Architectural Era (It’s Time for a
Complete Rewrite). Proceedings of the 33rd International Conference on Very
Large Data Bases: 1150-1160.
TIWARI, S. (2011): Professional NoSQL. Indianapolis.
VOGELS, W. (2009): Eventually Consistent. Communications of the ACM 52 (1): 40-44.
Internetquellen
10gen (2011): Geospatial Indexing - MongoDB. Internet:
http://www.mongodb.org/display/DOCS/Geospatial+Indexing (15.02.2012)
Amazon (2012): Amazon Elastic Compute Cloud (Amazon EC2) . Internet:
http://aws.amazon.com/de/ec2/ (20.2.2012)
BELLON, A. (2012): Die 20 bestverdienenden Internetseiten der Welt.
Internet: http://www.alexbellon.de/die-20-bestverdienenden-internetseiten-derwelt/ (22.02.2012)
BREWER, E. A. (2000): Towards Robust Distributed Systems. Internet:
http://www.eecs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf
(20.02.2012)
BUTLER, H. ET AL. (2008): The GeoJSON Format Specification. Internet:
http://geojson.org/geojson-spec.html (14.02.2012)
Cassandra Wiki (2012a): ClientOptions. Internet:
http://wiki.apache.org/cassandra/ClientOptions (14.02.2012)
Cassandra Wiki (2012b): DataModel. Internet:
http://wiki.apache.org/cassandra/DataModel (14.02.2012)
Cassandra Wiki (2012c): Datamodel. Internet:
http://wiki.apache.org/cassandra/FrontPage (14.02.2012)
Literaturverzeichnis
VII
CHANG, F. ET AL. (2006): Bigtable: A Distributed Storage System for Structurated Data.
Internet:
http://static.googleusercontent.com/external_content/untrusted_dlcp/research.g
oogle.com/de//archive/bigtable-osdi06.pdf (21.02.2012)
CHODROW, K. (2011): Mongo in Flatland. Internet:
http://www.snailinaturtleneck.com/blog/2011/06/08/mongo-in-flatland/
(05.02.2012)
CouchDB (o.J.): CouchDB/GeoCouch. Internet:
http://www.gdal.org/ogr/drv_couchdb.html (09.01.2012)
DataStax. (2012): Cassandra Users. Internet: http://www.datastax.com/cassandrausers
(08.01.2012)
DEAN, J. UND S. GHEMAWAT (2004): MapReduce: Simplified Data Processing on Large
Clusters. Internet:
http://static.googleusercontent.com/external_content/untrusted_dlcp/research.g
oogle.com/en//archive/mapreduce-osdi04.pdf (10.01.2012)
EDLICH, S. (2012): Your Ultimate Guide to the Non-Relational Universe! Internet:
http://nosql-database.org/ (30.01.2012)
EIFREM, E. (2009): NOSQL: scaling to size and scaling to complexity. Internet:
http://blogs.neotechnology.com/emil/2009/11/nosql-scaling-to-size-and-scalingto-complexity.html (18.02.2012)
EVAN, E. (2009): NOSQL 2009. Internet: http://blog.symlink.com/2009/05/12/nosql_2009.html (08.01.2012)
FIELDING, R. T. (2000): Representational State Transfer (REST). Internet:
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
(05.02.2012)
FIELDING, R. T. ET AL. (1999): Hypertext Transfer Protocol -- HTTP/1.1. Internet:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html (02.02.2012)
FINLEY, K. (2011): Video: How SimpleGeo Built a Scalable Geospatial Database with
Apache Cassandra. Internet:
http://www.readwriteweb.com/cloud/2011/02/video-simplegeo-cassandra.php
(05.02.2012)
GARULLI, L. (2011): OrientDB. Internet: http://www.orientechnologies.com/orient-db.htm
(14.02.2012)
Geofabrik GmbH (2012): Geofabrik Download-Bereich. Internet:
http://download.geofabrik.de/osm (21.02.2012)
GDAL (2012): OGR Vector Formats. Internet:
http://www.gdal.org/ogr/drv_couchdb.html (21.02.2012)
GONÇALVES, B. L. (2012): FrontPage. Internet: http://wiki.apache.org/cassandra/
(07.01.2012)
Google (2012): Google Earth Builder. Internet:
http://www.google.com/enterprise/earthmaps/builder.html (19.02.2012)
GREHAN, R. UND D. BARRY (2012): Introduction to ODBMS. Short History. Internet:
http://www.odbms.org/Introduction/history.aspx (06.01.2012)
HEINE, C. (2011): Foursquare Reaches 15M Users, Triples Audience on a Year.
Internet: http://www.clickz.com/clickz/news/2130251/foursquare-reaches-15musers-triples-audience (22.02.2012)
Literaturverzeichnis
VIII
HITCHCOCK, A. (2005): Google's BigTable. Internet:
http://andrewhitchcock.org/?post=214 (05.01.2012)
KATZ, D. UND V. MISCHE (2012): geocouch. Internet:
https://github.com/couchbase/geocouch (10.02.2012)
LUKAS, B. (2012): Geoinformationen – Download von Daten. Internet:
http://www.mugv.brandenburg.de/cms/detail.php/bb2.c.515599.de (21.02.2012)
MALONE, M. (2010): Working with Dimensional Data in a Distributed Hash Table.
Internet: http://strangeloop2010.com/talks/14495 (06.01.2012)
Neo Technology (2012a): Chapter 15. Cypher Query Language. Internet:
http://docs.neo4j.org/chunked/1.6.1/cypher-query-lang.html (28.01.2012)
Neo Technology (2012b): neo4j/spatial. Internet: https://github.com/neo4j/spatial
(18.02.2012)
NEUMANN, A. (2008): PostGIS-Einführung. Internet:
http://gis.hsr.ch/wiki/images/f/fd/Postgis_einfuehrung_2008.pdf (10.02.2012)
OGDEN, M. (2011): geocouch-utils. Internet: https://github.com/maxogden/geocouchutils (15.01.2012)
Open Geospatial Consortium (2011): OpenGIS® Implementation Standard for Geographic information - Simple feature access - Part 1: Common architecture. Internet:
https://portal.opengeospatial.org/modules/admin/license_agreement.php?suppr
essHeaders=0&access_license_id=3&target=http://portal.opengeospatial.org/files/%3fa
rtifact_id=25355 (21.02.2012)
Open Geospatial Consortium (2012a): The OGC Forms REST and WFS/FE Standards
Working Groups. Internet:
http://www.opengeospatial.org/pressroom/pressreleases/1497 (04.01.2012)
Open Geospatial Consortium (2012b): OGC History (detailed). Internet:
http://www.opengeospatial.org/ogc/historylong (01.02.2012)
OpenStreetMap Wiki (2011): OSM XML. Internet:
http://wiki.openstreetmap.org/wiki/OSM_XML (08.02.2012)
Oracle (2006): Topology Data Model Overview. Internet:
http://docs.oracle.com/cd/B19306_01/appdev.102/b14256/sdo_topo_concepts.
htm#CIHFGFIA (20.02.2012)
PostGIS Tracker and Wiki (o.J.): PostGIS Topology. Internet:
http://trac.osgeo.org/postgis/wiki/UsersWikiPostgisTopology (20.02.2012)
RDF Working Group (2012): Ressource Description Framework (RDF). Internet:
http://www.w3.org/RDF/ (16.02.2012)
RODRIGUEZ, M. (2012a): Defining a Property Graph. Internet:
https://github.com/tinkerpop/gremlin/wiki/Defining-a-Property-Graph
(20.02.2012)
RODRIGUEZ, M. (2012b): Blueprints. Internet:
https://github.com/tinkerpop/blueprints/wiki (20.02.2012)
SANFILIPPO, S. (2011): Short term Redis plans. Internet: http://antirez.com/post/shortterm-redis-plans.html (10.01.2012)
SLEE, M., AGARWAL, A., UND M. KWIATKOWSKI (2007): Thrift: Scalable Cross-Language
Services Implementation. Internet: http://www.scribd.com/doc/20232450/ThriftScalable-Cross-Language-Services-Implementation (21.02.2012)
Literaturverzeichnis
IX
STONEBRAKER, M. (2009): The End of a DBMS Era (Might be Upon Us). Internet:
http://cacm.acm.org/blogs/blog-cacm/32212-the-end-of-a-dbms-era-might-beupon-us/fulltext (10.01.2012)
STROZZI, C. (2010): NoSQL. A Relational Database Management System. Internet:
http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/nosql/Home%20Page
(21.02.2012)
The Apache Software Foundation (2011): Hadoop HDFS. Internet:
http://hadoop.apache.org/hdfs/ (15.01.2012)
The Apache Software Foundation (2012): Apache HBase. Internet:
http://hbase.apache.org/ (31.01.2012)
TROY, D. (2008): geoshash demonstrator. Internet:
http://openlocation.org/geohash/geohash-js/ (02.02.2012)
VMWare (2011a): Clients. Internet: http://redis.io/clients (20.02.2012)
VMWare (2011b): Commands. Internet: http://redis.io/commands (20.02.2012)
VMWare (2011c): Replication. Internet: http://redis.io/topics/replication (20.01.2012)
VMWare (2011d): Transactions. Internet: http://redis.io/topics/transactions (05.01.2012)
VMWare (2011e): Virtual Memory. Internet: http://redis.io/topics/virtual-memory
(02.01.2012)
VOGELS, W. ET AL. (2007): Dynamo: Amazon's Highly Available Key-value Store. Internet: http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html
(10.01.2012)
VOGELS, W. (2012): Amazon DynamoDB – a Fast and Scalable NoSQL Database
Service Designed for Internet Scale Applications. Internet:
http://www.allthingsdistributed.com/2012/01/amazon-dynamodb.html
(20.01.2012)
WILSON, J. R. (2008): Understanding HBase and BigTable. Internet:
http://jimbojw.com/wiki/index.php?title=Understanding_Hbase_and_BigTable
(23.01.2012)
Abbildungsverzeichnis
X
Abbildungsverzeichnis
Abbildung 1: Datenfluss des MapReduce-Verfahrens. ................................................. 7
Abbildung 2: Hashfunktion.. ......................................................................................... 9
Abbildung 3: Konzeptuelles Schema eines Wide Column Stores nach BigTable
White Paper. .................................................................................................... 11
Abbildung 4: Konzeptuelles Schema eines Wide Column Stores in JavaScriptnaher Notation. ................................................................................................ 11
Abbildung 5: Consistant Hashing-Ring ...................................................................... 12
Abbildung 6: Beispiel eines einfachen JSON-Dokuments. ......................................... 14
Abbildung 7: Beispiel eines GeoJSON GeometryObjects des Typs
MultiLineString. ................................................................................................ 16
Abbildung 8: Einfacher Graph bestehend aus drei Knoten und ungerichteten
Kanten. ............................................................................................................ 17
Abbildung 9: Gewichteter Property Graph zwischen Personen und Programmen ...... 18
Abbildung 10: Hinzufügen eines Knotens und einer Kante mit Gremlin. .................... 19
Abbildung 11: Komplexitt vs. Skalierbarkeit ............................................................... 23
Abbildung 12: Visualisierung der "Geohash Quadranten" .......................................... 26
Abbildung 13: JSON-Dokument eines Features des Typs Point. ............................... 34
Abbildung 14: Eine einfache Map-Funktion................................................................ 34
Abbildung 15: „Geometrie“ emittierende Map-Funktion.. ............................................ 35
Abbildung 16: Design-Dokument. .............................................................................. 35
Abbildung 17: Antwortdokument eines Bounding Box Querys. .................................. 36
Abbildung 18: List-Funktion. ...................................................................................... 37
bbildung 19: AJAX-Request an eine CouchDB. ......................................................... 38
Abbildung 20: Screenshot der Konzeptanwendung "Brandenburger
Schutzgebiete". ................................................................................................ 39
Abbildung 21: Abfrage des kürzesten Pfads .............................................................. 41
Abbildung 22: Gekürztes Beispiel einer OSM-XML-Datei. ......................................... 42
Abbildung 23: Import einer OSM-Datei in eine eingebettete Graphdatenbank. .......... 43
Abbildung 24: Visualisierung in Neoclipse. ................................................................ 43
Abbildung 25: Cypher MATCH-Statement. ................................................................ 44
Abbildung 26: Nearest Neighbor-Suche mit Hilfe einer GeoPipeline. ......................... 45
Abbildung 27: R-Tree-Index in Neo4j. ........................................................................ 45
Abbildung 28: Sammeln aller Stützpunkte mit Cypher. .............................................. 46
Abbildung 29: Konfiguration des Expanders. ............................................................. 47
Abbildung 30: Berechnung des kürzesten Wegs nach Dijkstra. ................................. 47
Abbildung 31: Die Programmoberfläche von NeoGIS ................................................ 48
Abbildung 32: Ergebnis der Berechnung einer kürzesten Route. ............................... 48
Tabellenverzeichnis
Tabelle 1: Eigenschaften von NoSQL-Datenbanken in Relation zu
Charakteristiken von Nichtstandardanwendungen. .......................................... 29
Anlagenverzeichnis
XI
Anlagenverzeichnis
Anhang 1
Anhang 2
CD-Inhalt
Bachelorarbeit Benjamin Thurm – Einsatz von NoSQL-Datenbanken für Geodaten.doc
BrandenburgerSchutzgebiete\
._index.html
._script
.DS_Store
script\
style\
index.html
NeoGIS\
NeoGIS Runnable\
NeoGIS Source\
Hinweis.txt
Webseiten\
10gen (2011) Geospatial Indexing - MongoDB.htm
Amazon (2012) Amazon Elastic Compute Cloud (Amazon EC2).htm
Bellon, A. (2012) Die 20 bestverdienenden Internetseiten der Welt.htm
Brewer, E. A. (2000) Towards Robust Distributed Systems.pdf
Butler, H. et al. (2008) The GeoJSON Format Specification.htm
Cassandra Wiki (2012a) ClientOptions.htm
Cassandra Wiki (2012b) Datamodel.htm
Chang, F. et al. (2006) Bigtable - A Distributed Storage System for Structurated Data.pdf
Chodrow, K. (2011) Mongo in Flatland.htm
CouchDB (o.J.) CouchDB GeoCouch.htm
DataStax (o.J.) Cassandra Users.htm
Dean, J. und S. Ghemawat (2004) MapReduce - Simplified Data Processing on
Large Clusters.pdf
Edlich, S. (2012) Your Ultimate Guide to the Non-Relational Universe!.htm
Eifrem, E. (2009) NOSQL - scaling to size and scaling to complexity.htm
Evan, E. (2009) NOSQL 2009.htm
Fielding, R. T. (2000) Representational State Transfer (REST).htm
Fielding, R. T. et al. (1999) Hypertext Transfer Protocol -- HTTP 1.1.htm
Finley, K. (2011) Video - How SimpleGeo Built a Scalable Geospatial Database
with Apache Cassandra.htm
Garulli, L. (2011) OrientDB.htm
Geofabrik GmbH (2012) Geofabrik Download-Bereich.htm
Gonçalves, B. L. (2012) FrontPage.htm
Google (2012) Google Earth Builder.htm
Grehan, R. und D. Barry (2012) Introduction to ODBMS.htm
Heine, C. (2011) Foursquare Reaches 15M Users, Triples Audience on a Year.htm
Hitchcock, A. (2005) Google's BigTable.htm
Katz, D. und V. Mische (2012) geocouch.htm
Lukas, B. (2012) Geoinformationen - Download von Daten.htm
Malone, M. (2010) Working with Dimensional Data in a Distributed Hash Table Internet.htm
Anlagenverzeichnis
XII
Neo Technology (2012a) Chapter 15. Cypher Query Language.htm
Neo Technology (2012b) neo4j spatial.htm
Neumann, A. (2008) PostGIS-Einführung.pdf
Ogden, M. (2011) geocouch-utils.htm
Open Geospatial Consortium (2011) OpenGIS® Implementation Standard for Geographic information - Simple feature access - Part 1 Common architecture..pdf
Open Geospatial Consortium (2012a) The OGC Forms REST and WFS FE Standards Working Groups.htm
Open Geospatial Consortium (2012b) OGC History (detailed).htm
OpenStreetMap Wiki (2011) OSM XML.htm
Oracle (2006) Topology Data Model Overview.htm
PostGIS Tracker and Wiki (o.J.) PostGIS Topology.htm
RDF Working Group (2012) Resource Description Framework (RDF).htm
Rodriguez, M. (2012a) Defining a Property Graph.htm
Rodriguez, M. (2012b) Blueprints.htm
Sanfilippo, S. (2011) Short term Redis plans.htm
Slee, M., Agarwal, A. und M. Kwiatkowski (2007) Thrift Scalable Cross-Language
Services Implementation.htm
Stonebraker, M. (2009) The End of a DBMS Era (Might be Upon Us).htm
Strozzi, C. (2010) NoSQL Relational Database Management System.htm
The Apache Software Foundation (2011) Hadoop HDFS.htm
The Apache Software Foundation (2012) Apache HBase.htm
Troy, D. (2008) geoshash demonstrator..htm
VMWare (2011a) Clients.htm
VMWare (2011b) Commands.htm
VMWare (2011c) Replication.htm
VMWare (2011d) Transactions.htm
VMWare (2011e) Virtual Memory.htm
Vogels, W. (2012) Amazon DynamoDB – a Fast and Scalable NoSQL Database
Service Designed for Internet Scale Applications.htm
Vogels, W. et al. (2007) Dynamo - Amazon's Highly Available Key-value Store.htm
Wilson, J. R. (2008) Understanding HBase and BigTable.htm
Anhang 1
XIII
Anhang 1
Von: Volker Mische
Betreff:
Re: Geocouch Spatial Queries
Datum:
11. Januar 2012 12:36:20 MEZ
An:
Benjamin Thurm
>Ich kann aber nicht
>rausfinden, ob komplexere Abfragen nach Nearest-Neighbor, Polygon
>berührt-Polygon etc. nativ unterstützt werden? Sollen dergleichen
>Abfragen auch über die Views integriert werden?
Momentan gibt es nut bounding box abfragen. Polygon suche (bzw. ist es
mit jeder Geometry möglich, also auch mit Linien) funktioniert schon,
ist momentan aber im Code Review der Firma steckengeblieben. Wird aber
bald verfügbar sein.
An Nearest-Neighbour-Suche (knn) arbeitet momentan Tobias Sauerwein, ein
Master Student der Universität Marburg.
Die Abfragen werden einfach wie die Bounding-Box-Abfrage funktionieren.
Ich versuche dabei die OpenSearch Geo Spezifikation [1] zu implementieren.
[1]http://www.opensearch.org/Specifications/ _
OpenSearch/Extensions/Geo/1.0/Draft_2
___
Von: Volker Mische
Betreff:
Re: Geocouch Spatial Queries
Datum:
11. Januar 2012 14:13:40 MEZ
An:
Benjamin Thurm
>Meinst du damit die Suche nach eingeschlossenen Features in einem Polygon
>etc.? Aggregationen wie das umschließende Feature mehrerer Geometrien
>ließe sich ja eventuell jetzt schon über entsprechendes Map/Reduce
>durchführen?
Alle Features die ein Polygon schneiden oder darin liegen.
Der Spatial-Index von GeoCouch hat nichts mit dem MapReduce-Index
(Views) zu tun. Er ist komplett unabhänig davon. Man kann sich das so
vorstellen. Die Daten sind in CouchDB gespeichert. Nun kann man einen
Index darauf aufbauen. Dabei gibt es die Wahl zwischen einem auf
MapReduce basierendem und einem räumlichen Index.
An Nearest-Neighbour-Suche (knn) arbeitet momentan Tobias Sauerwein, ein
Master Student der Universität Marburg.
>Hast du Informationen wann knn implementiert sein könnte?
Ein Prototyp funktioniert schon [1].
Die Abfragen werden einfach wie die Bounding-Box-Abfrage funktionieren.
Ich versuche dabei die OpenSearch Geo Spezifikation [1] zu implementieren.
>Wie schaut es dann aus mit der Ausgabe in anderen Formaten als JSON?
>"?format" wird dann als standardisierter View für WKT etc. implementiert?
>Gibt es darüber hinaus Standards die bei der Umsetzung eine Rolle gespielt
>haben? (Soweit man das so für eine schemafreie Datenbank sagen kann.)
Momentan kann man verschiedene Formate per _list Funktion ausgeben (es
gibt ein Beispiel in der README von GeoCouch). Daher plane ich nicht
dass direkt in GeoCouch zu implementieren. Das ist eher was für kleine
Helfer für GeoCouch wie geocouch-utils [2].
[1] https://github.com/tsauerwein/geocouch/tree/knn_prototyp_1.1.x
[2] https://github.com/vmx/geocouch-utils/
Anhang 2
XIV
Anhang 2
Von: Stefan Edlich
Betreff:
Re: Kategorisierung von NoSQL/Spatial Lösungen
Datum:
11. Januar 2012 12:38:50 MEZ
An: Benjamin Thurm
Sehr geehrter Herr Thurm,
vielen Dank für Ihre Email.
>Die Kategorisierung der NoSQL Datenbanken in die vier Hauptgruppen
>(Key/Value, Document Stores,...) hat sich in ziemlich allen
>Artikeln zum Thema durchgesetzt. Mir ist klar, dass sie auf der
>logischen Struktur der Datenverwaltung beruht und deshalb nicht
>weit hergeholt ist. Interessieren würde mich dennoch, ob sie für
>ihre NoSQL-Liste schon auf diese bestehende Einordnung
>zurückgegriffen haben oder ob sie sich bei der Recherche für sie
>ergeben hat?
Die erste Einordnung habe ich selbst auf der webseite http://nosqldatabase.org vorgenommen. Das war 2009.
Und dafür hatte ich mit allen NoSQL Gurus diskutiert. Ursprünglich
wollte ich witzigerweise sogar Graph-Datenbanken nicht mit
aufnehmen. Hatte hier aber z.B. heftige Diskussionen mit Emil Efrem
und vielen anderen. Auch daher kam die Aufteilung auf der Webseite
in Core-NoSQL und Soft-NoSQL.
>Sehen sie in der Hinsicht auf Geodaten eine Zukunft für NoSQL?
Eine sehr große.
>GeoCouch wurde zB. gerade als Schnittstelle für das GDAL Tool der
>OGC aufgenommen, MongoDB bietet eine zweidimensionale Indexierung,
>Neo4j mittlerweile auch eine eigene Spatial Extension. Key/Value
>Stores und Wide Column Stores scheinen mir in dieser Entwicklung im
>Open Source Bereich unterpräsentiert. (Sicherlich auch wegen der
>schwierigen Datenhaltung für nicht-Standard Daten.)
>Sind ihnen andere Projekte bekannt?
Nicht wirklich. Die Geo Features von Couch und Mongo kenne ich
natürlich.
Aus diesem Grunde haben ich mit Kollegin Frau Prof. Sauer eine
Abschlussarbeit am laufen, die diese
Features untersucht und vergleicht. Wenn sie mich in 4 Monaten
nochmal erinnern, kann ich ihnen das PDF dazu senden.
Viele Grüße
Stefan Edlich
Erklärung über die eigenständige Erstellung der Arbeit
XV
Erklärung über die eigenständige Erstellung der Arbeit
Hiermit erkläre ich, dass ich die vorgelegte mit dem Titel
__Einsatz von NoSQL-Datenbanksystemen für Geodaten____
selbständig verfasst, keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie alle wörtlich oder sinngemäß übernommenen Stellen in der Arbeit als solche und durch Angabe der Quelle gekennzeichnet habe. Dies gilt auch für Zeichnungen, Skizzen, bildliche Darstellungen sowie für Quellen aus dem Internet.
Mir ist bewusst, dass die Hochschule für Technik und Wirtschaft Dresden Prüfungsarbeiten stichprobenartig mittels der Verwendung von Software zur Erkennung von Plagiaten überprüft.
___Dresden, den 23.02.2012____
Ort, Datum
____________________________
Unterschrift Student