Umwandeln von GPS-Koordinaten in Adressen

Für die Geovisualisierung von Daten können neben GPS-Koordinaten auch Adressen verwendet werden. Dies kann vor allem sinnvoll sein, wenn verschiedene Detailebenen verwendet werden sollen. Das kann z.B. die Hierarchie Land à Postleitzahl à Adresse sein. Wenn von einer Lokation allerdings nur die GPS-Koordinaten vorhanden sind, muss noch das Land und die Postleitzahl herausgefunden werden, um eine solche Hierarchie abbilden zu können. Hierfür bietet z.B. google-Maps die Möglichkeit, die Koordinaten in Adressen umzuwandeln. Dafür muss die folgende Web-Adresse verwendet werden: „http://maps.googleapis.com/maps/api/geocode/json?latlng=x-Koordinate,y-Koordinate&sensor=true_or_false. Der Aufruf der Adresse gibt ein json-Objekt zurück, welches Ausgewertet werden kann (auch eine Ausgabe im xml-Format ist möglich). Wenn nun natürlich viele Koordinaten umgewandelt werden müssen, kann z.B. ein Programm in C# entwickelt werden, welches automatisiert die Anfragen an google sendet und die Adressen abspeichert. Zu beachten in diesem Fall ist allerdings, dass nur eine bestimmte Anzahl an Anfragen von einer IP-Adresse von google bearbeitet wird. Wenn zu viele gesendet werden, wird keine Adresse zurückgegeben, sondern eine Meldung, dass an diesem Tag bereits zu viele Anfragen gestellt wurden.

Das Büro der ixto-GmbH in Berlin hat näherungsweise die folgenden GPS Koordinaten: Breitengrad 52,52527 und Längengrad 13,38742. Diese Koordinaten zeigen bei google-Maps auf den folgenden Punkt:

Da die Adresse bei google mit . statt , eingegeben werden muss, ist die Web-Adresse für die GPS-Koordinaten folgende: http://maps.googleapis.com/maps/api/geocode/json?latlng=52.52527,13.38742&sensor=true_or_false. Ein Ausschnitt aus dem Ergebnis wird folgend dargestellt:

Zusätzlich werden noch informationen u.a. zum Land, Bundesland und die Postleitzahl zur verfügung gestellt.

Data-Warehouse mit Fremdschlüsseln

Vor einiger Zeit bestand ein Kunde darauf, dass im Data-Warehouse Tabellenrelationen mit Fremdschlüsseln realisiert werden. In diesem Zusammenhang fragten wir uns, welche Verschlechterung der benötigten Ladezeiten zu erwarten ist. Um dies zu testen, haben wir eine Faktentabelle mit 2.500.000 Zeilen gebaut, welche 44 Spalten enthält, wovon 20 als Fremdschlüssel genutzt werden. Die Fremdschlüsselspalten sind alle vom Datentyp Integer. Für den Vergleich wurde der Ladeprozess jeweils drei Mal mit und ohne Fremdschlüssel durchgeführt.

Die Durchschnittswerte der Ladezeiten werden in der folgenden Tabelle dargestellt.

Mit Fremdschlüsselbeziehungen

Ohne Fremdschlüsselbeziehungen

7:14 min

2:20 min

 

Durch den Kundenwunsch Fremdschlüssel im Data-Warehouse einzusetzen, würde sich in diesem Kundennahen Szenario der Ladeprozess mehr als verdreifachen.

Sort mit Merge anstatt Lockup

Mir hat ein Berater erzählt, dass in SSIS ein Merge mit Sort schneller ist, als ein Lockup. Nach anfänglichen erstaunen baute ich ein Szenario, um diese Behauptung zu überprüfen. Hierfür wurde eine Faktentabelle mit ca. 12 Mio. Zeilen befüllt und zwei Dimensionstabellen mit jeweils 4 Mio. Zeilen. Im ersten Versuch wurde die Faktentabelle mit einer Dimensionstabelle verbunden. Hierfür wurden drei Methoden verwendet: ein Lookup, ein Merge mit vorherigen Sort und ein Merge, bei dem die Sortierung bereits in der Datenquelle geschieht. Der Aufbau mit den drei Methoden zeigt das folgende Bild, wobei als erstes der Lookup abgebildet ist, als zweites der Merge mit vorheriger Sortierung und als letztes der Merge mit Sortierung in der Datenquelle.

Der Versuch wurde dreimal durchgeführt und die Durchschnittswerte dieser Versuche werden in der folgenden Tabelle dargestellt:

Lookup

Merge mit Sort

Merge mit Sort in der Datenquelle

142,86 sec

141,17 sec

87,11 sec

 

Zu meinem Erstaunen war der Merge mit Sort sogar ein Tick schneller als ein Lookup und der Merge mit Sortierung in der Datenquelle am Schnellsten. Der Grund, dass die Sortierung in Datenquelle am schnellsten war, hängt damit zusammen, dass diese durch die Datenbankengine durchgeführt wird und dort besonders performant geschieht. Unterschiede Beim Lookup und dem Merge mit Sortierung zeigte sich vor allem auch darin, dass mehr als doppelt so viel RAM beim Merge benötigt wurde. Somit ist der Lookup zwar gleich schnell, allerdings deutlich Ressourcenschonender.

Bei einem weiteren Versuch wurde auch noch die weitere Dimensionstabelle mit der Faktentabelle verbunden.

Lookup

Merge mit Sort

Merge mit Sort in der Datenquelle

164,04 sec

288,58 sec

103,31 sec

 

Hierbei zeigte sich ein ähnliches Bild wie im vorherigen Versuch, jedoch war der Merge mit Sort in diesem Fall die mit Abstand langsamste Variante. Auch zeigte sich, dass der Ramverbrauch bei dieser Methode am langsamsten war. In allen Versuchen am schnellsten war der Merge mit Sortierung in der Datenbank.