Einführung in die Nutzung von Geodaten in der NoSQL-Datenbank MongoDB

MongoDB trifft Geo Data
Kommentare

Die NoSQL-Datenbank MongoDB gehört sicherlich zu den heißesten Themen für Entwickler. In diesem Artikel erhalten Sie einen kurzen Überblick über den Einsatz von MongoDB unter PHP. Insbesondere zeigt der Praxisteil einige Fingerübungen für die Nutzung von Geodaten mithilfe von MongoDB.

PHP Magazin

Der Artikel „MongoDB trifft Geo Data“ von Carsten Eilers ist erstmalig erschienen im PHP Magazin 4.2012

Heute setzt man für PHP-Anwendungen im Wesentlichen auf den LAMP Stack, damit ist dann eigentlich MySQL fast immer mit von der Partie. Im Bereich der Entwicklung hat sich die Nutzung des objektorientierten Aufbaus von PHP-Anwendungen bereits durchgesetzt. Kaum eine Anwendung nutzt aber daneben kein JavaScript und meistens spielt auch Ajax eine große Rolle. Wobei das „x“ bei „Ajax“ kaum noch XML, sondern fast immer einen Austausch von Daten im JSON-Format bedeutet. Tatsächlich sprechen hier einige gar von Ajaj.

MongoDB – NoSQL im Vergleich

Genau hier setzt letztlich die NoSQL-Datenbank MongoDB an. Eine Grundeigenschaft ist, dass MongoDB alle Dokumente im JSON-Format speichert. Dabei werden die Daten ohne die Nutzung von Schemainformationen abgelegt. Müssen bei der Nutzung von MySQL zunächst Datenbanken und Tabellen angelegt und konfiguriert werden und als diesem Schema entsprechende Daten erzeugt werden, so ist der Entwickler bei NoSQL-Datenbanken davon befreit. Beliebige PHP/JSON-Objekte (inklusive eventuell vorhandener Unterobjekte oder Arrays) können einfach in einer so genannten Collection abgelegt werden. Dabei ist grundsätzlich die Ablage völlig unterschiedlicher Objekte in einer solchen Sammlung möglich, wenn auch nicht wirklich sinnvoll. Dieser dokumentenorientierte Ansatz ist insbesondere im Zusammenspiel mit einer objektorientierten Skriptsprache wie PHP recht nützlich und vermeidet den Bruch zwischen Kodierung und Datenvorhaltung. Für die Nutzung von relationalen Systemen wird ja heute oft ein entsprechender Mapper (ORM) genutzt, der jedoch zu größerem Aufwand insbesondere bei der initialen Implementierung führt. Bei vielen Entwicklungen arbeitet man auch direkt mit SQL und überführt nur teilweise Datenbanken in PHP-Objekte und Teile in JSON-Daten. Insbesondere sobald komplexe Objektbeziehungen dargestellt werden müssen, werden die Erwartungen an einen objektrelationalen Mapper oft enttäuscht. Im Gegensatz hierzu ist die Nutzung von MongoDB für die Speicherung von Objekten geradezu trivial; die MongoDB-Schnittstelle ermöglicht hier die direkte Speicherung von PHP-Objekten.

Als erfahrener Entwickler kennen Sie vielleicht die Probleme einer SQL-Datenbank, wenn Schemaänderungen im laufenden Betrieb auf großen Datenmengen durchgeführt werden müssen. Oft müssen hierzu die Systeme zur Sicherstellung der Konsistenz heruntergefahren werden, bevor Daten und Schema konvertiert werden können. Eventuell kommt dazu dann noch das „Wiederanfahren“ einer Replikation. MongoDB arbeitet hingegen ohne ein Datenbankschema. Somit können Sie auf eine Datenkonvertierung verzichten und sämtliche Versionsunterschiede im Code ausgleichen oder Strategien verwenden, wie die Konvertierung beim ersten Schreibzugriff. Intern speichert MongoDB alle Daten in Form von BSON, einem Format, das JSON binär und damit effizienter abbildet. Die Nähe zu JavaScript und JSON ist allerdings groß. MongoDB integriert Spider Monkey (also die JavaScript Engine von Mozilla/Firefox) und nutzt sie an vielen Stellen.

Hinter MongoDB steht die Firma 10gen. Schon 2007 begann man hier nach einer Venture-Capital-Runde von etwa 24 Millionen Euro mit der Entwicklung einer Cloud-Plattform. Nach zwei Jahren Entwicklungsarbeit hat man sich dann dazu entschlossen, die Datenbankkomponente als MongoDB unter einer Open-Source-Lizenz zu veröffentlichen und sich ganz der Weiterentwicklung zu widmen.

Der Name Mongo leitet sich übrigens vom englischen Wort „humongous“ (enorm) ab. Und neben den zuvor genannten Eigenschaften, die MongoDB sehr nahe an Sprachen wie JavaScript und auch PHP bringt, liegt der eigentliche Fokus in einem anderen Bereich: Es geht um Big Data, also um Anwendungen, die sehr große Datenmengen verwalten müssen. Ein zweiter Anwendungsfall ist die Bereitstellung von Diensten für eine sehr große Anzahl von Benutzern. Beide Problemstellungen lassen sich nur mit einem System lösen, das in der Lage ist, ohne größeren Aufwand die Daten auf mehrere Systeme verteilen zu können. Dabei ermöglicht MongoDB diverse Replikationsszenarien, die die Datenvorhaltung im Sinne einer redundanten Sicherung duplizieren können. Hierzu kommt das Sharding-Verfahren, das die Daten, ähnlich einer vertikalen Datenbankpartition, nach bestimmten inhaltlichen Kriterien nahe dem Endbenutzer vorhält.

Ein Bespiel wäre etwa die Trennung der für Endbenutzer vorgehaltenen Daten in einer weltweit verfügbaren Anwendung in regionalen Datencentern. Hierbei würden dann die Daten von europäischen Benutzern in einem Datencenter in Europa, Daten eines asiatischen Benutzers vielleicht in einem Datencenter in Singapur vorgehalten. Die primären Datenzugriffe finden dann im Wesentlichen in der „lokalen“ Region statt. Eine im Hintergrund arbeitende Replikation ermöglicht aber weiterhin den Zugriff auf die Gesamtdaten im Fall eines Ausfalls oder für die Erstellung etwa von globalen Statistiken. Ein solches Szenario wird etwa von foursquare mit dem Einsatz auf Amazon EC2 genutzt.

Neben diesen Funktionen bietet MongoDB auch ein so genanntes Grid FileSystem. Dieses Feature ermöglicht die Verteilung von einer Datei über die Rechnergrenzen hinweg. Dabei wird eine große Datei in kleinere Häppchen zerlegt und damit auch ein Cluster von MongoDB-Systemen verteilt. Sinn des Ganzen ist entweder das Handling von Dateien, das die Kapazität einer einzelnen Maschine überschreitet oder einfach die Möglichkeit, auf Inhalte des Gesamtsystems von jedem Teilsystem Zugriff zu haben.

Oft werden die Begriffe „MapReduce“ (Kasten: „MapReduce“) und „NoSQL“ synonym genutzt. Die allermeisten NoSQL-Systeme nutzen fast ausschließlich MapReduce als Abfragesprache. Bei MongoDB kann der Zugriff hingegen aber mithilfe einer Abfragesprache erfolgen. In den Grundzügen ähnelt die Abfragesprache durchaus SQL, was ein Grund dafür sein könnte, warum MongoDB gerade bei Umsteigern beliebt ist. Abfragen und vor allem Aggregationen mithilfe von MapReduce werden zwar auch unterstützt, muten einem Umsteiger aus einer SQL-Umgebung aber einen sehr großen Paradigmenwechsel zu. Daneben gibt es sehr viele Situationen, bei denen die Nutzung der Abfragesprache deutlich komfortabler ist. Aktuell entwickelt sich bei MongoDB eine neue deklarative Form der MapReduce-Nutzung, die viele umständliche Standard- und Grundaufgaben übernehmen kann.

Download und Installation

Unser erster Weg führt uns zu http://www.mongodb.org/downloads. Aktuell ist hier die Version 2.0.4, etwa 40 Megabyte später haben wir ein Verzeichnis und hier ein Unterverzeichnis bin mit einigen ausführbaren Dateien. Im Wesentlichen benötigen wir zunächst den Datenbankserver (mongod = mongo daemon) und später die interaktive Shell (mongo). Alle Programme haben lediglich eine Konsolenschnittstelle, auf deren Nutzung wir uns zunächst beschränken möchten. Alternativ können Sie MongoDB auch direkt aus Ihrer Linux-Distribution installieren, womit dann auch typische Skripte für init.d erzeugt werden. Auf Windows-Systemen kann mit –install (einmal auf der .exe aufrufen) die Installation als Service gestartet werden. Wichtig ist, dass beim Start des Datenbankservers ein Pfad für das Datenverzeichnis angegeben wird. Fehlt diese Angabe, sucht mongod das Verzeichnis unter /data/db/. Es ist durchaus möglich und auch üblich, auf einem Server mehrere Instanzen zu nutzen. Dabei müssen neben unterschiedlichen Datenverzeichnissen allerdings auch unterschiedliche IP-Ports vergeben werden:

cd /.../mongo-xxxx/bin
mkdir data_28017
./mongod --dbpath ./data_28017 --port 28017

Ohne weitere Parameter gibt damit der Server alle Meldungen auf dem Terminal aus und verbleibt im Vordergrund. Alternativ können die Ausgaben auch in eine Log-Datei umgeleitet werden (–logpath) oder der Server kann sich selbst daemonisieren (–fork) und läuft dann im Hintergrund weiter. In einem weiteren Terminalfenster können wir uns nun mit dem Server in der so genannten Mongo Shell verbinden:

cd /.../mongo-xxxx/bin
./mongo

Auch hier gelten wieder Standardvorgaben für alle Parameter. Ohne weitere Vorgaben verbindet sich die Shell auf den Server unter dem Port 28017 auf der aktuellen Maschine. Natürlich geht das Ganze auch remote und für beliebige andere Ports, hinter denen sich Server befinden. Hier hilft —help für die Ausgabe der möglichen Parameter und deren Funktion. Auch innerhalb der Shell hilft die Angabe von help. Hier sehen Sie dann, dass es wohl eine weitere Methode db.help gibt, die uns vielleicht weiterhelfen könnte. Die Eingabe von db.help (und Enter) zeigt aber eine seltsame Ausgabe: faktisch den Quelltext einer anonymen JavaScript-Methode.

MongoDB nutzt an sehr vielen Stellen JavaScript für die Verarbeitung; wir haben auch bereits gesehen, dass zur Datenspeicherung auf das JSON-Format zurückgegriffen wird. Richtig wäre übrigens die Angabe von db.help() gewesen, wobei die Klammer die JavaScript Engine um die Ausführung der Methode bittet. Hiernach gilt es, die Verbindung zu PHP herzustellen. MongoDB nennt die sprachspezifischen Module selbst „Treiber“. Zumeist ist der MongoDB-Treiber bereits in der Distribution Ihres OS enthalten oder kann eventuell schnell mit pecl install mongo und dem Eintragen der Extension in die PHP.ini installiert werden. Näheres befindet sich unter [1].

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -