DE:PostgreSQL

PostgreSQL (postgresql.org), ehemals Postgres, ist ein OpenSource RDBMSysem (relational database management system). Seit API v0.6 wird es für die zentrale Datenbank auf OSMF-Hardware verwendet. Für technische Details, wie dies bewerkstelligt werden kann, informieren sie sich weiter über The Rails Port und Database Schema.

Inhaltsverzeichnis

Geospezifische Funktionen

Die PostGIS Erweiterung für PostgreSQL wird oft für Geo-Daten verwendet. PostGIS fügt also geospezifische Funktionen und Datentypen PostgreSQL hinzu. Wir verwenden PostGIS aber nicht für unsere Kerndatenbank, sondern für die Datenbank, welche für das Mapnik rendering Programm erforderlich ist.

Es existieren eine Vielzahl an Programmen, welche OSM Daten importieren und in eine PostgreSQL/PostGIS Datenbank einpflegen können. Die meist genutzen sind:

• osm2pgsql Umwandlung der planet.osm Daten in ein anderes Format.
• Imposm Ist ein PostGIS Importierer welcher DB-Schemas ünterstützt. Kann kleine Planet Files importieren.
• Osmosis Kann verwendet werden um eine Datenbank aus Planet.osm zu erstellen.
• osm2pgrouting Importiert eine PostgreSQL/PostGIS Datenbank für Reiserutenerstellung.

Optimieren der Datenbank

Da wir große Datenmengen verwalten, wurde es ratsam Postgres dahingehend etwas zu modifizieren. Die Standardeinstellungen sind etwas langsam was das Verarbeiten der Datenmengen angeht. Das Folgende ist nur ein kleiner Überblick an welche Einstellungen gedacht werden sollte, bei einer Optimierung (Weiterführendes : Dokumentation). Bitte beachte das der Restliche Teil eines System (auch Webserver) auch Speicher benötigt um eine flüssige Performanca zu gewährleisten. Des weiteren muss die Datei postgresql.conf angepasst erden. Zu finden sollte diese sein in /etc/postgresql/<version>/main oder /var/lib/pgsql/data, abhängig vom OS. Nach Änderungen muss das System neugestartet werden. Auf den meisten Systemen kann 'systemd' verwendet werden:

sudo systemctl restart postgresql

Speicherverbrauch

shared_buffers = 4GB

Setzt den Speicherverbrauch, welcher für die temporäre Datenspeicherung verbraucht werden darf. Mehr heist in diesem Fall nicht gleich besser. osm3pgsql unter PostgreSQL braucht auch Speicherplatz, welcher dann nicht zur Verfügung steht. Für ein System mit 4-8GB Ram ist eine Speicherreservierung von 1GB sinnvoll, in einem System von 32GB 2GB und 4GB bei noch größerem Arbeitsspeicher.

maintenance_work_mem = 10GB
autovacuum_work_mem = 1GB

(Diese Übersetzung ist aus dem englischen und nicht wörtlich. Für Genaueres bitte den Orginaltext zurate ziehen.)

maintenance_work_mem ist die Speichergröße welche beim Erstellen von Indexen von osm2pgsql benötigt werden darf. Je mehr Speicher, desto schneller werden die Indexe nach dem Import erstellt. Danach wird der größte Teil des Speichers freigegeben.

autovacuum_work_mem ist der Speicher welcher von postgres verwendet wird um im Hintergrund die Datenbank sauber zu halten. Standardmäßig wird hier der gleiche Speicher verwendet, welcher auch maintenance_work_mem zur Verfügung steht. PostgreSQL verwendet mehrere Threads für diese Aufgabe. Der Speicher, welcher jedem Thread zur Verfügung steht, ist immer gleich. Folglich sollte sichergestellt werden, das bei einer Änderung des maintenance_work_mem auch bei Auautovacuum_work_mem ein niedriger Wert eingestellt ist, um das System nicht zu überlasten.

work_mem = 256MB

Diese Einstellung bezieht sich auf den Speicherverbrauch bei einer ORDER BY für welche kein Index vorhanden ist und berechnet werden muss. osm2pgsql verarbeitet Daten für diese Berechnung. Dazu ist die Standardeinstellung zu niedrieg eingestellt, was berichtigt werden muss. Die Arbeitsweise von work_mem ist die gleiche wie maintenance_work_mem.

Checkpointing

Checkpoints sind Zeitpunkte in welchen PostgreSQL zwischenspeichert. Die Häufigkeit dieser Zeitpunkte kann konfiguriert werden. Checkpointing ist Speicherintensiv, was bedeutet je weniger Checkpoints desto schneller das System.

Bei einem Systemabsturz muss PostgreSql alle Daten unter Zuhilfenahme der WAL Datei (write-ahead logs) seit dem letzten Checkpoint erneut berechnen. Je weiter die Checkpoints also auseinander liegen, desto länger dauert die Neuberechnung im Fehlerfall und desto mehr Speicher muss für WAL-Files bereigestllt werden.

checkpoint_timeout = 10min
max_wal_size = 20GB

Es giebt zwei Parameter um die Checkpoints zu beeinflussen. checkpoint_timeout steht für die Zeitspanne zwischen Checkpunkten und max_wal_size beinhaltet die maximale Größe, welche die WAL-Datei annehmen kann bevor ein neuer Checkpunkt erreicht wird. Um die ideale Einstellung der Parameter zu finden muss mit diesen experimentiert werden. Es ist ratsam in den postgres-log zu beachten:

LOG:  checkpoints are occurring too frequently (28 seconds apart)
HINT:  Consider increasing the configuration parameter "max_wal_size".

Als Faustregel gilt, der Speicher sollte so groß sein, das er in einem Zeitintervall nie zu 100% gefüllt wird.