Abstandsmessung optimieren

Gestern habe ich die Deutschland-Daten auf dem Server importiert. Das hat exzellent und ohne Abbruch geklappt. Direkt aus dem osm2sql in die Datenbank gepiped. Auch wenn fritsch Befürchtungen wegen des Arbeitsspeichers hatte. Die Swap-Größe hat sich seit 2 Tagen nicht verändert.

Heute haben wir uns mal dem Zeit-Problem bei der Entfernungsberechnung zwischen zwei Städten gewidmet. Wir haben mit 10 bis 20 Sekunden pro Abfrage begonnen. Fritsch hat dann heute Mittag beschlossen, die Indizes auf ein anderes Format zu ändern. Weg von BTREE hin zu HASH. Auch wenn das laut MySQL 5.0-Referenz gar nicht geht, hat uns das etwa eine Vervierfachung der Geschwindigkeit gebracht auf etwa 4 Sekunden.

Bisher hatten wurde ein View eingesetzt, der für alle Stadt-Kombinationen den Abstand berechnen konnte. Die Städte wurden dann per WHERE in der Abfrage eingeschränkt. Dumm nur, das die Abstandsberechnung recht aufwändig ist, weil sie 6 trigonometrische Funktionen auf einmal durchführt. Offenbar wurden die für jede Zeile berechnet, auch wenn die Zeile am Ende nicht ausgegeben wurde.

Deshalb habe ich mich heute abend nach fritschs “Ich waterboarde mich selbst”-Aktion nochmal hingesetzt und eine Stored Procedure geschrieben, die zunächst 2 Tabellen erzeugt, in denen jeweils die Daten zu den beiden eingegebenen Städten stehen und erst dann eine Berechnung durchführt. Damit bin ich jetzt auf unter 0,5 Sekunden runter, was durchaus akzeptabel ist. Interessanterweise macht es auch praktisch keinen zeitlichen Unterschied, ob ich mir die Entfernungen von Bremen nach Heidelberg ausgeben lasse oder alle Entfernungen von Bre* nach Hei*. Obwohl das 125 Zeilen mehr ergibt.

Ein paar Probleme gibts aber doch noch:

P.S.: Wie man Stored Procedures in MySQL schreibt, habe ich mir in diesem Tutorial angeeignet.

Kommentare

Schreibe einen Kommentar