Also, herzlich willkommen zu meinem Vortrag GeoCouch, ein endimensionale Index für Apache CouchDB und CouchBase. Nur schnell ganz kurz über mich, ich bin der Volker, ich bin der Autor von GeoCouch

und ich liebe Open Source, code meistens in JavaScript und Erlang und arbeite für CouchBase. So, das Thema hört sich ja relativ komplex an, deswegen nehme ich jetzt mal Stückchen vor. Was ist denn ein endimensionaler Index überhaupt? Dazu ein Beispiel, ich habe im Januar dieses Jahres jemanden bei der CouchDB-Konferenz

in Berlin kennengelernt und diese Firma stellt Kommunal-Software her und der war total begeistert als er gehört hat, dass GeoCouch jetzt auch einen endimensionalen Index hat und zwar aus einem ganz einfachen Grund, weil bei dem Gewerbeamt haben wir zum Beispiel

so Sachen wie natürlich zweidimensional, das heißt, ich will einfach alle Gewerbe in einem bestimmten Gebiet haben, das ist mehr oder weniger trivial. Jetzt kann man aber auch drei Dimensionen wollen, normalerweise denkt man jetzt wahrscheinlich an sowas wie Höhe oder so weiter, aber die dritte Dimension kann auch was ganz anderes sein, zum Beispiel Zeit.

Ich will zum Beispiel wissen, welche Gewerbe entstanden in diesem Gebiet seit 2010. Zeit ist dabei aber noch ein ganz interessanter Faktor und zwar ist Zeit nicht unbedingt ein bestimmter Punkt in der Zeit, sondern es kann auch andauern. Das heißt zum Beispiel, wenn ich jetzt alle Gewerbe haben will, die es an diesem

Ort zwischen 2009 und 2011 gab, sind natürlich nicht nur alle dabei, die zu dem Zeitraum entstanden sind, sondern auch alle, die da aufgehört haben oder bereits davor angefangen haben oder dahinter angefangen haben.

Aber es geht ja um Endimensionalität, das heißt, was ist dann bitte schön 4D? 4D können einfach quasi beliebige Attribute sein, zum Beispiel Gewerbeart. Ich will zum Beispiel alle Bäcker in einem bestimmten Gebiet seit einem bestimmten Zeitpunkt haben. Das kann man jetzt beliebig fortführen, man kann zum Beispiel 5D sagen und sagen,

ich will alle Bäcker, die es in diesem Gebiet seit 2010 gibt, die eine Verkaufsfläche über 50 Quadratmeter haben und so kann man jetzt quasi endlos weiterspielen und wenn man jetzt zum Beispiel in den OpenStreetMap denkt an die Tags, da gibt es ja hunderttausende, dann können wir einfach jedes Tag da quasi abfragen, so die Idee dahinter.

So, viele würden jetzt wahrscheinlich denken, ja gut, dann nehme ich ein SQL-Statement in einer normalen Datenbank und ja, ich habe eine Anfrage und fertig, was baue ich da irgendwas anderes? Warum baue ich überhaupt GeoCouch für sowas? Der Grund könnte sein, dass ich eben Apache-Couch oder Couchbase nehmen will.

Und jetzt ist wahrscheinlich wieder die Frage, ja was ist das überhaupt, das sind beides Datenbanken. Gut, Postgres ist auch eine Datenbank, die kann ich auch nehmen, aber es ist eben eine andere Art von Datenbank. Es ist eine sogenannte dokumentenorientierte Datenbank. Das bedeutet, die kleinste einer, die ich speichern kann, ist ein sogenanntes Dokument.

Bei einer relationalen Datenbank ist sozusagen das kleinste Element, das ich speichern kann, eine einzelne Zeile in der Tabelle. Hier ist es ein sogenanntes Dokument. Und jetzt und sonst ist es auch noch ganz anders, das heißt, bitte jetzt alles vergessen, bei dem dokumentenbasierten Datenbank gibt es keine Triggers, keine

Assistenz meistens. Also alle die Sachen, also Asset und so alles vergessen und genau, jetzt denken sich wahrscheinlich auch viele, aber Normalisierung ist unabdingbar. Das fällt auch weg, ich tue die Daten auch nicht normalisieren, weil ich habe keine Joins und wenn würde ich sie normalisieren, wäre es schwer, die wieder zusammenzufügen,

wenn ich keine Joins habe. Wie sieht jetzt so ein Dokument aus? Dokument ist eine einfache JSON-Struktur. Für die, die JSON nicht kennen, ist im Prinzip, ich habe den Schlüssel und ich habe den Wert. Das wäre jetzt zum Beispiel ein Messwert einer Wetterstation.

Ich messe die Temperatur. Was jetzt auffällig ist, ich speichere zum Beispiel den Namen der Station direkt ab. In der relationalen Datenbank wäre das alles IDs. Hier speichere ich wirklich die Daten einfach komplett mit dem Messwert ab. Für jeden Messwert speichere ich komplett ab, wo ist der, wie heißt die Station

und so weiter. So ein Dokument hat noch andere Vorteile und zwar gibt es eben auch keinen Schema. Das fällt auch weg. Wenn ich jetzt also zum Beispiel beschließe, diese Station bekommt einen Sensor dazu, um zum Beispiel den Niederschlag zu messen, dann mache ich das einfach. Ich füge es hinzu und ab dem Zeitpunkt hat jedes Dokument einfach nochmal einen

Wert dazu. Wenn ich es auch, keine Ahnung, zum Beispiel bei meinem Webinterface darstellen will, gut kriege ich die Werte aus der Datenbank. Ab einem bestimmten Zeitpunkt fängt dann erst die Kurve an für den Niederschlag. So, das Ganze ist eben sehr flexibel und ist eben auch ganz schön während der Entwicklung,

weil oft ist das so, man macht den Datenbankschema und dann fällt einem ein, oh ich habe noch diesen einen Wert vergessen und dann wird es plötzlich irrsinnig kompliziert und es funktioniert nicht mehr richtig und so. Und hier kann ich eben gerade auch während der Entwicklungszeit einfach, das heißt CouchSpace und CouchDB sind so ein bisschen wie eine Oracle-Datenbank und PostgreSQL.

Das sind beides Datenbanken und so, man kann innige Sachen damit machen, aber im Prinzip sind die einfach ganz verschiedene Produkte und so ist es hier auch. Und die haben eben auch verschiedene Ziele. Bei CouchSpace ist es so, CouchSpace ist relativ jung, gibt es erst seit 3-4 Jahren und da geht es hauptsächlich um Skalieren.

Skalieren wird häufig verwendet und man weiß überhaupt nicht, was damit eigentlich gemeint ist. Ich erkläre es mal an einem Beispiel, was ich darunter verstehe oder wozu man es eben verwenden will. Ich habe jetzt hier 3 Server, da sind meine Daten, die ich gerade speichern will, die Dokumenten A, B und C, wie ich da jetzt wunderbar verteilen drauf. In dem Beispiel bekommt man jetzt einfach jeder Server ein Dokument.

Das könnte ich auch mit einem anderen System einfach von Hand machen, das ist überhaupt noch nicht schwierig. Schwierig wird es immer im Fehlerfall. CouchSpace einfach einstellen, mach von jedem Dokument eine Kopie. Wenn ich natürlich auch mehr Server habe, kann ich nur sagen, es müssen immer 5 Kopien da sein. Hier in diesem Beispiel ist immer nur eine Kopie da. Natürlich ist die Kopie ein Datensatz von einem anderen Server, weil es macht keinen

Sinn auf dem gleichen Server eine Kopie von sich zu haben, weil wenn er abschmiert, ist die auch weg. So, jetzt also das Beispiel, was ist, wenn der Server, der unterstellt zum Beispiel hier abschmiert. Jetzt kann ich plötzlich nicht mehr, wenn ich jetzt anfragen will und ich will das Dokument C haben, es ist ja eigentlich weg. Was mache ich dann? Ja gut, ich habe die Kopie, das heißt, ich mache einen Click und sage, alle

Kopien bitte reaktivieren, dann wird es quasi zum Original und für den Endanwender war im Prinzip die Datenbank nie down. Er sieht einfach wieder, er kann es auf das Element C zurückgreifen und genau, die Datenbank war nie down. Das ist natürlich das Problem, wenn man jetzt wieder eins abschmieren

würde, würden ja Daten fehlen. Das heißt, ich mache im Webender vielleicht nochmal einen Click und die Daten werden frisch verteilt, es werden Kopien angelegt usw. Und jetzt könnte im Prinzip wieder einer von den beiden Server abschmieren, das System würde einfach aber weitergehen. So, das ist eben, worum es hauptsächlich geht, eben um diese Skalierbarkeit. Ich kann eben auch jetzt zum Beispiel nochmal den Server hinzufügen,

dann klicke ich wieder drauf und die Daten werden wieder frisch verteilt usw. Bei Apache CouchDB gibt es viele Dinge und während hier jetzt fünf verschiedene Vorträge würden wahrscheinlich diese fünf Personen fünf verschiedene Sachen erzählen, was sie an CouchDB so cool finden. Zu dem Thema gibt es auch morgen einen Vortrag, der ist auch über

CouchDB, der nennt sich Couch WFS und der macht genau eben den anderen Aspekt, das stellt ihr da von CouchDB. Ich gehe auf den Teil an, den ich besonders interessant finde und das ist die Replikation. Das bedeutet, also wir vergessen jetzt gerade so, was wir über CouchBase gehört haben, sonst verliert es nur, also schnell vergessen. So, bei CouchDB geht es darum, dass man die Daten auf andere

Geräte überspielen kann, im Prinzip den kompletten Datensatz rüberspielen. Das macht zum Beispiel jetzt Sinn, ich überspiele von einem Server die Daten auf meinen Laptop. Dann brauche ich eben im Nachhinein keine Verbindung mehr zum Server. Das macht es bei Laptop Server nicht so viel Sinn, weil Internet gibt es meistens überall, auch hier ist das WLAN ja sehr gut,

aber ich kann es auch auf mobile Geräte übertragen. Das heißt, die mobile Geräte können zum Beispiel auch ein Traktor sein. Das ist die Referenz zum Lightning Talk zu Beginn der Foskis, wo eben die Geobox vorgestellt wurde. Weil genau da wurde CouchDB verwendet, weil eben bei den

Landwirten die Daten eben direkt auf die mobilen Geräte überspielen kann, sie brauchen keine Internetverbindung mehr und haben die Daten lokal verfügbar. Schöner an dem ganzen System ist es aber auch, ich kann jetzt zum Beispiel Daten eben von einem Server auf den Laptop spielen, auf das mobile Gerät, eine Änderung auf mein Laptop, direkt zurückspielen auf den Server. Das heißt, ich kann ganze Topologien aufbauen.

So, jetzt haben wir das alles geklärt, was ist CouchDB und Apache CouchDB, jetzt kommen wir natürlich zum eigentlichen Thema des Vortrags, was ist denn überhaupt Geo-Couch? Das ist hier am einfachsten erklären, mit wo kam es her. Und zwar war ich 2008 in Australien, habe auch schöne Fotos geschossen und da habe ich bei einer Firma

gearbeitet, die machte eben auch Open Source Geo-Sachen und das Problem war, die hatten einen Auftraggeber und das war ein Amt und die hatten so eine Broschüre alle zwei Jahre, da war irgendwas über die Wasserqualität drin, über die Böden und so weiter und die haben beschlossen, wir wollen jetzt ein schönes Webinterface

haben für die ganzen Sachen. Ja gut, wir haben eben am Anfang die Daten als XML bekommen, haben sie zu JSON gemacht, dann schön in Open Dares Anwendung geschrieben, alles schön dargestellt, hat alles wunderbar funktioniert. Und dann kam der Tag, wo der Prototyp vorbei war und natürlich wurde der Prototyp die Endversion, wie es immer ist, aber auf jeden Fall war die Idee, sie

wollen jetzt den kompletten Stack haben, das heißt eine Oracle Datenbank, ein Geo-Server und da kommen dann die Daten her. Das Problem war natürlich, unser JSON war natürlich wie wir es uns vorgestellt haben, das heißt, wir müssen ein Modul für Geo-Server schreiben, dann wir das JSON so bekommen, wie wir es wollen. Und es wurde ein Datenbank-Schema her. Der Datenbank-Experte dieses Amtes hat 8 Wochen

gebraucht, um eins zu finden, weil die Daten relativ komplex waren, dann haben wir das angeschautes Schema und im Endeffekt war es dann so, man braucht für die Anfragen, die wir geschickt haben, braucht man den Cross-Join über alle Tabellen. Das heißt, man fragt sich dann ja, warum tu ich es normalisieren, wenn ich am Schluss wieder alles zusammenfüge. Und zu dem Zeitpunkt

habe ich gerade eben Couch-Debate kennengelernt und dann festgestellt, es wäre einfach die Lösung gewesen, weil wir hätten die Daten als JSON-Konvertierte abgesperrt und fertig gewesen. Oh, was ich vergessen habe zu erwähnen natürlich das Datenformat des Ursprünges waren natürlich Excel-Tabellen. Dann wäre es super einfach gegangen, ich hätte die Excel-Tabellen

benutzt, aber mach ich. Und so ist also quasi Geo-Couch, ist im Prinzip, so wie Postgres zu Postgres ist Geo-Couch zu Couch-Base aber auch Apache-Couch-DB. So, das kann jetzt alles. Ich kann alle Geometriearten

speichern. Da das ganze System ja auf JSON basiert, ist es im Prinzip alle Geometriearten die JSON unterstützt, werden auch von Geo-Couch unterstützt. Also ich kann eben meine Polygone speichern, meine Linien speichern, meine Multipunkte speichern und so weiter. Von der Anfrage-Seite aus gibt es eben, dass ich so eine Gebiets-Suche mache mit der Bounding-Box und da alles bekommen,

was geschnitten wird. Und was jetzt neu ist, es gibt die Polygon-Suche, die verwendet im Hintergrund Geos, weil das gibt es einfach und funktioniert sehr gut. Die Polygon-Suche ist aber momentan noch nicht in der viel seltenen Version, sondern nur in einer Branche auf einem privaten GitHub-Depository. Das hat diverse

Gründe, die ich jetzt nicht ausführen will. Aber es funktioniert eben. Es wurde eben auch von diesem anfangs erwähnten Beispiel mit dem Gewerbeamt. Wir wollten eben auch nicht nur eine Bounding-Box haben, sondern eben halt alle Gewerbe in verschiedenen Stadtgrenzen haben. Die waren eben auch sehr glücklich, dass es jetzt eben gibt. Dann die KNN-Suche. Gibt mir alles,

es gibt mir die 5 nächsten Punkte in der Umgebung. Das interessiert sogar nicht mal im Internet, sondern nur auf meinem PC. Das Problem ist, dass da wurde Code portiert von Postgiz und da gibt es Lizenzprobleme, wo ich jetzt keinen Ärger haben will. Da muss ich schauen, wie ich das löse und mit dem Postgiz deutlich sprechen. Aber als wenn es jemand haben will, kann ich es ihm geben,

aber ich will es halt noch nicht online stellen, weil GPL und so ist immer ein Problem. Genau. Und natürlich die bereits erwähnten multidimensionalen Anfragen. Diese bestehen bereits in der Patchy CouchDB. Es ist aber auch wieder nur eine Branch auf meinem GitHub Repository, aber wie gesagt, es ist zum installieren genau das gleiche.

Ich arbeite momentan dran, dass die dann eben auch für CouchBase funktionieren. Wie schaut die Zukunft aus von GeoCouch? Ich baue eben gerade, für die es interessiert, CouchDB ist in R lang geschrieben, CouchBase auch größend heiß und aus Performance Gründen

wird sehr viel in C umgeschrieben und auch GeoCouch wird komplett von R lang nach C portiert. Da baue ich eben gleich dieses multidimensionale Sachen ein. Dann, was bisher wirklich ein Problem war, war die Performance. Also wer bei der Force4G 2011 bei einem Vortrag von mir war, da hatte ich so eine Folie mit,

es kommt mich auf die Performance an, wenn man Performance will mit ein paar PostGIS, wenn man eben die Replikation zum Beispiel haben will mit CouchDB mit GeoCouch, das will ich auch ändern. Das Ziel ist wirklich halt schneller wie PostGIS zu sein und es ist eigentlich gar kein Problem. Nein, der Grund ist, weil PostGIS kann viel mehr.

PostGIS ist ein viel komplexeres System und dieses Dokumenten basiert es mehr oder weniger in Keyvalue Store und man hat eben keine Transaktionen und die ganzen Sachen, das macht die ganze Sache eben halt viel einfacher und deswegen müsste die Performance theoretisch auch viel besser sein. Das ist so mein Ziel, also schneller wie PostGIS ist das Ziel. Ziel ist es bis zur Force4G zu haben, zum Beispiel in der 1. Version.

Mal schauen, ob das klappt, werden wir sehen. Und noch ein Zukunftsziel, das relativ schwierig ist und zwar momentan kann das multidimensionale Index nur mit Zahlen arbeiten. Was ist es, wenn ich zum Beispiel eine Adressdatenbank habe und ich will jetzt alle haben, alle von C bis D,

die ein bestimmtes Alter haben und ein bestimmtes Geschlecht und so weiter. Mit Strings, also mit Zeichenketten ist das Ganze ganz schön kompliziert. Das Problem ist ganz leicht beschrieben, was ist die Distanz zwischen einem A und einem chinesischen Symbol? Das ist quasi die Problemstellung

und da habe ich auch schon ein paar Ideen und ich glaube, das kriege ich dann schon irgendwie hin. Da würde ich anpeilen, die ForceGIS 2015 oder so, das dürfte ein guter Zeitplan sein, aber sowas steht eben noch aus. Zum Abschluss will ich noch kurz noch ein Beispiel erzählen, für was man das eben verwenden kann, diesen multidimensionalen Index.

Ich habe vor über einem Jahr eine Anfrage bekommen von jemandem, die Firma macht Analysen von Satellitendaten über das Abschmetzen der Pole. Die speichern sogar nicht mal die Daten in der Datenbank ab, sondern will ich nur die Metadaten über die Satellitenbilder. Die hatten das Problem, dass momentan

mit ForceGIS wunderbar alles läuft, aber sie wissen, dass mit den neuen Satelliten, die die ESA hochschießt, werden die Datenmengen so viel, dass es wohl dann um die Ohren fliegen wird. Die tarnen eben halt früh. Die haben eben das Problem, sie brauchen den multidimensionalen Index, weil die sagen zum Beispiel, sie wollen jetzt ein Satellitenbild

in einem bestimmten Gebiet haben, also eine Polygonabfrage, zunehmend zu einem bestimmten Zeitpunkt haben und vielleicht noch ein bestimmtes Spektrum der Bilder und so weiter. Da hatten wir eben auch viele Dimensionen. Genau darum geht es. Das war es schon. Vielen Dank für die Aufmerksamkeit.

So, wir haben noch genug Zeit für Fragen. Wenn es Fragen gibt... Ja? Genau. Also es ist quasi ein R-Baum und die momentane Implementierung

ist ein R-R-Sternbaum. Das ist quasi der Befinder vom R-Sternbaum, der hat einen R-R-Sternbaum gemacht. Aber ich ändere es jetzt dann wahrscheinlich um, auch von diesem Professor, das ist dann einfach ein Index, wo vorher die Daten mit einer

Z-Kurve sortiert werden und dann von unten nach oben aufgebaut wird quasi. Und das Ganze verbunden dann mit einem LSM-Baum. Aber das kann ich noch genauer erklären, wenn es jemanden interessiert, kann ich da noch Details angehen, wie das genau, was ich da so für Pläne habe und wie es implementiert wird. Das ist recht spannend. Ja, weitere Fragen.

Also man kann auch gerne Sachen zu CouchDB fragen oder CouchBase oder wie auch immer, weil da kenne ich mich gut aus. Genau. Also für GeoCouch bin ich der einzige Entwickler. Aber ich bin bei CouchBase fest angestellt,

für eben an GeoCouch zu arbeiten, bin momentan der einzige Entwickler. Und ich hoffe, dass irgendwann, ja, dass irgend ein Kunde haben will, sodass es dann mehr Entwicklungen gibt quasi.

Ja genau, also das ist, man kann es auch automatisch einstellen, ist aber wenig empfohlen, weil das halt man muss da schon wissen, was man tut quasi. Und das Problem ist, wenn man es automatisiert hat, wenn man z.B. so etwas hat, wie man hat

ein Split-Brain plötzlich, da denken die Hälfte der Server, die andere Hälfte ist down, tut dann irgendwie die Topologie ändern und das machen gerade beide und fünf Sekunden später ist wieder alles normal und dann muss es wieder zurück und so. Deswegen ist es normalerweise besser, das von Hand zu machen, aber man könnte es automatisieren auf jeden Fall. Aber es wird meistens von Hand gemacht, dass ein Admin eine E-Mail

bekommt und sagt, ok, hier ist was kaputt und dann, aus praktischen Gründen. Hier vorne war eine Frage. Ja genau, ja. Und es gibt zum Beispiel schon ein experimentelles Backend für Impossum,

für Couchtabby, dass man eben Daten direkt von oben über Impossum in Couchtabby importieren kann. Was man damit herumspielen will.

Also ich würde spontan sagen, das ist relativ egal. Ich würde es dann einfach ausprobieren. Das ist so schwer allgemein zu sagen, aber also ich weiß jetzt von keinen Problemen und es dürfte eigentlich relativ egal sein,

denn speziell bei Couchtabby ist der Overhead mehr und man könnte es von JSON serialisieren, deserialisieren und so weiter und auf die Platte schreiben und so weiter, sodass die Größe redet. Also wenn man im normalen Gebiet, also klar, wenn ich jetzt so wie ein 100 MB JSON Dokument habe, dass es dann irgendwie um die Ohren fliegt, das kann gut sein, aber wenn ich so im normalen Gebiet bin, dürfte es eigentlich keine Probleme machen.

Es dürfte es egal sein. Wir haben jetzt noch 8 Minuten laut der Raumuhr. Ich wurde nicht darum gebeten nochmal an die Fragebögen zu ändern, das heißt ihr könnt das jetzt völlig eigenmotiviert noch machen,

wenn ihr hier bleibt und auf den nächsten Tag wartet.