Minimale HW-Anforderungen an aktuellen Planet in PostgreSQL

In meiner Erinnerung war es vor 5 Jahren noch möglich, den gesamten Planet OSM in einer PostgreSQL Datenbank mit einer normalen HDD aktuell zu halten. Jetzt habe ich einen Import des Planet (Nominatim Schema) auf einem Server (Ubuntu 16 LTS, Core i7-4770, 2x Enterprise SATA 2 HDDs, RAID 0, 32GB RAM, Postgres-Setting gemäß Nominatim-Doku) versucht, aber ich komme mit den Aktualisierungen nicht hinterher, jeden Tag wächst der Rückstand um ca. 1h.
Ich nehme mal an, dass ich nicht um eine SSD umhin komme. Reicht da eine oder muss es ein RAID 0 (ich weiß, das ist kein echtes RAID) sein? Und wie groß sollte die sein. Die DB ist bei mir jetzt 564 GB groß. Dazu kommt ja noch die Flatnode File beim Import. Wie groß wird die?

Bevor ich jetzt alle Server bei Hetzner nach oben durchprobiere, dachte ich, ich frage mal nach :slight_smile:

Ich nehme an, Du meinst mit osm2pgsql?
Raid 0 ist schon “echtes Raid”, nur halt nicht redundant, d.h. es vergrößert sich sogar das Risiko, durch Festplattenfehler einen Totalausfall zu haben. Welche diffs verwendest Du, minutely, hourly oder daily? Falls Du noch nicht bei daily bist, würde ich das versuchen.
Nach meinen Erfahrungen war es vor ca. 5 Jahren mit “einfacher” Hardware (ich damals 8GB RAM und 2 Platten 7200U/min) auch nicht möglich, den gesamten Planet aktuell zu halten, bzw. konnte man dann nur aktualisieren, aber nicht noch was anfangen mit den Daten (z.B. rendern) :wink:
Deine Hardware sieht für mich so aus, als könnte es damit evtl. schon gehen, als Alternative kannst Du regelmäßig (wöchentlich/ monatlich) einen Neuimport in eine neue db machen und dbs switchen (das muss man sowieso gelegentlich machen wegen “Fragmentation” (weiss nicht ob das der richtige Ausdruck ist)).

EDIT: Das bezieht sich allerdings auf eine Rendering db, zu Nominatim kann ich Dir nicht weiterhelfen (gerade erst bemerkt dass Du Nominatim genannt hast).

Welche Aktualität wird denn wirklich benötigt?

So aktuell wie möglich. Wenn man etwas in den Daten ändert und zwei Wochen warten muss damit es auf dem Server sichtbar ist, macht das keinen Spaß.

und weltweit muss auch sein? Weil ein Europaextrakt z.B. auch schon viel kleiner wäre. Wobei das dann mit den diffs ein bisschen komplizierter wird, am einfachsten wohl einfach die diffs der Welt einspielen und gelegentlich was ausserhalb liegt wegschmeissen.

Die Arbeit braucht man sich eigentlich nicht zu machen, Geofabrik bietet fertige Daily Updates für bestimmte Regionen an, z.B. http://download.geofabrik.de/europe-updates/ (das ist die Version mit abgespeckten Metadaten).

Ohne SSD hast du keine Chance.

Vor ca 3 Jahren hatte ich eine SSD nur für das Flat-File aber irgendwann reichte mir das nicht mehr.

Derzeit ist max(nodes) > 5.798.980.473, also rund 6 GB. Ich würde mal von 64 GB Flatfile ausgehen, sodass eine 128 GB SSD ausreichen könnte. Raid ist mMn dafür nicht so wichtig.

Besser wäre es natürlich, auch noch manche Indices auf SSD zu legen, aber das hat Zeit.

Da ich kein Flatfile mehr verwende, bringt dir meine aktuelle Konfiguration nix. https://wambachers-osm.website/index.php/technisches-umfeld Ich kann nur sagen “es flutscht” :wink:

Gruss
walter

Du meinst eine SSD nur für die Flatfile würde reichen und man könnte die DB auf zwei Spinning Disks lassen?

Das wäre zumindest ein Anfang. Aber nagel mich nicht darauf fest.

Gruss
walter

Meine osm2pgsql Instanz mit vielen zusätzlichen Indices und hstore und noch tonnenweise andere Daten braucht etwa 40% von einem RAID0 Array aus 2 480GB SSDs und würde auch auf eine passen (inklusive der Node Datei). Der Trick: ZFS mit Kompression.

Drücke ich mich immer noch vor :wink:

Da eine “gute” DB ja mit Tablespaces aufgesetzt wird, sollte es doch möglich sein, so nach und nach die entsprechenden Partionen auf ZFS umzustellen. Bin leider noch auf Ext4.

Mal sehen.

Gruss
walter