Bachelorarbeit. Einsatz von NoSQL-Datenbanksystemen für Geodaten

Transkript

1 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: Gutachter: Prof. Dr.-Ing. F. Schwarzbach 2. Gutachter: Prof. Dr. oec. G. Gräfe Eingereicht am:

2 Inhaltsverzeichnis II Inhaltsverzeichnis Inhaltsverzeichnis... II Einleitung Einführung in die Welt der NoSQL-Datenbanken Historischer Abriss NoSQL Scaling Up/Out CAP-Theorem ACID & BASE MapReduce Schemalosigkeit von Daten Allgemeiner Überblick Kategorisierung Key/Value Stores Datenhaltung Redis Spatial Extension Wide Column Stores Datenhaltung Apache Cassandra Spatial Extensions Document Stores Datenhaltung CouchDB Spatial Extensions Graphdatenbanken Datenhaltung Neo4j Spatial Extensions Anwendungspotential für Geodaten Definition Geodaten Die Haltung von Geodaten in SQL-Datenbanken Skalierbarkeit vs. Komplexität Positionsdaten in NoSQL-Datenbanksystemen Komplexe Geodaten in NoSQL-Datenbanksystemen Rasterdaten Zukünftige Entwicklungen... 30

3 Inhaltsverzeichnis III 4 Implementierung einer Webpräsenz für Geodaten mit CouchDB und GeoCouch Vorbereitung der Daten für CouchDB Abfrage der Datensätze aus CouchDB Abfrage von Datensätzen als FeatureCollection Integration der GeoCouch-Daten in eine Website Fazit Navigationsanwendung mit Neo4j Spatial Vorbereitungen Datengrundlage Auffinden des nächsten Knoten zu einer beliebigen Koordinate Berechnung des kürzesten, befahrbaren Weges Ergebnis Fazit Zusammenfassung und Ausblick Literaturverzeichnis... VI Abbildungsverzeichnis... X Tabellenverzeichnis... X Anlagenverzeichnis... XI Anhang 1... XIII Anhang 2... XIV Erklärung über die eigenständige Erstellung der Arbeit... XV

4 Einleitung 1 Einleitung Google, Amazon und Facebook teilen sich nicht nur den Status, eine der zehn am besten verdienenden Webseiten der Welt zu sein (Bellon 2012), sie haben auch etwas anderes gemeinsam: Alle drei Großkonzerne haben NoSQL-Datenbanken und die Nutzung von Geodaten für sich entdeckt. Gerade solche Dienste, die sich Geodaten in direkter oder indirekter Art zunutze machen haben in letzter Zeit große Aufmerksamkeit erlangt. So ermöglicht beispielweise mittlerweile jedes Social Network, allen voran Facebook, seinen Nutzern, ihre Position anderen mitzuteilen. Anwendungen wie Foursquare bauen sogar in erster Linie auf die Verknüpfung von sozialer Interaktion und Geodaten und die W3C Implementierung der Geolocation API mit HTML5 macht es mittlerweile fast jedem internetfähigem Gerät möglich, ebenfalls seine aktuelle Position mitzuteilen. Damit steht diese Entwicklung klar im Trend und verursacht dadurch ein immenses Daten- und Nutzeraufkommen. NoSQL-Datenbanken stellen in diesem Zusammenhang möglicherweise eine Option dar, bisher verwendete SQL-Datenbanken abzulösen und die so entstandenen Big Data besser zu verwalten. Das Ziel dieser Arbeit soll darum sein, den aktuellen Entwicklungsstand von FOSS- NoSQL-Datenbanksystemen darzustellen und deren Anwendungsmöglichkeiten für Geodaten zu untersuchen. Dazu soll im ersten Kapitel eine zweckmäßige Zusammenfassung der Historie der NoSQL-Bewegung gegeben werden. Nach einer Erläuterung des Begriffs NoSQL werden dann grundlegende Konzepte nichtrelationaler Datenbanken eingeführt. Das zweite Kapitel schließt mit einem allgemeinen Überblick zu den heute frei verfügbaren NoSQL-Datenbanken an. Die aktuell dafür gebräuchlichste Kategorisierung soll darin vorgestellt und jeweils ein Vertreter dieser Kategorien näher betrachtet werden. Insbesondere soll hier auf die für Geodaten interessante Eigenschaften und Standards eingegangen werden, um davon ausgehend eine Einschätzung zum aktuellen Entwicklungsstand zu treffen. Eventuell verfügbare Spatial Extensions werden in die Betrachtungen entsprechend mit einbezogen und in ihrem Funktionsumfang beleuchtet. Daran anschließend soll eine Diskussion des Anwendungspotentials von NoSQL-Datenbanken vorgenommen werden, bei der die in Kapitel zwei vorgestellten Systeme wieder aufgegriffen und exemplarisch auf ihre Tauglichkeit für Geodaten untersucht werden. Davon abgeleitet soll es möglich sein, eine Einschätzung über das theoretische Anwendungspotential der verschiedenen NoSQL-Datenbanken geben zu können. Kapitel fünf und sechs stellen zwei unterschiedliche exemplarische Implementierungen vor, die jeweils mit einem für sie geeigneten Vertreter der 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 treffen zu können.

5 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 wichtigsten Konzepte zu verschaffen. Im folgenden Kapitel soll dazu zunächst ein historischer Abriss zur Entstehung der NoSQL-Bewegung gegeben werden. Anschließend folgt eine kurze Auseinandersetzung mit Konzepten, die für viele der 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 Datenmodell anspielt (Strozzi 2010). Erste wirklich als NoSQL-Datenbanken zu bezeichnende Systeme entstanden mit Einzug der Web 2.0 Welle und der damit verbundenen Datenflut. Um den exponentiellen Wachstumsraten digitaler Informationen Herr zu werden, begann der Suchmaschinenriese Google 2004 mit der Arbeit an BigTable (Hitchcock 2005), einer nichtrelationalen Datenbank, optimiert zur verteilten Haltung exzessiver Datenmengen im Petabyte- Bereich. BigTable nutzt eine Kombination aus Reihen/Zellen-Schlüsseln und Zeitstempeln, um Daten lose zu strukturieren, und baut auf das hauseigene Dateisystem Google File System (GFS) auf (Chang 2006: 1). Seit der öffentlichen Präsentation der Ergebnisse 2006 im BigTable Whitepaper und dessen Präsentation auf der OSDI '06 erfuhr die Entwicklung von nichtrelationalen Systemen einen sprunghaften Anstieg. So finden sich heute beispielsweise Eigenschaften von BigTable in Apache HBase oder Apache Cassandra. Die Qualität dieses neuen Konzepts ist dabei nicht allein die Fähigkeit, große Datenmengen zu verwalten, sondern auch die Ausrichtung auf ein verteiltes System aus kostengünstigen Standardservern ( commodity server ), die zu leistungsfähigen und fehlertoleranten Clustern zusammengeschlossen werden können. Damit war es nun auch möglich, dynamisch auf wachsende Datenmengen und steigende Nutzerzahlen einzugehen und die Kapazitäten entsprechend anzupassen. (Edlich 2011: 2) Auch andere Unternehmen, deren Geschäft primär auf der Hochverfügbarkeit ihrer Dienste beruht, haben ähnliche Anwendungsfälle für nichtrelationale Datenbanken ge-

6 1 Einführung in die Welt der NoSQL-Datenbanken 3 funden. Aufgrund der Tatsache, dass der Versandkonzern Amazon zur Weihnachtszeit ein stark erhöhtes Nutzeraufkommen zu verzeichnen hatte, die technologischen Grenzen der eingesetzten Datenbanksysteme nach eigenen Aussagen 2004 aber ausgereizt waren, kam es zu Einbrüchen in der Verfügbarkeit der Dienste. Daraufhin setzte Amazon mit der Entwicklung von Dynamo ebenfalls auf ein skalierendes, nichtrelationales System aus der Eigenentwicklung (Vogels 2012). Obwohl von Google so nicht propagiert, steht das proprietäre BigTable heute als Begriffspate für eine ganze Kategorie der NoSQL-Datenbanken die sogenannten Wide Column Stores. Vermutlich setzte sich der Begriff im Juni 2009 durch, nachdem eine mit NoSQL betitelte Konferenz in San Francisco auf der Plattform Eventbride.com angekündigt wurde. Sie umfasste Präsentationen zu mehreren Datenbankenkategorien wie Voldemort, Cassandra, Dynomite, HBase, Hypertable und CouchDB (Evan 2009). Seitdem ist NoSQL zu einer Art Sammelbegriff für diese verschiedenen Datenbankengeworden und wird gerade aus Marketinggründen gern genutzt (Edlich 2011: XV). 1.2 NoSQL Während der Wiedererkennungswert des Wortes NoSQL unumstritten hoch ist, ist der Begriff selbst eher irreführend. Es hat den Anschein, dass SQL als Datenbankabfragesprache kategorisch abgelehnt wird, was jedoch nicht der Fall ist. Es gibt zum einen Systeme, die SQL in verschiedenen Qualitäten selbst implementieren, wie z.b. OrientDB und GenieDB. Außerdem haben die neuen Datenmodelle zu einer ganzen Reihe von Abfragesprachen geführt, die sich an der Semantik von SQL, und nicht zuletzt an der englischen Sprache, orientieren. Die Cassandra Query Language (CQL) ist einer dieser Vertreter. SQL wird vielmehr als Synonym für (objekt-)relationale Datenbanksysteme verstanden. Dies ist damit auch die vielleicht wichtigste und einende Eigenschaft der als NoSQL proklamierten Datenbanksysteme. Sie brechen mit dem Status Quo der relationalen Datenhaltung in vordefinierten, zeilenorientierten Tabellen. Carlo Strozzi hat in diesem Sinne also Recht, wenn er behauptet, NoRel wäre unter Umständen die treffendere Bezeichnung gewesen. Dementsprechend wird NoSQL mittlerweile mit Not-only-SQL gedeutet, was auch in dem gemeinschaftlich entworfenen Definitionsvorschlag für NoSQL-Datenbanken von Prof. Stefan Edlich deutlich wird: Unter NoSQL wird eine neue Generation von Datenbanksystemen verstanden, die meistens einige der nachfolgenden Punkte berücksichtigen: 1. Das zugrundeliegende Datenmodell ist nicht relational. 2. Die Systeme sind von Anbeginn an auf eine verteilte und horizontale Skalierbarkeit ausgelegt. 3. Das NoSQL-System ist Open Source. 4. Das System ist schemafrei oder hat nur schwächere Schemarestriktionen. 5. Aufgrund der verteilten Architektur unterstützt das System eine einfache Datenreplikation.

7 1 Einführung in die Welt der NoSQL-Datenbanken 4 6. Das System bietet eine einfache API. 7. Dem System liegt meistens auch ein anderes Konsistenzmodell zugrunde: Eventually Consistant und BASE, aber nicht ACID [ ]. (Edlich 2011: 2). Der Begriff NoSQL bezieht sich also nicht nur auf die Abfragesprache der relationalen Datenbanken. Gerade die Skalierbarkeit und der Aufbau als verteiltes System scheint eine große Bedeutung im Umfeld der NoSQL-Systeme zu spielen und soll anschließend Gegenstand dieser Betrachtungen sein. 1.3 Scaling Up/Out Technisch gesehen wird den Anforderungen unserer vernetzten Welt bisher mit der unter Scaling Up oder vertikaler Skalierung bekannten Vorgehensweise begegnet. Server, deren Kapazitäten erreicht sind und die Clientanfragen nicht mehr ausreichend bedienen können, werden durch neue Technik ersetzt oder aufgerüstet. Die entsprechend leistungsstarke Hardware ist teuer. Trotzdem ist dies für die meisten Anwendungen ein ausreichendes Mittel (Edlich 2011: 377). Eine Alternative zu einer Vertikalen Skalierung stellt die sogenannte Horizontale Skalierung oder Scaling Out dar. Darunter versteht man das Erweitern des Systems durch Einfügen zusätzlicher Computerressourcen (ebd.). Der Vorteil dabei liegt in der Möglichkeit, aus einem Verband aus Mittelklasse-Hardware einen leistungsfähigen Cluster zu bilden. Dies ist in der Regel kostengünstiger und ermöglicht eine dynamische Einflussnahme auf die Leistung des Systems durch Hinzufügen weiterer Rechner. Den aktuellen Gipfel der Horizontalen Skalierung stellt das sogenannte Cloud Computing dar (ebd.). Der Versanddienstleister Amazon etwa bietet auf Grundlage seiner eigenen Datencenter die Amazon Web Services an und erlaubt so eine Nutzung seiner Rechenkapazitäten. Der gewillte Kunde kann Rechenzeit kaufen und eigene virtuelle Server betreiben, deren Rechenleistung vom Cluster bereitgestellt wird. (Amazon.com 2012) Im Zusammenhang mit der Horizontalen Skalierung spielt das in Brewers 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 Entwicklungen, die in ihren Paradigmen über 25 Jahre alt sind (Stonebraker 2007: 1). Im Vergleich zu damals, hat sich das Spektrum für den Einsatz von Datenbanken jedoch vergrößert. Zumeist bedeutet dies die Integration in Web Services als verteilte Systeme, die einer viel größeren Zugriffslast unterliegen und dabei Hochverfügbarkeit bieten sollen. Eric A. Brewer stellte in diesem Zusammenhang eine gemeinhin als CAP-

8 1 Einführung in die Welt der NoSQL-Datenbanken 5 Theorem bekannte Theorie auf, welche besagt, dass die gewollten Eigenschaften Konsistenz, Verfügbarkeit und Partitionstoleranz für solche Dienste nicht gleichzeitig zu gewährleisten sind (Brewer 2000). Zwei Jahre später wurde dieses Theorem durch Seth Gilbert und Nancy Lynch für verteilte Web Services formal bestätigt (Gilbert 2002). Ein praktisches Beispiel dafür ist ein verteiltes System bestehend aus drei Servern. Da Netzwerkpartitionen eine Voraussetzung für ein solches System sind, gelingt es nicht, gleichzeitig Verfügbarkeit und Konsistenz aller drei Server zu wahren. In einem Konsistenz vernachlässigenden System würde zwar hohe Verfügbarkeit erreicht werden können, während eines Lesevorgangs jedoch könnte eventuell nicht der aktuellste Stand reflektiert werden. Soll andererseits Konsistenz garantiert werden, kann ein nicht verfügbarer Datenbankserver einen Schreibvorgang unterbinden, da er z.b. durch Transaktionierung gesperrt ist (Vogels 2009: 41). Ein nicht partitioniertes System hingegen bestehend aus Client und Speichereinheit könnte Verfügbarkeit und Konsistenz durch Transaktionierungsmechanismen garantieren. In dieser Umgebung würde der Ausfall einer Komponente jedoch zum Totalausfall führen, was bedeutet, dass für ein solches System das CAP-Theorem nicht gilt (ebd.). 1.5 ACID & BASE Aus dem CAP-Theorem lässt sich schließen, dass aufgrund des hohen Datenzugriffsbedarfs durch steigende Nutzerzahlen das ursprünglich verwendete sogenannte A- CID-Paradigma nicht mehr uneingeschränkt anwendbar ist. Unter dem Begriff ACID sind die vier Eigenschaften Atomicity, Consistency, Isolation und Durability zusammengefasst, welche durch Transaktionierung in RDBMS durchgesetzt werden (Kemper 2011: 289). Viele NoSQL-Datenbanken setzen daher auf ein alternatives Modell, welches gemeinhin als BASE bezeichnet wird und auf Transaktionierung verzichtet. BASE ist ein Akronym für: Basically Available Soft-State Eventually Consistent Der Grundgedanke beruht darauf, Hochverfügbarkeit für gelockerte Konsistenzbedingungen einzutauschen. Bei Eventual Consistency handelt sich also um einen optimistischen Ansatz, bei dem darauf verzichtet wird, alle im Cluster beteiligten Knoten durch Transaktionierung vor Inkonsistenzen zu sichern. Konsistenz der Daten wird so zu einem fließenden, sich über ein Zeitfenster ausbreitenden Zustand (Edlich 2011: 33). Zwar besteht so die Gefahr, dass für einen kurzen Zeitpunkt auf einigen Servern

9 1 Einführung in die Welt der NoSQL-Datenbanken 6 veraltete Daten zur Verfügung stehen, jedoch kann der hohe Bedarf an Zugriffen auf dieselben Datensätze eher gedeckt werden. Es ist offensichtlich, dass dieses Vorgehen nicht für jeden Einsatzzweck geeignet ist. Eine finanziellen Transaktion ließe ein solches Konzept nicht zu, da der richitge Kontostand nicht zu jedem Zeitpunkt garantiert wäre. Da die Konfigurationsmöglichkeiten zwischen ACID und BASE mittlerweile fließend sind und manche Datenbanken sogar eine Kombination der Paradigmen unterstützen, ist es sinnvoll, Vor- und Nachteile für die jeweilige Anwendung im Voraus abzuwägen (Edlich 2011: 34). 1.6 MapReduce Mit der starken Orientierung der nichtrelationalen Datenbanken nach verteilten Systemen und neuen Datenmodellen mussten auch neue Algorithmen erdacht werden, welche diese Anforderungen unterstützen. Einer der bekanntesten Algorithmen dieser Art ist MapReduce, welcher durch die Google-Ingenieure Jeffrey Dean und Sanjay Ghemawat für Google BigTable umgesetzt wurden (Edlich 2011: 12). Es handelt es sich dabei um ein Verfahren zur massiv parallelen Datenverarbeitung auf großen, verteilten Systemen. Die Parallelisierung beruht dabei auf den aus der funktionalen Programmierung abgeleiteten Methoden map() und reduce(), welche Abbildungsvorschriften darstellen, die auf Grundlage einer Kopie der Originaldaten in eine neue Datenstruktur überführen (Dean 2004: 1). Bei der Anwendung durch NoSQL-Datenbanken wie HBase, Cassandra oder BigTable erfolgt die Abarbeitung von Map und Reduce dabei in zwei Phasen. Die erste Phase ist die Map-Phase, bei der aus einer Liste von Werten in eine neue Liste von Werten überführt wird (ebd.: 2). Die Ausgangsliste stellt dabei den kompletten Datenbestand in der Datenbank dar. Da die Funktion auf Kopien der Originaldaten angewendet wird bzw. das Ergebnis eine neue Datenstruktur darstellt, beeinflussen sich mehrere gleichzeitige Aufrufe der Funktion nicht gegenseitig. Dies ermöglicht eine parallele Abarbeitung (s. Abbildung 1). Die optionale Reduce-Phase kann das Ergebnis der Map-Phase anschließend aggregieren. Die Funktion setzt voraus, dass sie rekursiv definiert ist, was sie so ebenfalls parallel ausführbar macht (Edlich 2011: 13).

10 1 Einführung in die Welt der NoSQL-Datenbanken 7 Abbildung 1: Datenfluss des MapReduce-Verfahrens (Edlich 2011: 17). Auf einem Computercluster, der die vielen Einzelprozesse der beiden Phasen auf die einzelnen Knoten verteilt, entsteht so ein enormes Potenzial für beschleunigte Berechnungen, die aufgrund der großen Datenmenge auf einem einzelnen Computer unter Umständen gar nicht möglich wären (Edlich 2011: 13). 1.7 Schemalosigkeit von Daten Neben den unterschiedlichen Herangehensweisen bei Konsistenz und Skalierung ist ein weiterer wesentlicher Unterschied zwischen den SQL- und NoSQL-Datenbanken, dass das Datenbankmodell selbst nicht vor dem Einfügen der ersten Datensätze definiert sein muss. Während vor dem Anlegen eines Datenbankmodells für 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 Datenhaltung ändern oder Informationen mit aufgenommen werden sollen, die beim Anlegen der Tabellen so nicht vorgesehen waren.

11 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 bestehende Systeme, wie beispielsweis Lotus Notes oder Oracle Berkeley DB, als nichtrelationale Systeme und sind zusammen mit derzeit mehr als 122 weiteren Datenbanken auf gelistet (Edlich 2012). Neben wenigen kommerziellen Anbietern handelt es sich dabei meist um Free and Open Source Projekte (FOSS) unterschiedlicher Größe. Aufgrund der schieren Größe des Angebots, kann hier nicht auf jede dieser Datenbanken eingegangen werden. Im Folgenden sollen deshalb die vier wichtigsten Kategorien nichtrelationaler Datenbanken vorgestellt werden und je ein typischer Vertreter genauer betrachtet werden, der diese repräsentiert. 2.1 Kategorisierung Eine Kategorisierung der Datenbanken erscheint zunächst schwierig, da die Eigenschaften der Systeme einerseits drastisch variieren, sich andererseits aber auch nur in Detailfragen unterscheiden. Der beste Weg, sich dem Angebot zu nähern, ist es, die Datenbanken nach Art der Datenhaltung zu unterscheiden. Die Website NOSQL Databases schlägt hier seit 2009 eine durch die Open Source Gemeinde diskutierte Ordnung vor, die sich weitgehend durchgesetzt hat. (Edlich 2012). Die Kategorisierung der nichtrelationalen Datenbanken basiert auf den ihnen zugrundeliegenden Datenmodellen und umfasst folgende Hauptkategorien: Key/Value Stores Wide Column Stores Document Stores und Graphdatenbanken. Die Einordnung der Systeme in die einzelnen Kategorien kann sich mitunter als schwierig erweisen, da hybride Lösungen beispielsweise Eigenschaften aus Key/Value-Stores und Document Stores mischen (z.b. Riak) (Edlich 2011: 179) oder Features mehrerer Kategorien implementieren (z.b. OrientDB). (Garulli 2011). 2.2 Key/Value Stores Die erste Gruppe der Key/Value Stores ist in den letzten Jahren sehr gewachsen. Seit den 70er Jahren bekannt, hat sich ihre Anzahl mit dem Erscheinen des Amazon Dynamo Whitepapers 2007 vervielfacht. Sie sind prädestiniert für Daten, die keine Relation zueinander aufweisen, da es sich um ein sehr einfaches Datenmodell handelt (Edlich 2011: 151).

12 2 Allgemeiner Überblick Datenhaltung Das Prinzip der Datenhaltung in einem Key/Value Store ähnelt einer Hash Table, also einer Zuordnungstabelle der objektorientierten Programmierung bestehend aus zwei Spalten. Eine Spalte enthält dabei den über eine Hash-Funktion abgebildeten Schlüssel ( Key ) über den der Zugriff erfolgt (s. Abbildung 2). Die zweite Spalte führt den assoziierten Wert, genannt Value, welcher als einzige Bedingung den Datentypen entsprechen muss, die durch die Datenbank unterstützt werden. Die einzelnen Einträge in die Zeilen der Tabelle sind dabei ohne weitere Relation zueinander (Edlich 2011: 36). Die Verantwortung der Beziehungen zwischen den Einträgen obliegt damit voll der Clientanwendung. Abbildung 2: Hashfunktion. Eingangswerte werden über eine bestimmte Funktion auf einen Werteraum abgebildet (Edlich 2011: 36) Redis Ein beliebter Vertreter der Key/Value Stores ist das Datenbanksystem Redis. Es startete 2009 als Entwicklung von Salvatore Sanfillippo und ist in ANSI-C programmiert (Edlich 2011: 152). Es steht für POSIX-kompatible Plattformen in einer New-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 Datenbank eingespielt werden (AOF Modus). Es ist ebenfalls möglich RDB und AOF-Modi zweckmäßig zu kombinieren oder komplett auf die nachhaltige Speicherung zu verzichten. Daten, die bei einem Ausfall ausschließlich im flüchtigen Arbeitsspeicher vorhanden waren, wären in einem solchen Fall jedoch verloren (Edlich 2011: 152f). Redis bietet die Möglichkeit, Operationen in einer Transaktion zusammenzufassen. Dies spart Verbindungszeit bei der Abarbeitung und schützt durch die atomare Reihenabarbeitung des Operationssatzes vor Inkonsistenz gegenüber weiteren Zugriffen (Edlich 2011: 156f.). Auf Konsolenebene geschieht dies mit dem Befehl MULTI. Zu beachten ist dabei, dass das Scheitern einer der Operationen, nicht das Scheitern der

13 2 Allgemeiner Überblick 10 restlichen durch MULTI zusammengefassten Operationen bedingt. Dies muss in der Anwendungsebene entsprechend berücksichtigt werden (VMWare 2011d). Um Redis zu skaliert, kann in einer Master-Slave-Schaltung über mehrere Knoten repliziert werden. Dies kann dazu dienen, die Leseleistung zu erhöhen oder Daten redundant vorzuhalten (ebd.). Zu beachten ist, dass zum gegenwärtigen Zeitpunkt (Version 2.4.7) kein Sharding mit Bordmitteln möglich ist. Der dazu notwendige Redis Cluster steht bisher nur als Developer Preview zur Verfügung und wird mit Version 2.6. erwartet (Sanfilippo 2011). Das bedeutet, dass der gesamte Datenbestand in den Arbeitsspeicher passen muss. Davon Daten in den virtuellen Speicher auszulagern wird abgeraten (VMWare 2011e). Auch wenn alle Datentypen die durch Redis unterstützt werden auf Strings basieren, werden komplexe Strukturen wie Listen, unsortierte und sortierte Sets und Hashes bereitgestellt (Edlich 2011: 153). Darüber hinaus werden Interaktionen, wie beispielsweise UNION und DIFF bei Sets, oder links- oder rechtsseitige PUSH und POP- Befehle bei Lists geboten, die einer Clientanwendung weitreichende Optimierungsmöglichkeiten bieten. Der Zugriff auf die Datenbank erfolgt dabei über die mitgelieferte Konsole oder über eine entsprechende Client-API. Die Auswahl ist sehr groß und umfasst alle verbreiteten hohen Programmiersprachen (VMWare 2011a) Spatial Extension Zum gegenwärtigen Zeitpunkt ist für keinen Key/Value Store eine Spatial Extension verfügbar (s. Anhang 2). Dies trifft auch für Redis zu. Da durch Redis binärsichere Strings unterstützt werden, ist es jedoch möglich, jede Art von Daten binärcodiert abzulegen und auszulesen. 2.3 Wide Column Stores Bei der zweiten großen Gruppe der NoSQL-Datenbanken, den Wide Column Stores (auch Column Family Store ), handelt es sich um spaltenorientierte, nichtrelationale Datenbanken. Sie könnten als Nachkommen des proprietären Google BigTable gesehen werden, da die Open-Source-Community vielfach begonnen hat, auf Basis der von Google veröffentlichten Forschungsunterlagen Eigenschaften von BigTable zu klonen und gewünschte hinzuzufügen. Ein sehr erfolgreiches Beispiel dafür ist die Datenbank HBase, die Teil des Apache Frameworks Hadoop ist (The Apache Software Foundation 2012). Auch der Social Network Riese Facebook hat einen Wide Column Store entwickelt. Dieser wurde unter dem Namen Cassandra 2008 der Open-Source- Community übergeben (Cassandra Wiki 2012c). Entsprechend des proprietären Vorreiters Google stellt auch das Open Source Framework Apache Hadoop das verteilte Dateisystem Hadoop Distributed File System

14 2 Allgemeiner Überblick 11 (HDFS) zur Verfügung und setzt als Apache Hadoop MapReduce eine quelloffenes Variante des Programmier-Paradigmas um auf das Cassandra und HBase zurückgreifen können (The Apache Software Foundation 2011) Datenhaltung Google selbst beschreibt das Datenmodell der Wide Column Stores als [ ] sparse, distributed, persistent multidimensional sorted map (Chang 2006: 1). Dabei handelt es sich um eine sehr eng gepackte Definition, die zusammengefasst Folgendes beschreibt: Die oberste Ordnungseinheit ist, so wie in einem Key/Value Store, der Zeilenschlüssel. Der Value ist in diesem Fall eine Map, wie sie aus der objektorientierten Programmierung bekannt ist. Diese zeigt wiederrum auf eine Zuordnungstabelle von Spaltenfamilien, daher auch der alternativer Name Column Family Store. Diese Verschachtelung von Zuordnungstabellen kann als multidimensional bezeichnet werden. Die Column Family verweist letztendlich auf Spalten, also columns, die versionierte Werte enthalten, welche wiederum ein nicht interpretiertes Byte-Array darstellen (Wilson 2008). Abbildung 3: Konzeptuelles Schema eines Wide Column Stores nach BigTable White Paper (Chang 2006: 2). { }... "com.cnn.www": { //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).

15 2 Allgemeiner Überblick 12 Das Konzept der spaltenorientierten Datenhaltung der Wide Column Stores hat Vorteile bei der Kompression und Analyse der Daten gegenüber den zeilenorientierten RDBMS. Andererseits ist das Lesen und Schreiben von Objektstrukturen aufwändiger (Edlich 2011: 63). Durch die sortierte Speicherung von Row Keys, Column Families und Columns (vgl. multidimensional sorted map bzw. Abbildung 4 ist es außerdem leichter, eine horizontale Partitionierung der Daten einzurichten und so Zugriffe auf mehr als einen Datenbankserver pro Abfrage zu reduzieren (ebd.) Apache Cassandra Das von Facebook entwickelte und mittlerweile als Apache Top Level Project gelistete Cassandra leitet seine Eigenschaften sowohl von BigTable als auch Amazon Dynamo ab. Cassandra ist damit auch ein gutes Beispiel für die eingangs erwähnte Vielfalt der NoSQL-Datenbanken, die durch Kombination von Konzepten entsteht. In erster Linie handelt es sich um einen BigTable-Klon der um eine weitere Organisationsebene, die Super-Column, erweitert ist (Edlich 2011: 83). Vorbild für die Skalierung ist das Amazon Dynamo Whitepaper welches unter anderem das Consistent Hashing beschreibt. Es ermöglicht, per horizontaler Fragmentierung ( Sharding ) den Datenbestand über eine große Menge von Datenbankservern zu verteilen. Das Grundprinzip besteht darin, den Hash-Wertebereich der Schlüssel über alle beteiligten Knoten zu verteilen und in einem Ring zu schließen. Jeder Rechner übernimmt die Schreibverantwortung für je eine dieser Partitionen. Außerdem wird diese Partition auf weitere Server repliziert, um so die Fehlertoleranz zu erhöhen. Sie ist dort als Schattenkopie vorgehalten und kann bei einem Ausfall neu im Ring verteilt werden. (Vogels 2007). Abbildung 5: Consistant Hashing-Ring. (Vogels 2007).

16 2 Allgemeiner Überblick 13 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 mitteilen und empfangen (ebd.). Als Schnittstelle steht Cassandra Thrift zur Verfügung, ein Framework, welches den plattformunabhängigen Austausch von Objekten ermöglicht (Slee 2007). Auf Grundlage der reinen Thrift API sind viele High Level-Clients verfügbar, der Zugriff auf ein Cassandra-Cluster ist also nativ in vielen Programmiersprachen wie Java, C++ und Ruby möglich (Cassandra Wiki 2012a) Spatial Extensions Derzeit steht, wie für Key/Value Stores, für keinen Wide Column Store eine Spatial Extension zur Verfügung (Stand Februar 2012). Die Schachtelung von Column Familys und Columns erlaubt strukturiertere Daten als dies bei einem reinen Key/Value Store möglich ist. Dass die Haltung von Geodaten in einem Wide Column Store nicht grundlegend unmöglich ist, zeigt Google durch die Nutzung von BigTable für den Großteil seiner Dienstleistungen, wozu auch die Bereitstellung der Google Earth Satellitenbildern per Desktop- und Webinterface gehört. (Chang 2006: 11f) Die gleichen technischen Grundlagen werden außerdem eingesetzt, um mit Google Earth Builder Geodaten für Unternehmen in der Cloud bereitzustellen (Google 2012). Apache Cassandra kommt außerdem bei der Firma SimpleGeo zum Einsatz, welche auf dem Wide Column Store aufbauende Point-of-Interest-Services und einen Storage- Service anbietet. Der Zugang erfolgt dabei über eine Web-API. SimpleGeo bietet grundlegende räumliche Abfragen auf Punktmengen durch Implementierung eines eigenen Zugriffsmechanismus (Finley 2011 und Malone 2010). 2.4 Document Stores Wie der Name bereits andeutet, handelt es sich bei den Document Stores, um in erster Linie dokumentenbasierte Datenbanken. Ein konzeptueller Vater der Document Stores ist Lotus Notes, das neben der Integration des relationalen IBM RB2 ebenfalls eine dokumentenzentrische Datenhaltung anbietet. Die Entwicklung ist also nicht grundlegend neu, hat aber durch CouchDB und dessen Begründer Damien Katz eine Wiederbelebung erfahren. Da sich die schemalose Dokumentenstruktur gerade für agile Webanwendungen eignet, wird CouchDB und auch die größte Konkurenz, das Document Store MongoDB, von der Entwicklergemeinschaft sehr gut angenommen (Edlich 2011: 117).

17 2 Allgemeiner Überblick Datenhaltung Das zugrundeliegende Datenmodell eines Document Stores wird als dokumentenzentrisch oder dokumentenorientiert bezeichnet. Unter Dokumenten verstehen sich dabei Daten im JSON-Format (JavaScript Object Notation) oder in der binärenkodierten Variante BSON. Um die Typen von Dokumenten zu unterscheiden, werden entsprechende Eigenschaften in ihnen definiert, die sie implizit unterscheiden (Scheliga 2010: 81). JSON ist ein Austauschformat, das auf einer Untermenge der 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 Programmiersprachen leicht zu verarbeiten (Scheliga 2010: 45.f). { } "_id": " b3772c8426e77a4e2c7000de8", "_rev": "4-17aaa5b24954e6c fda8b88", "name": "Ruby", "implementations": [ "Ruby", "JRuby" ] Abbildung 6: Beispiel eines einfachen JSON-Dokuments CouchDB CouchDB ist eine schemafreie, dokumentenorientierte Datenbank in der die Daten in Form von JSON-Datenstrukturen abgelegt werden. Der Zugriff auf CouchDB per HTTP-Protokoll orientiert sich eng an den durch Roy Fielding zusammengestellten Kriterien des Representational State Transfer, womit es sich bei CouchDB wohl um die am besten ans Web angepasste Datenbank handeln dürfte (Tiwari 2011). RESTful bedeutet, dass CouchDB alle REST Operationen (GET/HEAD, PUT, 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 immer zum gleichen Ausgang führt. So kann verhindert werden, dass die gleiche Operation unwillentlich zu doppelten Dokumenten führt (Fielding 1999). Datenbank und Dokumente stellen die Ressourcen dar, auf die die Operationen angewandt werden können. Sie besitzen eine eindeutig zu identifizierende Uniform Ressource Identifier (URI). Außerdem setzt CouchDB eine zustandslose Anfrage durch den Client voraus. Jede Anfrage muss also alle Informationen zur Abarbeitung enthalten und kann nicht auf Kontextinformationen in der Datenbank vertrauen. Die Integration in Web Services ist so besonders einfach (Fielding 2000 und Edlich 2011: 51ff.).

18 2 Allgemeiner Überblick 15 Neben der Funktion als Dokumentdatenbank integriert CouchDB so einen vollwertigen HTTP-Server, deren Ressourcen per HTTP-REST- API aufrufbar sind. Dazu gehört auch eine Administrationskonsole, die per Browser aufgerufen werden kann und über die, neben der Verwaltung von Datenbanken und Dokumenten auch Konfigurationen vorgenommen und Zugriffsrechte geregelt werden können. In der Arbeit Roy Fieldings ist die Zustandslosigkeit der Ressourcen des 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 auszulesen, andererseits kann die Ressource auch in verschiedensten Ausprägungen dargestellt werden. Diesem Konzept folgt auch CouchDB und implementiert bestimmte Sonderdokumente, die durch einen führenden Unterstrich auszumachen sind. Das wichtigste Dokument stellt dabei _design dar. Hier lassen sich neben anderen folgende Funktionen als JSON-Objekte definieren: Views Lists Validierungsfunktionen (Scheliga 2010) Views stellen dabei die Abfragemöglichkeit auf CouchDB-Dokumente dar, welche per Map- und Reduce-Funktionen in JavaScript formuliert wird. Der Grundgedanke ist dabei analog zu dem des MapReduce-Verfahrens, welches in 2.6 beschrieben ist. Es werden also alle Datensätze der Datenbank durchlaufen und geprüft. Die Antwortmenge wird anschließend indexiert und ist unter der URI des Views verfügbar. List- Funktionen dienen als Render-Funktionen für Views (ebd.: 140) und verarbeiten die Ergebnismenge eines Views weiter (ebd.). Sie eignen sich beispielsweise zum Umformen des JSON-Objekts in ein anderes Format. Über die Validierungsfunktion lassen sich die Benutzerrechte für verschiedene Nutzergruppen steuern (ebd.: 149f.). CouchDB setzt statt auf pessimistische Transaktionierung auf die Versionierung von Schreibzugriffen durch Multi Version Concurrency Control (MVCC). Das heißt, dass mehrere unveränderliche Versionen eines Datensatzes (Edlich 2011:41) vorgehalten werden. Jeder Schreibzugriff erstellt eine neue Version die eine eindeutig identifizierbare Revisionsnummer trägt. Treffen konkurrierende Schreibzugriffe auf einem Datensatz zusammen, wird durch vergleichen der Revisionsnummern bestimmt, ob die Schreiboperation zu diesem Zeitpunkt zulässig war. Im Konfliktfall muss diese optimistische Transaktion zurückgerollt und unter Umständen von vorn begonnen werden. (ebd.) Spatial Extensions Für CouchDB steht die Spatial Extension GeoCouch zur Verfügung. Sie wird durch den Couchbase-Entwickler Volker Mische koordiniert und gepflegt. Im Februar 2012 war

19 2 Allgemeiner Überblick 16 ausschließlich eine Bounding Box Abfrage auf geometrische Objekte möglich, welche sich auf den zweiten Entwurf der OpenSearch-Spezifikation für Geodaten stützt. Nach eigenen Aussagen sollen zukünftige Implementierungen ebenfalls diesen Standard bedienen (s. Anhang 1). Für die Strukturierung der Daten bietet sich die GeoJSON-Spezifikation an, die mit dem 16. Juni 2008 in die Version 1.0 überführt wurde. Es handelt sich dabei um ein Schnittstellenformat für geographische Datenstrukturen, das ebenfalls auf der JavaScript Object Notation beruht. Die geometrischen Objekte der Spezifikation orientieren sich an der Simple Feature Specification und umfassen neben simpler Geometrie auch die Definition eines FeatureObject und einer FeatureCollection. Außerdem ist es möglich, direkt oder indirekt ein CRS, bevorzugt notiert nach den Empfehlungen für OGC Universal Ressource Names für Koordinatenreferenzsysteme, als Attribut zu definieren (Butler 2008). { "type": "MultiLineString", "coordinates": [ [ [100.0, 0.0], [101.0, 1.0] ], [ [102.0, 2.0], [103.0, 3.0] ] ] } Abbildung 7: Beispiel eines GeoJSON GeometryObjects des Typs MultiLineString. Durch die Aufnahme von GeoJSON und CouchDB als Schnittstellenformate in die Geospatial Data Abstraction Library (GDAL) bzw. in die Sub-Bibliothek OGR Simple Features Library der OGC ab Version 1.9 aufwärts, können alle durch die Simple Feature Specification definierten Geometrien in CouchDB importiert und durch GeoCouch indexiert werden (GDAL 2011). Neben CouchDB bietet auch der Document Store MongoDB, entwickelt durch die Firma 10gen, eine native räumliche Indexierung, welche allerdings auf die Abfrage von Punktgeometrie beschränkt ist (10gen 2011). Trotz dieser Einschränkungen listet 10gen auf seiner Website mindestens zwölf Anbieter die MongoDB primär für webbasierende Geolocation Services nutzen, darunter auch FourSquare mit nach eigenen Aussagen 15 Millionen Nutzern im Dezember 2011 (Heine 2011). 2.5 Graphdatenbanken Die letzte hier vorgestellte Gruppe der NoSQL-Datenbanken unterscheidet sich deutlich von den vorherigen. Während Key/Value Stores, Wide Column Stores und Document Stores unstrukturierte Datensätze speichern und diese für Suchanfragen zur Verfügung stellen, beschreibt eine Graphdatenbank die Art und Weise der Verknüpfungen dieser Datensätze untereinander (Edlich 2011: 207). Das Grundkonzept der Graphdatenbanken basiert auf der Graphentheorie der Mathematik, welche das

20 2 Allgemeiner Überblick 17 allgemeine Graphenmodell bestehend aus einer Knoten- und einer Kantenmenge definiert. Eine Kante stellt eine Beziehung zwischen zwei Knoten dar und kann sowohl gerichtet als auch ungerichtet sein (Edlich 2011: 209f.). Abbildung 8: Einfacher Graph bestehend aus drei Knoten und ungerichteten Kanten. Auch im Hinblick auf das Schlagwort Semantic Web spielen Graphdatenbanken eine bedeutende Rolle. Um den Datenaustausch im Web zu standardisieren, baut man hier auf das Ressource Description Framework (RDF), das das Konzept des einfachen Verlinkens von Informationen per URI zu einer benannten Kante mit Anfangs- und Endpunkt ausbaut. Das resultierende Triple entspricht einem gerichteten und benannten Graphen (RDF Working Group 2012). Graphdatenbanken, die zu diesem Zweck die Abfragesprache SPARQL implementieren, werden gemeinhin als RDF- Stores bezeichnet und können als Untermenge der Graphdatenbanken angesehen werden (Edlich 2011: 228) 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.).

21 2 Allgemeiner Überblick 18 Abbildung 9: Gewichteter Property Graph zwischen Personen und Programmen (Rodriguez 2012a). Gegenüber den relationalen Datenbanken ergeben sich einige Parallelen. Während alle anderen hier vorgestellten NoSQL-Vertreter keine Beziehungen zwischen den Datensätzen modellieren, gehört dies zur natürlichen Struktur eines Graphen. Auch in einer relationalen Datenbank lassen sich diese Vernetzungen abbilden. Während es bei einer SQL-Datenbank mit einigem Aufwand verbunden sein kann, die einzelnen Tabellen per (rekursivem) JOIN zu durchlaufen, um komplexe Beziehungen herzustellen, gestaltet sich die Traversierung eines Graphen schon bedeutend intuitiver (Edlich 2011: 225f.). Aufgrund der Komplexität des Datenmodells, müssen ähnlich wie bei den 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).

22 2 Allgemeiner Überblick 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 Spatial Extensions Aus der Graphentheorie geht hervor, dass Topologie gut durch Graphen modelliert werden kann. Ändern sich nämlich in einem solchen Graphen die Koordinaten, also eine metrische Eigenschaft eines Knotens, so ist die Topologie davon nicht betroffen. Im Grunde lässt sich schon mit den Bordmitteln einer Graphdatenbank komplexe Topologie einpflegen. Darüber hinaus bietet Neo4j die Spatial Extension Neo4j Spatial. Dieser steht bisher lediglich als Development Version zur Verfügung, kann aber in seinem tagesaktuellen Stand vom öffentlichen Git-Repository geladen werden (Neo

23 2 Allgemeiner Überblick 20 Technology 2012a). Neo4j Spatial stellt auf Grundlage des GeoTools GIS Toolkits der Open Source Geospatial Foundation (OSGeo) für die Graphdatenbank optimierte GIS Funktionalität bereit die als Java-Bibliothek in Projekte eingebunden werden kann. Außerdem steht eine Erweiterung für die Neo4j Server Variante zur Verfügung, die Abfragen auf Geodaten per REST-Schnittstelle erlaubt. Durch den Aufbau auf das GeoTools Framework ist es möglich, Neo4j als Datenhaltungskomponente für OpenGIS-Produkte zu nutzen. Interessant ist dies speziell für GeoServer, dem es damit möglich ist WFS und WMS auf Grundlage der Graphdatenbank bereitzustellen. Darüber hinaus implementiert die Erweiterung die WKT bzw. OSM und ESRI Shapefiles Encoder zum Im- und Export von Daten. Neo4j Spatial kann mit allen Geometrietypen umgehen, die durch die OGC Simple Feature Specification definiert sind und bietet weitreichende Operationen auf die Geometrien, die durch die Spezifikation vorgegeben sind.

24 3 Anwendungspotential für Geodaten 21 3 Anwendungspotential für Geodaten In summary, one can leverage at least the following ideas to get superior performance: A non-relational data model. If the user s data is naturally something other than tables and if simulating his natural data model on top of tables is awkward, then chances are that a native implementation of the natural data model will significantly outperform a conventional RDBMS. (Stonebraker 2009). Das obige Zitat einer der Gallionsfiguren der relationalen Datenbanken, Michael Stonebraker, hat mit seinem Erscheinen für einige Aufmerksamkeit gesorgt. Mittlerweile steht Stonebraker eher für eine defensive Haltung gegenüber der NoSQL-Bewegung und kritisiert die vollkommene Abkehr von bewährten Konzepten. Nichtsdestotrotz spricht er einen Punkt an, der gerade auch für Geodaten diskutiert werden muss. Die Haltung von Geodaten in Tabellen ist nicht intuitiv oder natürlich und erfordert weitreichende Kenntnisse zur Strukturierung der Daten. Dieses Kapitel soll zeigen, ob sich in den NoSQL-Datenbanksystemen Alternativen dazu finden lassen. 3.1 Definition Geodaten Um die Komplexität von Geodaten selbst zu erfassen, ist es hilfreich eine genaue Definition zu betrachten. Ralf Bill gibt dafür folgenden Vorschlag: Geodaten sind Daten über Gegenstände, Geländeformen und Infrastrukturen an der Erdoberfläche, wobei als wesentliches Element ein Raumbezug vorliegen muss. [ ] Geodaten lassen sich über den Raumbezug miteinander verknüpfen, woraus insbesondere unter Nutzung von GIS-Funktionalitäten wiederum neue Informationen abgeleitet werden können [ ] (Bill 1999: 167). Besonders im Zusammenhang mit Datenbanken spricht man auch von Geoobjekten - elementaren oder auch zusammengesetzten Einheiten mit sowohl quantitativen (geometrischen und topologischen) als auch qualitativen (thematischen) Komponenten. Ein Objekt ist dabei eine konkrete, physisch, geometrisch oder begrifflich begrenzte Einheit der Natur und besitzt eine individuelle Identität. (ebd.: 10f.) Die Geometrie eines Objekts kann dabei sowohl in Vektor- als auch Rasterdarstellung vorliegen, ihr Raumbezug indirekt oder direkt hergestellt sein. (ebd.: 11) Durch die weitreichende Definition von Geodaten unterscheidet sich auch die Komplexität der unter Geodaten verstanden Informationen. Insbesondere Geoobjekte in Vektordarstellung stellen eine Herrausforderung für die Wahl eines passenden Datenmodells dar. Das verbreitetste ist dabei das (objekt-)relationale Datenmodell.

25 3 Anwendungspotential für Geodaten Die Haltung von Geodaten in SQL-Datenbanken Für die Verwaltung von Geodaten in einer relationalen Datenbank bestehen zwei grundlegende Lösungen. Zum einen ist eine Speicherung der Geometrie in der unstrukturierten Form eines Binary Large Objects (BLOB) möglich, zum anderen kann sie strukturiert unter Nutzung der numerischen Datentypen, die durch die Datenbank angeboten werden gespeichert werden. Beide Methoden haben dabei Vor- und Nachteile: Die Speicherung als BLOB ist zwar einfach, der Zugriff muss aber in diesem Fall über eine externe Anwendung sichergestellt werden und kann nur über eine eigene API erfolgen. Es handelt sich um solche Anwendungsdaten, die vom Datenbanksystem gar nicht interpretiert, sondern nur gespeichert bzw. archiviert werden sollen (Kemper 2011: 421). Außerdem muss die Sicherung der Konsistenten zwischen der Geometrie und den Sachdaten geregelt sein. Die Speicherung der Geometrie in strukturierter Form stellt die zweite Möglichkeit dar, bei der Topologie und Metrik mittels Normalisierung in Tabellenform abgebildet wird. Durch einen hohen Grad an Normalisierung ist es möglich Anomalien im Datenbestand Größtenteils vorzubeugen (ebd.: 179f.). Ein Nachteil ist jedoch, dass das Datenmodell damit sehr umfangreich wird und das Antwortverhalten auf komplexe räumliche Abfragen nicht optimal ist (Bill 1999: 318). Möchte man Geodaten in einer relationalen Datenbank in Abfragen zusätzlich mit Sachdaten verknüpfen führt dies je nach Anwendungsfall zu komplizierten Statements. Mit dem zunehmenden Erfolg objektorientierter Programmiersprachen haben Konzepte der Objektorientierung auch Einzug in die relationalen Datenbanken gehalten. Durch Typendeklaration und die Möglichkeit, Operationen auf diese Typen zu definieren, ergaben sich damit auch für die Geodatenhaltung Vorteile, die in objektrelationelen und objektorientierten Datenbanken umgesetzt werden konnten. Als Standard hat sich in der GIS-Welt seit dem die OGC Simple Features Specification for SQL durchgesetzt welche von den verbreiteten Geodatenbanken wie Oracle Spatial oder PostGIS umgesetzt wird. Zunehmend wird dieses um Bestandteile des bedeutend umfangreicheren konzeptuellen Schema ISO 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.

26 3 Anwendungspotential für Geodaten 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 Komplexität des Datenmodells der NoSQL-Datenbanken beginnend bei den Key/Value und Wide Column Stores, über die Document Stores und schließlich bis hin zu den Graphdatenbanken zunimmt. Daraus ergibt sich eine Wechselwirkung mit der Skalierbarkeit der Datenbank. Da Key/Value Stores und Wide Column Stores auf ein einfaches Datenmodell bauen, in denen die Datensätze keine bzw. geringe Beziehungen zueinander haben, ist es besser möglich, die Daten horizontal zu Partitionieren und auf mehrere Datenbankserver auszubreiten. Wie auch bei den SQL-Datenbanken ist dies beispielsweise für Graphdatenbanken schwieriger, da engere Verknüpfungen zwischen den Daten bestehen (Eifrem 2009). Um Leseleistung zu erhöhen, bietet sich hier eher eine Replikation auf mehrere Server an, womit jedoch die Größe der Datenbank auf die Größe des kleinsten Servers beschränkt bleibt. Abbildung 11: Die Komplexität des untersetzten Datenmodells der NoSQL-Datenbanken unterscheidet sich stark und steht in Wechselbeziehung mit der zu erwartenden Skalierbarkeit. (veranschaulichende Darstellung aus der Präsentation Emil Eifrems. (Eifrem 2009) Es muss allerding betont werden, dass diese Überlegungen in vielerlei Hinsicht theoretischer Natur sind, da die Anforderungen sehr hoch sein müssen, um die Kapazität eines Servers zu überschreiten (Edlich 2011: 377). Außerdem verschiebt ein einfaches

27 3 Anwendungspotential für Geodaten 24 Datenmodell die Komplexität eine Stufe höher in die Anwendungsebene und erschwert so die Implementierung. Dementsprechend sollte die Wahl der richtigen Datenbank nach dem Zweck ihrer Anwendung erfolgen. (Eifrem 2009). Dies gilt insbesondere auch für die Verwaltung von Geodaten, denn der Nutzen, der aus Geodaten gezogen werden soll, ist jeweils sehr unterschiedlich. Wenn Web Services wie FourSquare oder Twitter Positionsdaten speichern und diese mit Beiträgen und Fotos koppeln, dann dient dies in erster Linie zur reinen Präsentation des Ortes. Die weitreichendste Analyse, die auf diese Daten angewandt wird, ist eine einfache Umkreissuche. Die Fragestellung Wer hält sich in meiner Umgebung auf? oder Wo wurde dieses Foto aufgenommen? ist dabei keine zeitkritische, die immer korrekt beantwortet werden muss. Viel wichtiger ist es für einen solchen Dienstleister, alle zur Verfügung gestellten Informationen zu speichern und dabei auch zu Spitzenzugriffszeiten eine angenehme Nutzererfahrung zu gewährleisten. Die quantitative Komponente des Geoobjekts Position beschränkt sich in diesem Fall lediglich auf Punkte auf der Erde von denen anzunehmen ist, dass sie immer im gleichen Referenzsystem vorliegen werden, also keine weitere Informationen gesammelt werden muss. In vielen Fällen ist die Positionsangabe auch nur optional und stellt so nur ein weiteres Attribut der eigentlichen Informationseinheit Statusmitteilung dar. Die Struktur der Daten ist hier also wenig komplex. Soll die Datenbank hingegen als Datenhaltungskomponente eines wertigen Geoinformationssystems eingesetzt werden, stellen sich andere Anforderungen, denn allgemein haben Geodaten eine viel komplexere Struktur. Außerdem ist hier der Anspruch an standardisierte Schnittstellen viel größer. Es soll gezeigt werden, wie diesen Ansprüchen gerecht zu werden ist. Dazu wird im Folgenden in drei Ausprägungen von raumbezogenen Objekten unterschieden. Zum einen ist unter Positionsdaten eine Basisklasse von Objekten gemeint, dessen Geometrie lediglich aus einem Punkt besteht. Im speziellen bezieht sich dies auf eine Position, analog der Definition einer direkten Position in der Simple Feature Specification (OGC 2011: 9). Des Weiteren sollen komplexe Geodaten raumbezogene Daten nach dem Vektormodell beschreiben. Dies sind Daten, die im eigentlichen Sinne komplexe, auf punkt- und linienhaften Beschreibungen beruhende Datenstrukturen (Bill 1999: 21) darstellen. Abschließend sollen Geodaten in einer Rasterdarstellung gesondert betrachtet werden. 3.4 Positionsdaten in NoSQL-Datenbanksystemen Lässt man in einem Vektormodell lediglich Punkte, also die Träger der geometrischen Information, zu, beschränkt also die topologische Dimension auf 0-Zellen (Nullzellen), so liegen in diesem Modell keine topologischen Beziehungen zwischen Objekten vor.

28 3 Anwendungspotential für Geodaten 25 Die Kante, als Träger der topologischen Information, fehlt (Bill 1999: 15,18). Nach Ralf Bill kann erst die Vereinigung von metrischen und topologischen Daten [ ] zu [ ] umfassenden räumlichen Datenmodellen führen, die in der Lage sind, auf einen breitgefächerten Abfrageraum zu antworten (edb.: 255). Das im vorherigen Kapitel gezeigte Beispiel zur Anwendung in Web Services hat aber gezeigt, dass solch ein breitgefächerter Abfrageraum nicht unbedingt nötig ist, um Anforderungen bestimmter Anwendungen zu befriedigen. Ist ein Modell ausschließlich bestehend aus Punktobjekten ausreichend, so erleichtert dies die Organisation in einer Datenbank enorm. Es handelt sich im Grunde genommen um ungeordnete raumbezogene Daten ohne die logische Zuordnung der Nachbarschaft wie sie durch Ralf Bill beschrieben sind (edb.: 241). Zu beachten ist, dass sich die Beschreibung für ungeordneten raumbezogene Daten eigentlich auf Geometrieinformationen aus verschiedenen Quellen, wie beispielsweise Koordinatenlisten, bezieht. Deren Attribute bzw. Sachdaten könnten in unterschiedlicher Ausdehnung vorliegen. Dies ist durchaus ein Fall, der für dynamische Webanwendungen eine Rolle spielen kann, beispielsweise um in einem neuen Konzept auch Bilder mit einer Georeferenz zu versehen. Sollen diese Daten in eine objektrelationale Geodatenbank geführt werden, so muss diese Ausdehnung der Attribute durch Normierung in eine einheitliche Dimension bzgl. der Tabellengröße gebracht werden. (edb.: 241f.) Dabei bestehen zwei grundlegende Probleme, die bereits in Kapitel 1.7 angesprochen wurden: Neue Attribute machen eine Schemaänderung der Relationen nötig, können aber zu vielen leeren Zellen im Datenbestand führen. Referenzierungen führen zu mehr Relationen und erschweren die Abfrage. Hier kann sich also ein Vorteil ergeben, wenn von Seiten der Datenbank kein Schema für die Struktur der Daten vorrausgesetzt wird. In jener Hinsicht kommen 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,

29 3 Anwendungspotential für Geodaten 26 indem Längen- und Breitengrad immer durch die Zahl 2 geteilt und so sukzessive einem Binärcode zugewiesen werden. Die Besonderheit des entstehenden Hashcodes ist dabei, dass die Auflösung der Quadranten durch die Anzahl der Stellen des Hashwerts beeinflusst werden kann und dass nah beeinander liegende Punkte meist den gleichen Prefix tragen. Wird die hinterste Stelle des Hashs gestrichen, vergrößert sich so der durch den Wert dargestellte Quadrant (edb.). Der Geohash-Index ist bei einer Umkreissuche in den Grenzbereichen eines Quadranten nicht schlüssig. Es kann also nicht immer angenommen werden, dass die ersten Stellen zwei sich nahe liegender Punkte den gleichen Prefix teilen. Dieses Problem kann allerdings weitestgehend ausgeglichen werden, indem die acht umliegenden Quadranten ebenfalls für den Test genutzt werden. MongoDB nutzt dieses Prinzip sehr erfolgreich und konnte in der Vergangenheit viele Kunden gewinnen, die die Datenbank für Geolocation Services einsetzen. Abbildung 12: Visualisierung der "Geohash Quadranten". (Troy 2008) 3.5 Komplexe Geodaten in NoSQL-Datenbanksystemen Unter komplexen Geodaten sollen hier räumliche Objekte verstanden werden, deren Geometrie in Vektordaten beschrieben ist. Ihre Grundelemente sind der Punkt, die Linie und die Fläche [ ] (Bill 1999: 21), wobei die graphische Grundstruktur aus Punkten und Linien besteht durch welche Flächen als geschlossener Linienzug darge-

30 3 Anwendungspotential für Geodaten 27 stellt werden (ebd.). Ohne die im vorherigen Kapitel vorgestellten Beschränkungen besteht die Geometrie von raumbezogenen Objekten nicht nur aus der metrischen Information des Punktes, sondern ist um topologische Beziehungen zwischen den Punkten bereichert. Die Haltung von solch komplexen raumbezogenen Daten in Datenbanken ist bekanntermaßen nicht trivial. Diese Aufgabe wird allgemein zu den Nichtstandardanwendungen (NSA) von Datenbankmanagementsystemen (DBMS) gezählt (Bill 1999: 327). Die Nichtstandardanwendung für Geodaten hat dabei unter anderem die folgenden Charakteristiken: Die Daten sind typischerweise mehrdimensional und sollen durch räumliche Bereichsabfragen aufrufbar sein. Die Geometrien der Objekte können dabei aus einer Vielzahl logischer Verknüpfungen bestehen, sie besitzen eine komplexe Struktur. Außerdem werden für die Analyse raumbezogener Daten komplexer Operationen vorrausgesetzt. Aufgrund der Struktur und Größe der Objekte können Operationen auf raumbezogene Daten deshalb zu langen Transaktionen führen (ebd.: 330). Um eine grobe Einschätzung treffen zu können, inwiefern diesen Anforderungen entsprochen werden kann, ist es hilfreich, einen kurzen Vergleich anzustellen. Mehrdimensionalität: Das offensichtlichste Problem, das für Geodaten geklärt werden muss, ist die Indexierung des multidimensionalen Raums. Die bereichsbezogene Abfrage stellt hier mehr die Regel als die Ausnahme dar, also sollte die Indexierung mindestens in X- und Y-Richtung möglich sein (Bill 1999: 330). Dieses Kriterium beschränkt die Anzahl der Vertreter der NoSQL-Datenbanken auf sehr wenige die entsprechende Erweiterungen anbieten. In der hier getroffenen Auswahl bieten nur CouchDB mit den Spatial Extensions GeoCouch und Neo4j Spatial einen mehrdimensionalen Index, der räumliche Abfragen über ihre API ermöglicht. Alternativ können auch eigene Zugriffsmechanismen für die Datenbank der Wahl konstruiert werden, allerdings ist dies auch mit einem gehörigem Mehraufwand für die Umsetzung verbunden. Komplexe Strukturen: Der Umsetzung einer Vielzahl logischer Verknüpfungen von Geodaten steht außerdem das zugrundeliegende Datenmodell der meisten 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

31 3 Anwendungspotential für Geodaten 28 worden sind. Wieder ist es die der Datenbank übergeordnete Ebene, die diese Daten interpretieren muss. Wie bereits durch Emil Eifrem festgestellt, verlagert sich die Komplexität damit in die Anwendungsebene (Eifrem 2009). Es gilt die Entscheidung zu treffen, ob die damit verbundenen Nachteile für die jeweilige Anwendung Sinn machen. Die Nutzung des MapReduce-Paradigmas für exzessiv große Datenmengen kann beispielsweise von Interesse sein und so die Nachteile aufwiegen. Document Stores bieten hingegen die Möglichkeit, Daten denormalisiert in einem Dokument abzulegen. Das macht die Datenverwaltung übersichtlicher und durch die Implementierung des MapReduce-Paradigmas können diese effektiv auf Sachdaten durchsucht werden. Graphdatenbanken beiten die weitreichste Möglichkeit Daten logisch zu Verknüpfen und können durch Traversierungsalgorithmik auftrumpfen. Das macht sie für komplexe Strukturen interessant. Komplexe Operationen: Neben den einfachen den CRUD-Operationen (Create, Read, Update, Delete) versteht man unter komplexen Operationen für Geodaten bespielsweise das Verschneiden, die Ein- und Ausschlussberechnung oder das Clipping von raumbezogenen Objekten (Bill 1999: 330). Nach der Definition der NoSQL-Datenbank bieten diese aber ganz bewusst nur eine sehr einfache API an, um so den Zugang für die Programmierung zu erleichtern (Edlich 2011: 2). Auf Grundlage dieser APIs kann es möglich sein, Operationen auf die in der Datenhaltungskomponente abgelegten Objekte zu implementieren, aber auch das ist mit dem nötigen Aufwand verbunden. Die Spatial Extension Neo4j Spatial bietet hier weitreichende Funktionalität, um raumbezogene Analysen durchzuführen und kann diesen Punkt als einzige bedienen. Lange Transaktionen: Das Thema der langen Transaktionen spielt auch für 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.

32 3 Anwendungspotential für Geodaten 29 Tabelle 1: Eigenschaften von NoSQL-Datenbanken in Relation zu Charakteristiken von Nichtstandardanwendungen. Mehrdimensionaler Index Bereichsabfragen Vielfache logische Verknüpfung Komplexe Operationen Key/Value Store Redis (VMWare 2011b und 2011d) Wide Column Store Cassandra Document Store CouchDB mit GeoCouch (Katz und Mische 2012) Nein Nein Ja Ja Nur in Listen & Sets Nein, binärsichere Speicherung von Objekten Ja, Columns und Column Families sortiert Nein, einfache Strukturierung und binärsichere Speicherung von Objekten Ja Nein, schemafreie Dokumente Nein Nein Nein Ja Graphdatenbank Neo4j mit Neo4j Spatial (NeoTechnology 2012 und Edlich 2011: 291) Ja Ja, durch Traversierung 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.

33 3 Anwendungspotential für Geodaten 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 Aufbereitung wird nach eigner Aussage in Google BigTable verwirklicht ist die Tabellengröße allein mit 70 Terrabyte angegeben. Während allein das Speichern einer solchen Datenmenge auf einem Rechner unmöglich ist, sind Berechnungen auf eine solch enorme Menge von Daten nur durch massive Parallelisierung möglich. Um die Satellitenbilder letztendlich für die Darstellung im Browser oder der Clientanwendung Google Earth aufzubereiten, wird das MapReduce Framework eingesetzt, welches die Daten bereinigt und letztendlich in geographische Segmente teilt. Eine weitere, bedeutend kleinere Tabelle von 500GB hält außerdem die Indexierung des Bildmaterials im verteilten Dateisystem GFS vor und dient zur Interaktion mit dem Nutzer. Allein diese Tabelle ist über hunderte von Server gehostet, um zehntausende Anfragen pro Sekunde zu befriedigen (Chang 2006: 10f.). Während die Haltung von solchen Datenmengen eher die Ausnahme ist, verdeutlicht Google damit aber das enorme Leistungspotential das von verteilten Systemen ausgeht. 3.7 Zukünftige Entwicklungen Neben der eigentlichen Datenhaltung spielt gerade auch die Interoperabilität von georeferenzierten Daten zwischen verschiedenen Systemen eine wichtige Rolle und stellt ein altes Problem dar (de Souza Baptista 2011). Durch die Entwicklung der NoSQL- Datenbanken ist denkbar, dass etwa CouchDB, Neo4j oder MongoDB zu einer heterogeneren Landschaft im Umfeld der Geoinformation führen können. Darüber hinaus ist es auch für die Nutzer klassischer SQL-Geodatenbanken interessant, Informationen aus dem Umfeld der Social Networks in Analysen einzubeziehen, denn hier hat NoSQL bereits viel Anwendung gefunden. Es wird also in Zukunft unumgänglich sein, sich um

34 3 Anwendungspotential für Geodaten 31 Schnittstellen zwischen den Welten zu bemühen, um so den Informationsfluss zu fördern. Der wohl überzeugendste Weg, ist es auf bereits bestehende Standards zurückzugreifen. Neben dem Im- und Export über bekannte Formate, ist die Implementierung von Web Services wie dem OGC Web Map Service (WMS) und dem Web Feature Service (WFS) die lohnenswerteste, da so jeder Client mit Unterstützung dieser Services Zugriff auf die Daten erhalten kann. Cláudio de Souza Baptista et al. haben mit dieser Begründung einen ersten erfolgreichen Vorschlag geleistet, wie eine solche Schnittstelle für GeoCouch aussehen kann. Sie nutzten den modularen Aufbau CouchDBs, um einen Service Layer für die NoSQL-Datenbank zu integrieren. Nicht zuletzt zeigt auch die Integration des CouchDB-Treibers in die GDAL-Bibliothek ab Version 1.9 (GDAL 2011), dass gerade von Seiten der OpenGIS-Bewegung reges Interesse an solchen Speziallösungen bestehen muss. GDAL dient vielen 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.

35 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 dabei: Geodaten in CouchDB einlesen Mit der Erweiterung GeoCouch vertraut machen und einen Abfragemechanismus definieren Webseite über CouchDB hosten Datengrundlage sollen dabei öffentlich verfügbare Geodaten sein, wie sie von öffentlichen Trägern angeboten werden. Dies umfasst insbesondere Informationen zu Landespflege und Naturschutz, wie sie beispielsweise auch in den Beständen des Landes Brandenburg zu finden sind. Sie können unter der Website (Lukas 2012) abgerufen werden und sollen in diesem Entwurf als Datengrundlage für eine digitale Übersichtskarte dienen, die es Interessierten ermöglicht, sich über Naturschutz im Land Brandenburg zu erkundigen. Zur Umsetzung kommt CouchBase Single Server Version 1.2 als vorkompiliertes Packet aus CouchDB und GeoCouch zum Einsatz. Außerdem findet die Folgende Software Anwendung: GDAL Library 1.9 jquery Leaflet.js 0.3.1

36 4 Implementierung einer Webpräsenz für Geodaten mit CouchDB und GeoCouch Vorbereitung der Daten für CouchDB Wie bereits in Kapitel vorgestellt, erwartet CouchDB Daten im JSON-Format. Die vom Brandenburger Ministerium bereitgestellten Daten liegen allerdings als Shapefiles vor und müssen zunächst entsprechend umgewandelt werden. Außerdem ist es sinnvoll, vom durch das Land Brandenburg genutzten Koordinatenreferenzsystem ETRS89 BB in WGS84 zu transformieren. Dies erleichtert später die Integration in bestehende Mapping-Frameworks, ist aber ein optionaler Schritt. Beide Operationen sind mit dem durch die Open Source Geospatial Foundation (OSGEO) beförderten Framework GDAL (Geospatial Data Abstraction Library) bzw. der enthaltenen Sub-Library OGR möglich. Mit Version 1.9 wurde die OGR Simple Feature Library um eine Schnittstelle für CouchDB erweitert, die die bereits bestehende GeoJSON Unterstützung nutzt, um Geodaten so per HTTP-PUT auf eine CouchDB zu übertragen. Die Transformation mit dem Konsolentool OGR2OGR sieht dabei folgendermaßen aus: $ ogr2ogr -t_srs EPSG:4326 output_4326.shp input.shp Beim Übertragen der Daten auf eine CouchDB-Instanz kann außerdem ein Admin- Zugang spezifiziert werden: $ ogr2ogr -f couchdb "couchdb: output_4326.shp OGR2OGR legt pro Feature je ein JSON-Dokument in die Datenbank, welches die Geometrie als GeoJSON-Objekt enthält. Im Beispiel wird dieses Dokument in die Datenbank output_4326 hinterlegt. Bestehende Attribute und Metadaten werden im JSON-Objekt properties abgelegt, wodurch das Dokument nun über die URI verfügbar ist. Mit dem erstmaligen Speichern des JSON-Dokuments wird durch CouchDB ebenfalls eine Revisionsnummer _rev angelegt, die für die MVCC-Versionierung genutzt wird.

37 4 Implementierung einer Webpräsenz für Geodaten mit CouchDB und GeoCouch 34 { } "_id": " ", "_rev": "1-57b1dffc6a3c47d428252db519fad50f", "type": "Feature", "properties": { "AST NR": " ", "NAME": "Global Wind Power A/S", "ANL NR": "4016", "BEZEICHNUN": "WKA NEG Micon NM 82/1500", [ ] "ROTORDURCH": "82", "NABENHOEHE": "108" }, "geometry": { "type": "Point", "coordinates": [ , ] } 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: 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 filtern und die Ergebnismenge als Ressource des HTTP-Servers abzufragen. function(doc) { if(doc.properties) { emit(doc.properties.bezeichnun, doc.properties.leistung) } } Abbildung 14: Eine einfache Map-Funktion. Sie durchläuft jedes Dokument der Datenbank, testet, ob das JSON-Objekt properties vorhanden ist und emittiert das Attribut BEZEICHNUN als Key bzw. LEISTUNG als Value. Über eine optionale Reduce-Funktion ließe sich das Ergebnis der Map-Funktion aggregieren.

38 4 Implementierung einer Webpräsenz für Geodaten mit CouchDB und GeoCouch 35 Die Ergebnismenge einer MapReduce-Funktion wird durch CouchDB mit der ersten Abfrage indexiert. Später hinzugefügte Datensätze werden mit jeder weiteren Abfrage sukzessive im Index eingepflegt. function(doc) { if(doc.geometry) { emit(doc.geometry, doc.properties); } } Abbildung 15: Geometrie emittierende Map-Funktion. Sofern vorhanden, wird das (GeoJSON) Objekt "geometry" als Schlüssel emittiert. Die Eigenschaften properties schließen als Values der Ausgabeliste an. Diese Map-Funktion allein unterstützt noch keine räumlichen Suchanfragen. Würde sie in einem Designdokument einfach als View gespeichert werden, wäre mit dem ersten Abrufen ein B-Tree-Index angelegt, wie er auch für jeden anderen eindimensionalen View eingesetzt wird. Die Spatial Extension GeoCouch erweitert hier die Indexierungsfähigkeiten um einen R-Tree-Index. Um diesen zu nutzen, wird die Mapping-Funktion im Designdokument unter dem Attribut spatial gespeichert. { } "_id": "_design/technik", "_rev": "1-b d68d3a7ab145623fc18a9", "spatial": { "pos": "function(doc) { if (doc.geometry){ emit(doc.geometry, doc.properties); } }" } Abbildung 16: Design-Dokument. Das Dokument "technik" umfasst nur den Spatial-View "pos". Um anschließend eine räumliche Abfrage durchzuführen, wird die URI, welche auf das definierte Design-Dokument zeigt, um den Parameter _spatial, den Namen des Spatial Views sowie die gesuchte Bounding Box ergänzt. Eine räumliche Abfrage der enthaltenen Features im umschließenden Rechteck mit den Koordinaten [(52,13 ), (53,14 )] auf das Designdokument technik und dessen Spatial-View pos würde wie folgt lauten: 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

39 4 Implementierung einer Webpräsenz für Geodaten mit CouchDB und GeoCouch 36 Konstruktion des umschließenden Rechtecks in der Form minx, miny, maxx, maxy voraus. Achtung muss hier beim Überspannen der Datumsgrenzen geboten sein. In der aktuellen Version von GeoCouch für CouchDB 1.2.x steht die Bounding Box Suche als einzige räumliche Funktion zur Verfügung. Die nachfolgende Antwort der CouchDB-Instanz entspricht einem JSON-Dokument, das die ermittelten Datensätze im Objekt rows als Array von JSON Objekten enthält: { } "update_seq":3475, "rows":[{ "id":" ", "geometry":{ "type":"point", "coordinates":[ , ] }, "value":{ "AST NR":" ", "NAME":"Phase 5 GmbH & Co Lindenberg 4 KG", "ANL NR":"0001", [ ] "GEN_NIB":"ja", "GEPLANT":null, "ROTORDURCH":"92", "NABENHOEHE":"100" }}, [ ] ] Abbildung 17: Antwortdokument eines Bounding Box Querys. (Gekürzt) 4.3 Abfrage von Datensätzen als FeatureCollection Bei dem im HTTP-Body erhaltenen JSON-Dokument einer CouchDB-Abfrage handelt es sich nicht um ein GeoJSON-Objekt, sondern um ein valides JSON. Das heißt, dass die gewonnen Datensätze in dieser Form nicht weiter für Mapping-Aufgaben genutzt werden können, ohne dass GeoJSON-Objekt ( geometry ) zu extrahieren und die gewünschten Attribute mit anzuführen. CouchDB bietet hier mit der Funktion List ein mächtiges Werkzeug. Sie verarbeitet die Zeilen der Ergebnisliste einer Mapping-Funktion und formatiert sie nach einer gewählten Vorschrift in eine Liste von Objekten. Abbildung 18 zeigt hierfür eine JavaScript-Funktion, welche eine Ergebnisliste mit den Spalten geometry und value in eine GeoJSON-FeatureCollection wandelt.

40 4 Implementierung einer Webpräsenz für Geodaten mit CouchDB und GeoCouch 37 function(head, req) { var row, out, sep = '\\n'; if (typeof(req.headers.accept)!= "undefined" && req.headers.accept.indexof('application/json')!=-1) else start({"headers":{"content-type" : "application/json"}}); start({"headers":{"content-type" : "text/plain"}}); if ('callback' in req.query) send(req.query['callback'] + "("); send('{"type": "FeatureCollection", "features":['); while (row = getrow()) { out = '{"type": "Feature", "id": ' + JSON.stringify(row.id); out += ', "geometry": ' + JSON.stringify(row.geometry); delete row.geometry; out += ', "properties": ' + JSON.stringify(row.value) + '}'; } send(sep + out); sep = ',\n'; send("]}"); }; if ('callback' in req.query) send(")"); Abbildung 18: List-Funktion. Sie wandelt die Ergebnisse eines GeoCouch Spatial-Views in eine GeoJSON-FeatureCollection. (Ogden 2011) 4.4 Integration der GeoCouch-Daten in eine Website Um die Geodaten verfügbar zu machen, sollen sie als ein Vektorlayer auf einer Karte dargestellt werden. Die Implementierung erfolgte in HTML und JavaScript, wobei die Leaflet-Karte in einen div-block eines einfachen *.html-dokuments eingebunden wurde. Das Abrufen der Kartenwerke und weitere Zusatzfunktionen sind ebenfalls mit Leaflet implementiert und hier nicht weiter beschrieben. Um den Datenfluss auf ein Minimum zu reduzieren und so den Kartenaufbau zu beschleunigen, ist es möglich, über die Methode getbounds() der Leaflet-Karte die aktuelle Ausbreitung der Karte abzufragen. Diese können als Parameter im AJAX-Request an die CouchDB übergeben werden, wie es in bereits beschrieben wurde. Die in der aktuellen Ausbreitung befindlichen Features können auf diese Weise bestimmt und durch die in Abbildung 19 gezeigte Map-Funktion pos als Ergebnisliste emittiert werden. Die Liste wird anschließend durch die in Abbildung 18 vorgestellte List-Funktion in eine GeoJSON-FeatureCollection gewandelt und so als Antwort übertragen.

41 4 Implementierung einer Webpräsenz für Geodaten mit CouchDB und GeoCouch 38 function loadplaceswka(bounds) { $.ajax( { type: 'GET', url: ' + '_design/simplegeo/_spatial/_list/geojson/pos?bbox=' + bounds._southwest.lng + ',' + bounds._southwest.lat + ',' + bounds._northeast.lng + ',' + bounds._northeast.lat, datatype: 'json', success: function (data) { [ ] wkageojson.on("featureparse", function (e) { var popupcontent = '<p>'; if (e.properties && e.properties.name){ popupcontent+='name: ' + e.properties.name + '<br />' } [ ] }); popupcontent+='</p>'; if (popupcontent!='<p></p>') { e.layer.bindpopup(popupcontent); } wkageojson.addgeojson(data); map.addlayer(wkageojson); layerscontrol.addoverlay(wkageojson, "Windkraftwerke"); }, }); error: function (req, status, error) { alert('unable to get data:' + error); } Abbildung 19: AJAX-Request an eine CouchDB. Hier wird das Design-Dokument simplegeo in der Datenbank wka_4326 angefragt. Die darin gespeicherte List-Funktion geojson wandelt dann das Ergebnis des Spatial-View pos, der mit den Parametern einer Bounding Box aufgerufen wurde, um. Die nachfolgenden Methoden im Körper der success -Funktion sind Bestandteil des Leaflet.js-Frameworks und parsen die gewonnene FeatureCollection für die Darstellung. Da neben der eigentlichen Geometrie auch die Sachdaten im JSON-Objekt properties übermittelt werden, können diese als interaktive Marker auf der Karte eingebunden und dem Nutzer verfügbar gemacht werden. Mit einem Mausklick auf das zu untersuchende Feature lassen sich so weitere Informationen abrufen (s. Abbildung 19). Die Webseite und alle referenzierten JavaScript-Dateien wurden anschließend als Attachement an ein Design-Dokument angehangen. So ist der Zugriff per URI der Webseite als Anhang des Designdokuments in der Form möglich.

42 4 Implementierung einer Webpräsenz für Geodaten mit CouchDB und GeoCouch 39 Abbildung 20: Screenshot der Konzeptanwendung "Brandenburger Schutzgebiete". Durch Klicken auf eines der Features wurden hier Zusatzinformationen zu einem Wasserschutzgebiet aufgerufen. Außerdem sind Windkraftwerke (blaue Marker) und ein Schutzgebiet (grünes Polygon) in der näheren Umgebung eingeblendet. 4.5 Fazit Das Aufsetzen einer Webpräsentation von Geodaten hat sich als sehr einfach und praktikabel erwiesen. Der Verwaltungsaufwand ist gering, da für die zu verwaltenden Dokumente kein Schema angelegt werden muss. Im Ergebnis sind alle Komponenten dieser Anwendung über einen einzige Server verfügbar die beginnend mit der Webseite aus der CouchDB-Instanz geladen werden. Die Reihenfolge sieht dabei folgendermaßen aus: Anfrage des index.html-dokuments über die URI Referenzierte JavaScript-Bibliotheken werden nachgeladen Interaktive Karte wird initialisiert und Features werden asynchron abgefragt und als Vektorlayer auf die Karte gemappt Durch die Formatierungsmöglichkeiten der List-Funktion bieten sich vielfältige Schnittstellen, da Geodaten, wenn auch mit einem höheren ersten Aufwand, an das gewünschte Mapping-Framework angepasst werden können. Zu beachten ist, dass die erste Indexierung als R-Tree für große Datenbestände zeitaufwändig ausfallen kann. Dies sollte beim Erstellen einer Webpräsens berücksichtigt werden, um Nutzern die Wartezeit zu ersparen. Nachdem der Index bereitsteht, werden neue Features mit dem ersten Aufruf in den Index eingepflegt, er muss also nicht komplett neu generiert werden. Des Weiteren fiel im Testbetrieb und speziell beim Testen verschiedener Spatial Views auf, dass der Index eines Views sehr schnell viel

43 4 Implementierung einer Webpräsenz für Geodaten mit CouchDB und GeoCouch 40 Speicherplatz in Anspruch nehmen kann. Um Speicherplatz zu sparen, ist es sinnvoll, alte Views durch den Compaction -Befehl zu entfernen, der durch CouchDB bereitgestellt wird. Die Abfragemöglichkeiten beschränken sich im Moment auf einfache Bounding Box Queries. In Kombination mit dem angewandten MapReduce-Verfahren und den Formatierungsmöglichkeiten lässt sich dies für mächtige Sachabfragen mit geographischem Bezug einsetzen. Für umfangreiche Analysen ist GeoCouch aber zum gegenwärtigen Zeitpunkt nicht einsetzbar. Es ist auch fraglich, ob dies ein erklärtes Ziel für das GeoCouch-Team sein wird. Nichtsdestotrotz sind nach eigenen Aussagen des GeoCouch-Programmierers Volker Mische weitere Funktionen in Arbeit (s. Anhang 1).

44 5 Navigationsanwendung mit Neo4j Spatial 41 5 Navigationsanwendung mit Neo4j Spatial Die Suche nach einem Weg zwischen zwei Punkten ist eine der grundlegenden Fragen, die durch Geodaten beantwortet werden können. Die Suche lässt sich durch Bedingungen, wie das Finden des kürzesten oder schnellsten Weges, beliebig erweitern. Die Beschreibung eines solchen Weges wird sich allgemein auf die einzelnen Wegpunkte und die Folgerichtung beziehen die dabei passiert werden müssen. Im Grunde lässt sich dieses Problem also auf einen Graphen reduzieren, dessen Knoten die Wegpunkte und dessen Kanten die Wege zwischen diesen Punkten beschreibt. Entscheidend für das Traversieren eines solchen Graphen ist in erster Linie nicht die Metrik der Punkte, sondern ihre Topologie. Diese sollte sich in einer Graphdatenbank wiedergeben lassen. Im Folgenden soll ein Beispiel für eine solche Problemlösung gegeben werden, bei dem topologisch strukturierte Geodaten in die Graphdatenbank Neo4j importiert werden und anschließend zwischen gegebenen Start- und Zielkoordinaten der kürzeste befahrbare Weg ermittelt wird. Für die Implementierung in Java kommt Neo4j Community Edition in der Version 1.6 und die Spatial Extension Neo4j Spatial als Development Snapshot Version 0.8 zum Einsatz. Beide stehen unter der GPL. Neo4j Spatial baut auf das OpenGIS GeoTools Toolkit auf, welches in Version 8.0 Milestone 4 bereitsteht. 5.1 Vorbereitungen Neo4j implementiert beruhend auf der Graphentheorie bereits umfassende Algorithmen, um die Datensätze im Graphen zu traversieren. Am einfachsten ist dies in der Webkonsole des Datenbankservers zu testen (s. Kapitel 2.5.2). Die Abfrage erfolgt mit der Traversierungssprache Cypher. neo4j-sh (0)$ START a=node(2093), x=node(6) MATCH p = shortestpath( a-[*..15]-x ) RETURN p ==> ==> p ==> ==> (2093)<--[TEST,3114]--(500)--[CHANGESET,499]-->(6) ==> ==> 1 rows, 1 ms Abbildung 21: Abfrage des kürzesten Pfads der Länge 2 zwischen den Knoten mit der ID 2093 und 6. Das MATCH-Statement gibt hier Bedingungen für die Traversierung der Kanten im Graph. Da nicht explizit ein Label in der Form [:LABEL] angegeben ist, werden alle in Frage kommenden Beziehungen durchlaufen. Der Parameter *..15 beschränkt die Suche dabei auf maximal 15 Schritte. Die in Abbildung 21 gezeigte Berechnung des kürzesten Pfades bezieht sich auf einen ungewichteten Graphen und zählt lediglich die zurückgelegten Schritte. Soll sich die

45 5 Navigationsanwendung mit Neo4j Spatial 42 Auswertung auf die tatsächliche geometrische Länge beziehen, wie es von einer Navigationsanwendung erwartet werden würde, so müsste das Gewicht der Kante also entweder implizit aus den Eigenschaften der Knoten berechnet werden oder explizit als Gewicht der Kante verfügbar sein. 5.2 Datengrundlage Als Datengrundlage für den Prototypen einer Navigationsanwendung sollen die Vektordaten des OpenStreetMap-Projekts dienen. Sie können direkt auf der Website im OpenStreetMap-XML-Format exportiert werden. Alternativ bieten andere Webseiten Datensätze, an die das Downloadlimit des OpenStreetMap-Projekts überschreiten. Unter sind tagesaktuelle 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=" " lat="54.0" lon="12.2" user="svenhro" uid="46882" visible="true" version="1" changeset="676636" timestamp=" t21:37:45z"/>... <way id=" " user="masch" uid="55988" visible="true" version="5" changeset=" " timestamp=" t11:47:08z"> <nd ref=" "/>... <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=" " timestamp=" t14:23:49z"> <member type="node" ref=" " role=""/>... <tag k="type" v="route"/> </relation>... </osm> Abbildung 22: Gekürztes Beispiel einer OSM-XML-Datei. (OpenStreetMap Wiki 2011). Neo4j Spatial implementiert in der aktuellen Version mehrere Möglichkeiten, Geodaten einzupflegen. Neben dem Einlesen der Geometrie als Well-known Text oder Wellknown Binary steht die Möglichkeit des Imports von Shapefiles und OSM-Dateien bereit.

46 5 Navigationsanwendung mit Neo4j Spatial 43 GraphDatabaseService databaseservice = new EmbeddedGraphDatabase(storeDir); OSMImporter importer = new OSMImporter(layerName); importer.importfile(db, osmpath); importer.reindex(db, 1000); Abbildung 23: Import einer OSM-Datei in eine eingebettete Graphdatenbank. Der entstandene Graph lässt sich mit dem Programm Neoeclipse visualisieren und auf seine Struktur untersuchen. Besonders interessant ist es hier zu erkennen, wie die Topologie der Pfade in der Datenbank repräsentiert ist. In Abbildung 24 ist der 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 Eigenschaften trägt. Jeder dieser Stützpunkte eines Weges besitzt genau eine Kante des Typs NODE, dessen Endpunkt Träger der Informationen des Wegpunktes, wie Rechts- und Hochwert, sowie der node_osm_id ist. Um dem Weg zu folgen, kann entlang der Kanten mit dem Label NEXT traversiert werden. Neben dem eigentlichen Label zeichnet sich diese Kante durch die Eigenschaft lenght aus, welche beim Importieren aus den gegebenen Koordinaten berechnet wird. Es handelt sich also um einen gewichteten Sub-Graphen. Abbildung 24: Visualisierung in Neoclipse.