norBIT / alkisimport

ALKIS-Import
http://www.norbit.de/68/
GNU General Public License v2.0
28 stars 17 forks source link

nicht linearer Verlauf der Importzeiten bei großen Datensätzen #14

Closed ruhri closed 7 years ago

ruhri commented 7 years ago

Ich habe festgestellt, dass bei großen Datensätzen die Import-Dauer unverhältnismäßig zunimmt.

Einzelimporte - immer Vollabgaben - laufen auf performanter Hardware insgesamt sehr zügig durch. Werden 15 Ämter auf einmal importiert, skaliert auch der reine DB-Import (ogr2ogr) optimal mit der Datenmenge im Vergleich zur Datenmenge bspw. eines Amtes. Das Aufbereiten der Daten (nachgelagerte SQL-Skripte) dauert allerdings unverhältnismäßig länger. Bis zu bestimmten Datenmengen skaliert das "Postprocessing" noch gut, ab einer bestimmten Menge läuft es zeitlich sehr aus dem Ruder.

EDIT 20.02. (Aktualisierung der u.g. Zahlen) Amt / Datenmenge der Vollabgabe / Dauer des kompletten Imports: Mülheim a.d Ruhr (3,5 GB): 14 min. Wesel (29 GB): 204 min. Mülheim a.d Ruhr, Duisburg, Oberhausen, Bottrop (zus. 33 GB): 482min. Mülheim a.d Ruhr, Wesel, Duisburg, Oberhausen, Bottrop (zus. 62 GB): 1.097 min. alle 15 Ämter im Ruhrgebiet (175 GB): 9.500 min (ca. 6,5 Tage)

Die Hausnummern (Konsolenausgabe: "Gebäudehausnummern...") scheinen einen "problematischen" Part darzustellen, denn dort "steht" der Prozess (15 Ämter, s.o.) seit etwa 49h. Vor eineinhalb Jahren ist ein vergleichbarer Import aller Ämter gelaufen; dort hat der Part, der wohl auch die Gebäudehausnummern enthält (alkis-ableitungsregeln.sql?) insgesamt nur 26h auf schwächerer Hardware benötigt (Import-Version: 287fce5). Kann die Änderung https://github.com/norBIT/alkisimport/commit/7f82ac20784ee14b2dba873e557935dfc8f25a15 vielleicht bei großen Datenmengen negative Auswirkungen haben? Diese ist nach dem letzte großen Import in den aktuell verwendeten Code eingeflossen und bezieht sich auf Hausnr....

ruhri commented 7 years ago

Bezogen auf obigen Eintrag habe ich die Änderung https://github.com/norBIT/alkisimport/commit/7f82ac20784ee14b2dba873e557935dfc8f25a15 testweise rückgängig gemacht. Ergebnis: sehr großer zeitlicher Gewinn beim Postprocessing!

Mülheim a.d Ruhr, Duisburg, Oberhausen, Bottrop (zus. 33 GB): 299 min. (anstatt 482min.) reines Postprocessing-Zeiten (ohne og2ogr, welcher jew. 62 min. beansprucht): 237min. (anstatt 420 min.)

--> das ist fast ein Halbierung der Postprocessing -Zeit aufgrund der o.g. 3 Zeilen SQL-Code in alkis-ableitungsregeln.sql! Sicherlich hängt das auch von der Datenmenge, der Hardware und der DB-Konfiguration ab... Ich bitte eine Rückänderung des Codes abzuwägen.

Näher Infos zu obigen Testadaten, die Anzahl der Objekte ist sicherlich aussagekräftiger als die NAS-Datenmenge:

ALKIS-Modellart | #Objekte -----------------+---------- DLKM | 2001479 NWABK | 1659923 DKKM500 | 1097529 DKKM1000 | 951847 NWDKOM | 596357 NWDKOMK | 451485 NWABKK5 | 68275