[PostNAS] Empfehlung Hardware

[Jäger, Frank (KRZ)]

Hallo,
die PostgreSQL/PostGIS-DB ist bei der Hardware eigentlich sehr bescheiden.

Vor 1 ½ Jahren haben wir unsere GDI komplett umgebaut. Der Datenbankserver läuft seitdem als eigene "Virtuelle Maschine" mit Debian GNU Linux.
Er hat 2 GB Speicher und 2 (virtuelle) Prozessoren. Das reicht für das Web-GIS im internen Gebrauch in 14 Städten und Gemeinden.
Der Plattenspeicher liegt auf einem zentralen Storage.

Davor hatten wir 7 Jahre lang die komplette GDI für die 14 Städte auf einer einzigen "physischen" Maschine. Das war noch ein 32-Bit-System.
Darauf liefen alle Komponenten der GDI gemeinsam: Datenbank, Services (WMS: Mapserver, WFS: GeoServer), Client (Mapbender), CMS-Portal (CMSimple) und PHP-Scripte für Auskunft.
Als Platten wurde ein SCSI-RAID verwendet.
Die Leistung war immer noch ausreichend. Wir haben das ausgewechselt, weil die Hardware nicht mehr in der Wartung war.

Fazit: Keine besonderen Ansprüche an die Hardware.


> vor allem beim Skript "pp_laden.sql"

Das ist auch hier ein Engpass. Bei der monatlichen Verarbeitung der Differenzdaten der Städte braucht die Nachverarbeitung (SQL) deutlich mehr Zeit als die eigentliche Konvertierung (PostNAS).
Sie sollten mal schauen, ob sie alle dort ausgeführten Schritte tatsächlich benötigen.
Die im Script aufbereiteten Tabellen werden im WMS, in der Buchauskunft und in der Mapbender-Navigation verwendet.
Wenn sie nicht alle diese Komponenten verwenden sondern z.B. die Norbit-QGIS-Version, dann brauchen sie nur Teile des Scriptes.

Beispiel: Im ALKIS gibt es auf einer Flurstücksgrenze (Linie) die zusätzlichen Bedeutungen Flurgrenze, Gemarkungsgrenze, Gemeindegrenze.
Dies kann in den üblichen Maßstäben der Liegenschaftskarte (1:500 - 1:5000) zugeschaltet werden.
In unserem WMS ist das die Layer-Gruppe "Grenzen" (Darstellung Magenta, gestrichelt).

Es erschien mir aber nicht sinnvoll, diese Zusatzbedeutungen auch in einer Übersichtskarte bei 1:100.000 oder 1:50.000 schon darzustellen.
Die Grenze einer Gemeinde würde aus Tausenden von Linienstücken zusammen gesetzt.
Es fehlt in ALKIS aber so etwas wie ein "Flächenobjekt Gemarkung", dass man als Übersicht verwenden kann.

Das Script "pp_laden.sql" enthält den Versuch, solche Flächenobjekte in den Tabellen "pp_flur", "pp_gemarkung" und "pp_gemeinde" zu bilden.
Dazu werden die Flurstücksflächen schrittweise zu Flur-, dann zu Gemarkungs- und schließlich zur Gemeindefläche zusammen gefasst und im Hinblick die Nutzung als "Übersichtskarte für kleine Maßstäbe" geometrisch vereinfacht (st_simplify).
Dieses Script läuft nicht ganz fehlerfrei. Manchmal treten Geometriefehler auf.
Unschön dabei ist auch, dass mitgelieferte "Randstreifen" um das eigentliche Auswertungsgebiet zu unvollständigen Gebieten zusammen gesetzt werden.

In unserer Demo-Anwendung http://map.krz.de/alkis/mapbender.php ist das die Layer-Gruppe "Gebiete" (Darstellung grün) , die aus diesen Tabellen gefüttert wird. Das ist etwas redundant zu der Layer-Gruppe "Grenzen", ist aber eben für einen anderen Maßstabsbereich optimiert.

Wenn sie auf die "Übersicht Flur/Gemarkung/Gemeinde" der Gruppe "Gebiete" im Kartendienst verzichten können, dann können sie einige Teile des SQL-Skriptes deaktivieren und haben dann einige Laufzeit eingespart.
Die Tabellen pp_flur, pp_gemarkung, pp_gemeinde werden allerdings auch in der Mapbender-Navigation verwendet um die Hierarchie "Gemeinde -Gemarkung - Flur - Flurstück" abzubilden. Die Tabellen sollten also nicht komplett entfernt werden, nur die Geometrie darin kann leer bleiben.

Ein anderer Ansatz zur Optimierung:

Das Füllen der Tabelle "pp_flurstueck_nr" im Script "pp_laden.sql" hat in der alten Version (über "alkis_beziehungen") für eine Stadt etwa 4 bis 18 Sek. gedauert. Nach der Umstellung auf Relationen-Spalten hat sich dies vervielfacht.
Ich habe versucht, dies durch zerlegen in 3 Einzelschritte zu optimieren, das ist jedoch bisher nicht gelungen. Die alte Version ist als Kommentarblock noch sichtbar.
Der Schritt 2 von 3 ist kommentiert mit "-- Dies läuft sehr lange. Optimierbar?".
Ich hatte noch nicht die Zeit, da mal tiefer einzusteigen, vielleicht fehlt nur ein Index.
Es kann ja mal wer anderes drüber schauen und analysieren wo das Problem dabei liegt.

MfG
F. Jäger



Von: nas-bounces at lists.osgeo.org [mailto:nas-bounces at lists.osgeo.org] Im Auftrag von GIS (Landratsamt)
Gesendet: Montag, 17. November 2014 08:46
An: nas at lists.osgeo.org
Betreff: [PostNAS] Empfehlung Hardware

Hallo,

unter welcher Hardwareumgebung läuft Eure Postnas- Datenbank.
Könntet Ihr mir ein paar Tipps geben:

-          Speicher

-          Prozessor

Ich merke die Auslastung vor allem beim Skript "pp_laden.sql", dass ich nach dem Datenimport ausführe.


Vielen Dank für Eure Hilfe.

Mit freundlichen Gruessen
Wolfgang Escherl

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.osgeo.org/pipermail/nas/attachments/20141117/559f86b9/attachment-0001.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 7599 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.osgeo.org/pipermail/nas/attachments/20141117/559f86b9/attachment-0001.bin>