Einsatz von NoSQL-Datenbanksystemen für Geodatengeoinformatik.htw-dresden.de/abschlussarbeiten/BA... · 1 Einführung in die Welt der NoSQL-Datenbanken 2 ... finden sich heute beispielsweise

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 Key/Value Stores ................................................................................................ 8

2.2.1 Datenhaltung ...................................................................................................... 9

2.2.2 Redis .................................................................................................................. 9

2.2.3 Spatial Extension .............................................................................................. 10

2.3 Wide Column Stores ........................................................................................ 10

2.3.1 Datenhaltung .................................................................................................... 11

2.3.2 Apache Cassandra ........................................................................................... 12

2.3.3 Spatial Extensions ............................................................................................ 13

2.4 Document Stores .............................................................................................. 13

2.4.1 Datenhaltung .................................................................................................... 14

2.4.2 CouchDB .......................................................................................................... 14


2.5 Graphdatenbanken ........................................................................................... 16

2.5.1 Datenhaltung .................................................................................................... 17

2.5.2 Neo4j ................................................................................................................ 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 bes-

ten 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 Fa-

cebook, seinen Nutzern, ihre Position anderen mitzuteilen. Anwendungen wie „Fours-

quare“ 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 Zu-

sammenhang 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 FOSS-

NoSQL-Datenbanksystemen darzustellen und deren Anwendungsmöglichkeiten für

Geodaten zu untersuchen. Dazu soll im ersten Kapitel eine zweckmäßige Zusammen-

fassung der Historie der NoSQL-Bewegung gegeben werden. Nach einer Erläuterung

des Begriffs „NoSQL“ werden dann grundlegende Konzepte nichtrelationaler Daten-

banken 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 Ka-

tegorisierung soll darin vorgestellt und jeweils ein Vertreter dieser Kategorien näher

betrachtet werden. Insbesondere soll hier auf die für Geodaten interessante Eigen-

schaften und Standards eingegangen werden, um davon ausgehend eine Einschät-

zung zum aktuellen Entwicklungsstand zu treffen. Eventuell verfügbare Spatial Exten-

sions werden in die Betrachtungen entsprechend mit einbezogen und in ihrem Funkti-

onsumfang beleuchtet. Daran anschließend soll eine Diskussion des Anwendungspo-

tentials 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 NoSQL-

Datenbanken 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 tref-

fen zu können.

1 Einführung in die Welt der NoSQL-Datenbanken 2

1 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 wich-

tigsten Konzepte zu verschaffen. Im folgenden Kapitel soll dazu zunächst ein histori-

scher Abriss zur Entstehung der NoSQL-Bewegung gegeben werden. Anschließend

folgt eine kurze Auseinandersetzung mit Konzepten, die für viele der NoSQL-

Datenbanken 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 Daten-

modell anspielt (Strozzi 2010).

Erste wirklich als NoSQL-Datenbanken zu bezeichnende Systeme entstanden mit Ein-

zug der Web 2.0 Welle und der damit verbundenen Datenflut. Um den exponentiellen

Wachstumsraten digitaler Informationen Herr zu werden, begann der Suchmaschinen-

riese Google 2004 mit der Arbeit an „BigTable“ (Hitchcock 2005), einer nichtrelationa-

len Datenbank, optimiert zur verteilten Haltung exzessiver Datenmengen im Petabyte-

Bereich. BigTable nutzt eine Kombination aus Reihen/Zellen-Schlüsseln und Zeitstem-

peln, 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 ver-

teiltes System aus kostengünstigen Standardservern („commodity server“), die zu leis-

tungsfähigen und fehlertoleranten Clustern zusammengeschlossen werden können.

Damit war es nun auch möglich, dynamisch auf wachsende Datenmengen und stei-

gende Nutzerzahlen einzugehen und die Kapazitäten entsprechend anzupassen. (Ed-

lich 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-


funden. Aufgrund der Tatsache, dass der Versandkonzern Amazon zur Weihnachtszeit

ein stark erhöhtes Nutzeraufkommen zu verzeichnen hatte, die technologischen Gren-

zen der eingesetzten Datenbanksysteme nach eigenen Aussagen 2004 aber ausge-

reizt waren, kam es zu Einbrüchen in der Verfügbarkeit der Dienste. Daraufhin setzte

Amazon mit der Entwicklung von Dynamo ebenfalls auf ein skalierendes, nichtrelatio-

nales System aus der Eigenentwicklung (Vogels 2012).

Obwohl von Google so nicht propagiert, steht das proprietäre BigTable heute als Be-

griffspate 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 Datenbanken-

geworden 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 Datenbankab-

fragesprache 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 zu-

letzt an der englischen Sprache, orientieren. Die „Cassandra Query Language“ (CQL)

ist einer dieser Vertreter. „SQL“ wird vielmehr als Synonym für (objekt-)relationale Da-

tenbanksysteme 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 entworfe-

nen 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 Ska-

lierbarkeit 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.


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 entspre-

chend leistungsstarke Hardware ist teuer. Trotzdem ist dies für die meisten Anwen-

dungen ein ausreichendes Mittel (Edlich 2011: 377).

Eine Alternative zu einer Vertikalen Skalierung stellt die sogenannte „Horizontale Ska-

lierung“ 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 dynami-

sche Einflussnahme auf die Leistung des Systems durch Hinzufügen weiterer Rechner.

Den aktuellen Gipfel der Horizontalen Skalierung stellt das sogenannte „Cloud Compu-

ting“ dar (ebd.). Der Versanddienstleister Amazon etwa bietet auf Grundlage seiner

eigenen Datencenter die „Amazon Web Services“ an und erlaubt so eine Nutzung sei-

ner Rechenkapazitäten. Der gewillte Kunde kann Rechenzeit kaufen und eigene virtu-

elle Server betreiben, deren Rechenleistung vom Cluster bereitgestellt wird.

(Amazon.com 2012)

Im Zusammenhang mit der Horizontalen Skalierung spielt das in Brewers CAP-

Theorem 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 Ent-

wicklungen, 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 Syste-

me, die einer viel größeren Zugriffslast unterliegen und dabei Hochverfügbarkeit bieten

sollen. Eric A. Brewer stellte in diesem Zusammenhang eine gemeinhin als „CAP-


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 garantie-

ren. 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 Datenzugriffs-

bedarfs durch steigende Nutzerzahlen das ursprünglich verwendete sogenannte „A-

CID-Paradigma“ nicht mehr uneingeschränkt anwendbar ist. Unter dem Begriff „ACID“

sind die vier Eigenschaften Atomicity, Consistency, Isolation und Durability zusam-

mengefasst, welche durch Transaktionierung in RDBMS durchgesetzt werden (Kemper

2011: 289).

Viele NoSQL-Datenbanken setzen daher auf ein alternatives Modell, welches gemein-

hin als „BASE“ bezeichnet wird und auf Transaktionierung verzichtet. BASE ist ein Ak-

ronym für:

Basically Available

Soft-State

Eventually Consistent

Der Grundgedanke beruht darauf, Hochverfügbarkeit für gelockerte Konsistenzbedin-

gungen einzutauschen. Bei „Eventual Consistency“ handelt sich also um einen optimis-

tischen Ansatz, bei dem darauf verzichtet wird, alle im Cluster beteiligten Knoten durch

Transaktionierung vor Inkonsistenzen zu sichern. Konsistenz der Daten wird so zu ei-

nem 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


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 Syste-

men und neuen Datenmodellen mussten auch neue Algorithmen erdacht werden, wel-

che diese Anforderungen unterstützen. Einer der bekanntesten Algorithmen dieser Art

ist MapReduce, welcher durch die Google-Ingenieure Jeffrey Dean und Sanjay Ghe-

mawat 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 Programmie-

rung abgeleiteten Methoden map() und reduce(), welche Abbildungsvorschriften dar-

stellen, 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 vo-

raus, dass sie rekursiv definiert ist, was sie so ebenfalls parallel ausführbar macht

(Edlich 2011: 13).


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 Berech-

nungen, 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 defi-

niert sein muss. Während vor dem Anlegen eines Datenbankmodells für SQL-

Datenbanksystems 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 Da-

tenhaltung ändern oder Informationen mit aufgenommen werden sollen, die beim Anle-

gen der Tabellen so nicht vorgesehen waren.

2 Allgemeiner Überblick 8

2 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 beste-

hende Systeme, wie beispielsweis Lotus Notes oder Oracle Berkeley DB, als nichtrela-

tionale 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) un-

terschiedlicher 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 Eigen-

schaften 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 Datenmo-

dellen 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 Dy-

namo Whitepapers 2007 vervielfacht. Sie sind prädestiniert für Daten, die keine Relati-

on zueinander aufweisen, da es sich um ein sehr einfaches Datenmodell handelt

(Edlich 2011: 151).

http://nosql-database.org/


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üs-

sel („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 star-

tete 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-BSD-

Lizenz 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 Daten-

bank eingespielt werden (AOF Modus). Es ist ebenfalls möglich RDB und AOF-Modi

zweckmäßig zu kombinieren oder komplett auf die nachhaltige Speicherung zu verzich-

ten. Daten, die bei einem Ausfall ausschließlich im flüchtigen Arbeitsspeicher vorhan-

den 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 Rei-

henabarbeitung 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


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 re-

pliziert werden. Dies kann dazu dienen, die Leseleistung zu erhöhen oder Daten re-

dundant vorzuhalten (ebd.). Zu beachten ist, dass zum gegenwärtigen Zeitpunkt (Ver-

sion 2.4.7) kein Sharding mit Bordmitteln möglich ist. Der dazu notwendige Redis Clus-

ter steht bisher nur als Developer Preview zur Verfügung und wird mit Version 2.6. er-

wartet (Sanfilippo 2011). Das bedeutet, dass der gesamte Datenbestand in den Ar-

beitsspeicher 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 beispiels-

weise UNION und DIFF bei Sets, oder links- oder rechtsseitige PUSH und POP-

Befehle bei Lists geboten, die einer Clientanwendung weitreichende Optimierungsmög-

lichkeiten bieten. Der Zugriff auf die Datenbank erfolgt dabei über die mitgelieferte

Konsole oder über eine entsprechende Client-API. Die Auswahl ist sehr groß und um-

fasst 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 abzu-

legen 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 ge-

sehen 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 Da-

tenbank „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-Source-

Community übergeben (Cassandra Wiki 2012c).

Entsprechend des proprietären Vorreiters Google stellt auch das Open Source Frame-

work Apache Hadoop das verteilte Dateisystem Hadoop Distributed File System


(HDFS) zur Verfügung und setzt als Apache Hadoop MapReduce eine quelloffenes

Variante des Programmier-Paradigmas um auf das Cassandra und HBase zurückgrei-

fen 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 be-

schreibt:

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 Programmie-

rung bekannt ist. Diese zeigt wiederrum auf eine Zuordnungstabelle von Spaltenfami-

lien, 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 enthal-

ten, 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": { //Row Key

"anchor" : { //Column Family

"cnnsi.com" : { //Column

T9 : "CNN" //Version & Value

},

"my.look.ca" : {

T8 : "CNN.com"

},

"contents" : {

"" : { //Column mit leerem Bez. ""

T6 : "<html>...",

T5 : "<html>...",

T3 : "<html>..."

}

}

}

...

}

Abbildung 4: Konzeptuelles Schema eines Wide Column Stores in JavaScript-naher Notation (Wilson 2008).


Das Konzept der spaltenorientierten Datenhaltung der Wide Column Stores hat Vortei-

le 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“ geliste-

te Cassandra leitet seine Eigenschaften sowohl von BigTable als auch Amazon Dyna-

mo 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“ be-

schreibt. Es ermöglicht, per horizontaler Fragmentierung („Sharding“) den Datenbe-

stand ü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 Schreibver-

antwortung 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).


Die im Cluster verbundenen Knoten befinden sich also in einer Master-Master-

Konfiguration, 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 mittei-

len 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 Grundla-

ge 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 grund-

legend unmöglich ist, zeigt Google durch die Nutzung von BigTable für den Großteil

seiner Dienstleistungen, wozu auch die Bereitstellung der Google Earth Satellitenbil-

dern 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 Storage-

Service anbietet. Der Zugang erfolgt dabei über eine Web-API. SimpleGeo bietet

grundlegende räumliche Abfragen auf Punktmengen durch Implementierung eines ei-

genen Zugriffsmechanismus (Finley 2011 und Malone 2010).

2.4 Document Stores

Wie der Name bereits andeutet, handelt es sich bei den „Document Stores“, um in ers-

ter 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.4.1 Datenhaltung

Das zugrundeliegende Datenmodell eines Document Stores wird als „dokumentenzent-

risch“ oder „dokumentenorientiert“ bezeichnet. Unter Dokumenten verstehen sich dabei

Daten im JSON-Format (JavaScript Object Notation) oder in der binärenkodierten Vari-

ante „BSON“. Um die Typen von Dokumenten zu unterscheiden, werden entsprechen-

de Eigenschaften in ihnen definiert, die sie „implizit“ unterscheiden (Scheliga 2010: 81).

JSON ist ein Austauschformat, das auf einer Untermenge der JavaScript-

Programmiersprache 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 Programmierspra-

chen 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 Kri-

terien 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, DELE-

TE, 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 im-

mer zum gleichen Ausgang führt. So kann verhindert werden, dass die gleiche Opera-

tion unwillentlich zu doppelten Dokumenten führt (Fielding 1999). Datenbank und Do-

kumente stellen die Ressourcen dar, auf die die Operationen angewandt werden kön-

nen. 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.).


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 HTTP-

Protokolls 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 aus-

zulesen, 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 folgen-

de 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 da-

bei 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 Antwortmen-

ge wird anschließend indexiert und ist unter der URI des Views verfügbar. List-

Funktionen dienen als „Render-Funktionen für Views“ (ebd.: 140) und verarbeiten die

Ergebnismenge eines Views weiter (ebd.). Sie eignen sich beispielsweise zum Umfor-

men 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.)


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


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 Ja-

vaScript Object Notation beruht. Die geometrischen Objekte der Spezifikation orientie-

ren 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 de-

finieren (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 Fir-

ma 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 deut-

lich 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üp-

fungen dieser Datensätze untereinander“ (Edlich 2011: 207). Das Grundkonzept der

Graphdatenbanken basiert auf der Graphentheorie der Mathematik, welche das


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 „RDF-

Stores“ 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-Graph-

Modell“ 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.).


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 Da-

tensä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 herzustel-

len, gestaltet sich die Traversierung eines Graphen schon bedeutend intuitiver (Edlich

2011: 225f.).

Aufgrund der Komplexität des Datenmodells, müssen ähnlich wie bei den SQL-

Datenbanken, 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.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.


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 To-

pologie einpflegen. Darüber hinaus bietet Neo4j die Spatial Extension „Neo4j Spatial“.

Dieser steht bisher lediglich als Development Version zur Verfügung, kann aber in sei-

nem tagesaktuellen Stand vom öffentlichen Git-Repository geladen werden (Neo


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 Abfra-

gen auf Geodaten per REST-Schnittstelle erlaubt.

Durch den Aufbau auf das GeoTools Framework ist es möglich, Neo4j als Datenhal-

tungskomponente 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 Graphdaten-

bank 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 21

3 Anwendungspotential für Geodaten

“In summary, one can leverage at least the following ideas to get superior perfor-mance:

A non-relational data model. If the user’s data is naturally something other than ta-bles 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. Mittlerwei-

le 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 weitrei-

chende 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 Defi-

nition 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 insbe-

sondere unter Nutzung von GIS-Funktionalitäten wiederum neue Informationen abge-

leitet 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.2 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 un-

strukturierten Form eines Binary Large Objects (BLOB) möglich, zum anderen kann sie

strukturiert unter Nutzung der numerischen Datentypen, die durch die Datenbank an-

geboten 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 Abfra-

gen 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 umge-

setzt 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 NoSQL-

Datenbanken 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.3 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 NoSQL-

Datenbanken (s. Anhang 2), stellte dazu in einem Blog-Eintrag fest, dass die Komplexi-

tät des Datenmodells der NoSQL-Datenbanken beginnend bei den Key/Value und Wi-

de Column Stores, über die Document Stores und schließlich bis hin zu den Graphda-

tenbanken zunimmt. Daraus ergibt sich eine Wechselwirkung mit der Skalierbarkeit der

Datenbank. Da Key/Value Stores und Wide Column Stores auf ein einfaches Daten-

modell 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 bei-

spielsweise 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 un-terscheidet 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 theore-

tischer 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


Datenmodell die „Komplexität“ eine Stufe höher in die Anwendungsebene und er-

schwert so die Implementierung. Dementsprechend sollte die Wahl der richtigen Da-

tenbank nach dem Zweck ihrer Anwendung erfolgen. (Eifrem 2009). Dies gilt insbe-

sondere 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 Dienst-

leister, alle zur Verfügung gestellten Informationen zu speichern und dabei auch zu

Spitzenzugriffszeiten eine angenehme Nutzererfahrung zu gewährleisten. Die quantita-

tive 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 Referenz-

system 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 Geoinfor-

mationssystems eingesetzt werden, stellen sich andere Anforderungen, denn allge-

mein 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 Geo-

metrie lediglich aus einem Punkt besteht. Im speziellen bezieht sich dies auf eine Posi-

tion, 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 be-

trachtet 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.


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 NoSQL-

Datenbanksysteme 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,


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-


stellt werden (ebd.). Ohne die im vorherigen Kapitel vorgestellten Beschränkungen

besteht die Geometrie von raumbezogenen Objekten nicht nur aus der metrischen In-

formation des Punktes, sondern ist um topologische Beziehungen zwischen den Punk-

ten bereichert.

Die Haltung von solch komplexen raumbezogenen Daten in Datenbanken ist bekann-

termaßen nicht trivial. Diese Aufgabe wird allgemein zu den „Nichtstandardanwendun-

gen (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 NoSQL-

Datenbanken 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


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 NoSQL-

Datenbanken 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.


Tabelle 1: Eigenschaften von NoSQL-Datenbanken in Relation zu Charakteristiken von Nicht-standardanwendungen.

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.6 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 NoSQL-

Datenbank gibt Google durch sein Produkt Google Earth. Die Haltung und Aufberei-

tung wird nach eigner Aussage in Google BigTable verwirklicht. 2006 ist die Tabellen-

größ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 Satelli-

tenbilder 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 ver-

teilten Dateisystem GFS vor und dient zur Interaktion mit dem Nutzer. Allein diese Ta-

belle 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 geo-

referenzierten Daten zwischen verschiedenen Systemen eine wichtige Rolle und stellt

ein altes Problem dar (de Souza Baptista 2011). Durch die Entwicklung der NoSQL-

Datenbanken ist denkbar, dass etwa CouchDB, Neo4j oder MongoDB zu einer hetero-

generen 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


Schnittstellen zwischen den Welten zu bemühen, um so den Informationsfluss zu för-

dern.

Der wohl überzeugendste Weg, ist es auf bereits bestehende Standards zurückzugrei-

fen. 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 Zu-

griff 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 Schnittstel-

le 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 O-

penSource-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 NoSQL-

Datenbanken 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 32

4 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 da-

bei:

Geodaten in CouchDB einlesen

Mit der Erweiterung GeoCouch vertraut machen und einen Abfragemechanis-

mus definieren

Webseite über CouchDB hosten

Datengrundlage sollen dabei öffentlich verfügbare Geodaten sein, wie sie von öffentli-

chen Trägern angeboten werden. Dies umfasst insbesondere Informationen zu Lan-

despflege 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) abge-

rufen werden und sollen in diesem Entwurf als Datengrundlage für eine digitale Über-

sichtskarte 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 Pa-

cket 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.1 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 sinn-

voll, 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 Admin-

Zugang 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 Da-

tenbank „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“ ange-

legt, die für die MVCC-Versionierung genutzt wird.


{

"_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 JSON-

Objekt enthält.

Um umfangreichere Abfragen auf Grundlage der Dokumente zu verwirklichen, kann ein

„View“ eingesetzt werden. Sie werden in Design-Dokumenten als JavaScript-

Funktionen 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 fil-

tern 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 Er-gebnis der Map-Funktion aggregieren.


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 Indexierungs-

fä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 Spa-

tial Views sowie die gesuchte Bounding Box ergänzt. Eine räumliche Abfrage der ent-

haltenen 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


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 ge-

wü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 ge-

wählten Vorschrift in eine Liste von Objekten. Abbildung 18 zeigt hierfür eine Ja-

vaScript-Funktion, welche eine Ergebnisliste mit den Spalten „geometry“ und „value“ in

eine GeoJSON-FeatureCollection wandelt.


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 wur-

de. 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 be-

schleunigen, ist es möglich, über die Methode getBounds() der Leaflet-Karte die aktuel-

le 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 wer-

den. Die Liste wird anschließend durch die in Abbildung 18 vorgestellte List-Funktion in

eine GeoJSON-FeatureCollection gewandelt und so als Antwort übertragen.


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 = '';

if (e.properties && e.properties.NAME){

popupContent+='Name: ' + e.properties.NAME + ' '

}

[…]

popupContent+='';

if (popupContent!='') {

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 aufge-rufen wurde, um. Die nachfolgenden Methoden im Körper der „success“-Funktion sind Bestand-teil 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 untersuchen-

de Feature lassen sich so weitere Informationen abrufen (s. Abbildung 19).

Die Webseite und alle referenzierten JavaScript-Dateien wurden anschließend als At-

tachement an ein Design-Dokument angehangen. So ist der Zugriff per URI der Web-

seite als Anhang des Designdokuments in der Form

http://host:port/db/_design/technik/index.html möglich.


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 Poly-gon) 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 Websei-

te aus der CouchDB-Instanz geladen werden. Die Reihenfolge sieht dabei folgender-

maß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 Schnitt-

stellen, da Geodaten, wenn auch mit einem höheren ersten Aufwand, an das ge-

wünschte Mapping-Framework angepasst werden können.

Zu beachten ist, dass die erste Indexierung als R-Tree für große Datenbestände zeit-

aufwändig ausfallen kann. Dies sollte beim Erstellen einer Webpräsens berücksichtigt

werden, um Nutzern die Wartezeit zu ersparen. Nachdem der Index bereitsteht, wer-

den 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 Tes-

ten verschiedener Spatial Views auf, dass der Index eines Views sehr schnell viel


Speicherplatz in Anspruch nehmen kann. Um Speicherplatz zu sparen, ist es sinnvoll,

alte Views durch den „Compaction“-Befehl zu entfernen, der durch CouchDB bereitge-

stellt wird.

Die Abfragemöglichkeiten beschränken sich im Moment auf einfache Bounding Box

Queries. In Kombination mit dem angewandten MapReduce-Verfahren und den Forma-

tierungsmö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 Ge-

oCouch-Team sein wird. Nichtsdestotrotz sind nach eigenen Aussagen des Ge-

oCouch-Programmierers Volker Mische weitere Funktionen in Arbeit (s. Anhang 1).

5 Navigationsanwendung mit Neo4j Spatial 41

5 Navigationsanwendung mit Neo4j Spatial

Die Suche nach einem Weg zwischen zwei Punkten ist eine der grundlegenden Fra-

gen, die durch Geodaten beantwortet werden können. Die Suche lässt sich durch Be-

dingungen, wie das Finden des kürzesten oder schnellsten Weges, beliebig erweitern.

Die Beschreibung eines solchen Weges wird sich allgemein auf die einzelnen Weg-

punkte 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. Ent-

scheidend für das Traversieren eines solchen Graphen ist in erster Linie nicht die Met-

rik der Punkte, sondern ihre Topologie. Diese sollte sich in einer Graphdatenbank wie-

dergeben lassen.

Im Folgenden soll ein Beispiel für eine solche Problemlösung gegeben werden, bei

dem topologisch strukturierte Geodaten in die Graphdatenbank Neo4j importiert wer-

den 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 Algorith-

men, 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


Auswertung auf die tatsächliche geometrische Länge beziehen, wie es von einer Navi-

gationsanwendung 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 Vek-

tordaten 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 OpenSt-

reetMap-Projekts überschreiten. Unter http://download.geofabrik.de/osm/ sind tagesak-

tuelle Datensätze ganzer Kontinente und Staatsgebiete sowohl als OSM (OpenStreet-

Map-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 OSM-

Format 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 Well-

known Binary steht die Möglichkeit des Imports von Shapefiles und OSM-Dateien be-

reit.


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 Sub-

Graph 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 Eigen-

schaften 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 Im-

portieren aus den gegebenen Koordinaten berechnet wird. Es handelt sich also um

einen gewichteten Sub-Graphen.

Abbildung 24: Visualisierung in Neoclipse.


Die Nachbarschaftsbeziehungen zu angrenzenden Pfaden lassen sich über die „NO-

DE“-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 eigentli-

chen 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 Cypher-

Schreibweise 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 anlie-

genden 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 ausgegan-

gen, 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:


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 startNea-restNeighborLatLonSearch() 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 beson-

dere 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.


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 Abbil-

dung 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, wel-

cher 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“ getes-

tet. 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 gewonne-

ne Wissen auf die Konfiguration der zur Traversierung des Graphen genutzten Klasse

angewandt werden. Hier ergab sich ein grundlegendes Problem bei der aktuellen Im-

plementierung für OSM-Daten: Die NearestNeighbor-Suche erwidert den Referenzkno-

ten 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 Cypher-

Skript, das eine Liste aller Knoten die auf die gerichtete Kante „NODE“ folgen erstellt.

Diese Knoten entsprechend dabei den Trägern der metrischen Information der Geo-

metrie (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 ge-

suchten 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 berech-

net werden. Zum Einsatz kommt hier der Dijkstra-Algorithmus, der, neben anderen

Traversierungsalgorithmen für gerichtete und ungerichtete Graphen, durch die Neo4j-

Bibliothek 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


zu traversieren, die für diese Aufgabe von Bedeutung sind, müssen bestimmte Krite-

rien erstellt werden. Dafür dient die Klasse des „Expander“:

Expander expander = Traversal.emptyExpander();

expander = expander.add(RelTypes.NODE);

expander = expander.add(RelTypes.NEXT);

expander = 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 Path-

Finder, welche mit Hilfe des zuvor definierten Expanders und einer Vorschrift zur Inter-

pretation 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 visuali-

sieren. 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 verwende-

te 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.


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 wer-den.

5.6 Fazit

Dieser Prototyp demonstriert die Eignung von Graphdatenbanken zur Analyse von To-

pologie. Durch die implizite Identifikation von Kanten und Knoten über deren Eigen-

schaften bietet das Property-Graph-Modell eine große Vielseitigkeit. Für die Berech-


nung von gewichteten und ungewichteten Pfaden stehen neben Dijkstra weitere Algo-

rithmen 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 per-

fektionieren. Beispielsweise wäre es denkbar, einen Sub-Graphen wie den einer Geo-

metrie durch einen eigenen Zugriffsmechanismus zu ergänzen. Das in Kapitel 5.3 vor-

gestellte 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ünschens-

wert 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 Geomet-

rien 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 Ent-

wicklung.

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, standar-

disierten Abfragesprache steht für diese etablierten Systeme auch eine zentrale Do-

kumentation 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 50

6 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 Katego-

rien wurden mit ihren Spatial Extensions und Anwendungen vorgestellt. Danach wur-

den zunächst Geodaten definiert, um deren Komplexität darzulegen und davon ausge-

hend die konventionelle Verarbeitung in SQL-Datenbanken mit ihren Vor- und Nachtei-

len grob zu umreißen. Anschließend wurde gezeigt, wie die Komplexität des Datenmo-

dells 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 wei-

teren 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 Dokumentenstruk-

tur unterstützen, bieten eine interessante Alternative zu SQL-Datenbanken mit ihrer

Kombination aus Schemalosigkeit, 2D-Indexierung und MapReduce an. Auch Graph-

datenbanken 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 über-

prü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 er-

laubt, einen Geodienst nicht nur zu konsumieren, sondern selbst zu pflegen. Die Be-

rechnung 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 Datenbankty-

pen möglich ist. Durch die hohe Komplexität, die Geodaten im Allgemeinen jedoch

aufweisen, ist genau abzuwägen, welche Datenbank zum Einsatz kommen soll. Auf-

grund des überlegenen Entwicklungsstands der objektrelationalen Geodatenbanken,

6 Zusammenfassung und Ausblick 51

wie PostGIS oder Oracle Spatial, sind diese jedoch bei komplexen Projekten vorzuzie-

hen.

Zu beachten ist, dass es sich bei dieser Arbeit lediglich um eine momentane Einschät-

zung 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 entwi-

ckeln 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-der-welt/ (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)

http://www.mongodb.org/display/DOCS/Geospatial+Indexing

http://aws.amazon.com/de/ec2/

http://www.alexbellon.de/die-20-bestverdienenden-internetseiten-der-welt/

http://www.alexbellon.de/die-20-bestverdienenden-internetseiten-der-welt/

http://www.eecs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf

http://geojson.org/geojson-spec.html

http://wiki.apache.org/cassandra/ClientOptions

http://wiki.apache.org/cassandra/DataModel

http://wiki.apache.org/cassandra/FrontPage

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.google.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.google.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-scaling-to-complexity.html (18.02.2012)

EVAN, E. (2009): NOSQL 2009. Internet: http://blog.sym-link.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-15m-users-triples-audience (22.02.2012)

http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/de/archive/bigtable-osdi06.pdf

http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/de/archive/bigtable-osdi06.pdf

http://www.snailinaturtleneck.com/blog/2011/06/08/mongo-in-flatland/

http://www.gdal.org/ogr/drv_couchdb.html

http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/archive/mapreduce-osdi04.pdf

http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/archive/mapreduce-osdi04.pdf

http://blogs.neotechnology.com/emil/2009/11/nosql-scaling-to-size-and-scaling-to-complexity.html

http://blogs.neotechnology.com/emil/2009/11/nosql-scaling-to-size-and-scaling-to-complexity.html

http://blog.sym-link.com/2009/05/12/nosql_2009.html

http://blog.sym-link.com/2009/05/12/nosql_2009.html

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

http://www.readwriteweb.com/cloud/2011/02/video-simplegeo-cassandra.php

http://www.orientechnologies.com/orient-db.htm

http://download.geofabrik.de/osm

http://www.gdal.org/ogr/drv_couchdb.html

http://wiki.apache.org/cassandra/

http://www.google.com/enterprise/earthmaps/builder.html

http://www.odbms.org/Introduction/history.aspx

http://www.clickz.com/clickz/news/2130251/foursquare-reaches-15m-users-triples-audience

http://www.clickz.com/clickz/news/2130251/foursquare-reaches-15m-users-triples-audience

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/geocouch-utils (15.01.2012)

Open Geospatial Consortium (2011): OpenGIS® Implementation Standard for Geo-graphic information - Simple feature access - Part 1: Common architecture. In-ternet: https://portal.opengeospatial.org/modules/admin/license_agreement.php?suppressHea-ders=0&access_license_id=3&target=http://portal.opengeospatial.org/files/%3fartifact_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/short-term-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/Thrift-Scalable-Cross-Language-Services-Implementation (21.02.2012)

http://andrewhitchcock.org/?post=214

https://github.com/couchbase/geocouch

http://www.mugv.brandenburg.de/cms/detail.php/bb2.c.515599.de

http://strangeloop2010.com/talks/14495

http://docs.neo4j.org/chunked/1.6.1/cypher-query-lang.html

https://github.com/neo4j/spatial

http://gis.hsr.ch/wiki/images/f/fd/Postgis_einfuehrung_2008.pdf

https://github.com/maxogden/geocouch-utils

https://github.com/maxogden/geocouch-utils

https://portal.opengeospatial.org/modules/admin/license_agreement.php?suppressHeaders=0&access_license_id=3&target=http://portal.opengeospatial.org/files/%3fartifact_id=25355




http://www.opengeospatial.org/pressroom/pressreleases/1497

http://www.opengeospatial.org/ogc/historylong

http://wiki.openstreetmap.org/wiki/OSM_XML

http://docs.oracle.com/cd/B19306_01/appdev.102/b14256/sdo_topo_concepts.htm#CIHFGFIA

http://docs.oracle.com/cd/B19306_01/appdev.102/b14256/sdo_topo_concepts.htm#CIHFGFIA

http://trac.osgeo.org/postgis/wiki/UsersWikiPostgisTopology

http://www.w3.org/RDF/

https://github.com/tinkerpop/gremlin/wiki/Defining-a-Property-Graph

https://github.com/tinkerpop/blueprints/wiki

http://antirez.com/post/short-term-redis-plans.html

http://antirez.com/post/short-term-redis-plans.html

http://www.scribd.com/doc/20232450/Thrift-Scalable-Cross-Language-Services-Implementation

http://www.scribd.com/doc/20232450/Thrift-Scalable-Cross-Language-Services-Implementation

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-be-upon-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. Inter-net: 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)

http://cacm.acm.org/blogs/blog-cacm/32212-the-end-of-a-dbms-era-might-be-upon-us/fulltext

http://cacm.acm.org/blogs/blog-cacm/32212-the-end-of-a-dbms-era-might-be-upon-us/fulltext

http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/nosql/Home%20Page

http://hbase.apache.org/

http://openlocation.org/geohash/geohash-js/

http://redis.io/clients

http://redis.io/commands

http://redis.io/topics/replication

http://redis.io/topics/transactions

http://redis.io/topics/virtual-memory

http://www.allthingsdistributed.com/2012/01/amazon-dynamodb.html

http://jimbojw.com/wiki/index.php?title=Understanding_Hbase_and_BigTable

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 JavaScript-naher 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 Da-ta.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 In-ternet.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 Geo-graphic information - Simple feature access - Part 1 Common architecture..pdf Open Geospatial Consortium (2012a) The OGC Forms REST and WFS FE Stand-ards 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


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


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://nosql-

database.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 be-

nutzt sowie alle wörtlich oder sinngemäß übernommenen Stellen in der Arbeit als sol-

che und durch Angabe der Quelle gekennzeichnet habe. Dies gilt auch für Zeichnun-

gen, Skizzen, bildliche Darstellungen sowie für Quellen aus dem Internet.

Mir ist bewusst, dass die Hochschule für Technik und Wirtschaft Dresden Prüfungsar-

beiten stichprobenartig mittels der Verwendung von Software zur Erkennung von Pla-

giaten überprüft.

___Dresden, den 23.02.2012____ ____________________________

Ort, Datum Unterschrift Student

Documents

Einsatz von NoSQL-Datenbanksystemen für Geodatengeoinformatik.htw-dresden.de/abschlussarbeiten/BA... · 1 Einführung in die Welt der NoSQL-Datenbanken 2 ... finden sich heute beispielsweise