Kleine Kollateral-Erkenntnis: Man muss im Moment noch kein schlechtes Gewissen haben, wenn man eine neue Relation erstellt.
Wie Nop bereits geschrieben hatte, ist flate-nodes ein feature up die Node Daten in einer simplen Datei zu speichern. Postgresql ist eine generelle Datenbank, die mehr oder weniger beliebige Daten speichern kann. Das mach Postgres auch eigentlich sehr gut. Allerdings diese flexibilitaet kostet ein wenig overhead. Bei 2 Milliarden Nodes die inzwischen im Planet sind, addieren sich auch ein paar bytes overhead pro Node schnell zu sehr grossen Mengen.
Zum Glueck braucht man die volle Flexibilitaet von Postgres nicht fuer die das Speichern der Nodes fuer den slim mode. Fuer diesen speziellen Zweck weiss man das man lediglich die Koordinaten benoetigt (4 bytes latitude, 4 bytes longitude) und das man sie nur per node_id suchen muss. Weiterhin weis man das die gueltigen node_ids dicht gepackt sind.
Desshalb kann man relativ leicht eine “Spezial Datenbank” erstellen, was das “flat-nodes” feature ist. Es schreibt schlicht 8 byte (lat/lon) linear fuer alle IDs in eine grosse Datei. Da derzeit die hoechste Node_id bei ca 2506700000 liegt, ergibt das eine Datei groesse von ~19 GB. Die postgresql Datenbank dafuer benoetigt hingegen ueber 100GB wenn ich mich nicht taeusche.
Ausserdem benoetigt “flat-nodes” keine Indexe, da die position in der Datei eindeutig durch die node_id gegeben ist. Somit sind lookups O(1). Desweiteren durch die geringere Groesse der Datei, passt mehr davon in den ram cache, wodurch die Geschwindigkeit weiter steigen koennte.
Insofern wuerde ich jedem der einen vollen Planet importiert die Option flatnodes empfehlen!
Der haupt Kachelserver von Openstreetmap verwendet eine SSD um die osm2pgsql Datenbank zu speichern und hat damit sehr gute Erfahrung gemacht.
Seit May 2011 werkelt dort eine einzelne Intel 320 SSD mit 600 GB Groesse und enthaelt die komplette osm2pgsql Datenbank. Der Umstieg von 4 velociraptor in Raid 10 auf eine einzelne SSD hat einen riesigen Unterschied gemacht und die I/O Performance ist nun kaum noch ein Problem. Der Server faellt eigentlich nie mit den Updates zurueck und kann in fast allen Faellen die 16 cores fuers rendering voll auslasten (so fern genuegend Anfragen da sind).
Moderne SSDs wie die Samsung 840 pro, sind noch einmal deutlich schneller als die inzwischen “recht alte” Intel 320, und werden seit kurzem im zweiten rendering Server von osm.org eingesetzt, so wie fuer die Nominatim Datenbank.
“Write endurance” scheint fuer normale SSDs mit einer osm2pgsql Datenbank kein Problem zu sein. Die SSD in Yevaud laeuft nun sein zwei einhalb Jahren im Dauerbetrieb mit minutely diffs und hat bislang erst 5% der Schreibzyklen aufgebraucht. Das heist die SSD kann noch die 20 fache Menge an Schreibzyklen verkraften, bzw bei gleichbleibender Belastung wuerde sie theoretisch noch 40 - 50 Jahre halten!
Natuerlich verhaelt sich jede SSD ein wenig anders, und die relative ueberdimensionierung von 600GB und die Tatsache das es eine aeltere SSD mit 25nm Struktur ist duerfte dabei helfen. Andererseits erwartet wohl auch keiner das eine SSD tatsaechlich 50 Jahre hallten soll.
Insfoern sind mir bislang noch keine Indikatoren bekannt die darauf hinweisen das eine osm2pgsql Datenbank mit diffs SSDs schneller verschleisst als die typische Lebensdauer von herkoemlichen Festplatten von ca 5 Jahren.
Moeglicherweise wuerden sogar verhaeltnissmaessig “Schreibempfindliche” (und billige) SSDs wie die TLC SSD von Samsung (840 / 840 Evo), wenn man nicht gerade nur eine 64GB SSD verwendet, ausreichend durchhalten.
full ack… OCZ kann ich auch auf keinen Fall empfehlen. Ich hatte anfangs auch OCZ bei uns in der Firma eingesetzt und bei einigen PCs mächtig Probleme. Seit ich aber Intel-SSDs (und vereinzelt Corsair Force Series GS) einsetze, läuft alles absolut rund.
Auch Privat nutze ich nur noch Intels und Corsair-SSDs - auch hier: nie irgendwelche Probleme.
Vielleicht OT: Aber hast du für dich schon die Frage geklärt, ob du wirklich die gesamte Erde benötigst und nicht nur mit Europa auskommst?
Gruß Klaus
Auf die Ausfallsicherheit des RAID10 ggü. einer Einzelplatte wurde bewußt verzichtet? Gilt eine SSD heute als soviel zuverlässiger als eine klassische Festplatte? Wenn ich hier die Berichte über einzelne Marken lese, beginne ich zu zweifeln.
Gruß,
Zecke
Die Ausfallsicherheit ist durch den 2. Server gegeben. Da es in diesem Fall ja auch nicht so ist, das die Daten irgendwie wertvoll wären (sprich: geht die SSD kaputt wird sie ersetzt und die Daten neu importiert), spricht nicht wirklich was gegen die Lösung.
Generell sollte man auch nicht ausser acht lassen, dass SSDs sich in den letzten 3 Jahren von exotisch zu völlig mainstream entsickelt haben (und parallel dazu ist die Technik auch gereift), sprich dass Erfahrungen die ein paar Jahre alt sind, kaum mehr wirklich relevant sind.
Simon
Das ist realativ!
Habe gestern erst wieder eine ausgebaut - Beim runterfahren alle OK beim Hochfahren nur noch 2MB 
.
Leider gibt es bei den SSD nicht sowas wie s.w.i.f.t das Problem vorher ankündigen könnte - wenn der interne Controller ausfällt ist halt nur noch der Zwischenspeicher da fertig …
bei mir derzeit sogar ~370 GB. Ich hab allerdings mit --hstore-all importiert und das scheint mit ein Grund für die Probleme zu sein.
Yes, Sir 
Gruss
walter
DAS hört sich ja gut an! Also befinde ich mich auf dem richtigen Weg. Genau die “Write Endurance” machte mir ja am meisten Sorgen.
Nach dem, was ich mir inzwischen angelesen habe, kommt TLC für mich nicht in Frage. MLC ist akzeptabel und SLC auch nicht mehr so teuer.
Gruss
walter
ps: wäre es eventuell möglich, mir die postgresql.conf von Yevaud zukommen zu lassen (wenn die nicht schon irgendwo online steht)? Ein paar Kniffe sollten da schon zu sehen sein.
ja, ich möchte den ganzen Planeten. Nur damit kann ich verlässliche Auswertungen/Anwendungen machen, die nicht an ihre Grenzen stoßen.
Zudem werden die Daten im Laufe der Zeit immer “diffuser”, da die Diffs immer alle neuen und geänderten Daten des gesamten Planeten einbringen. Wenn man z.B. eine Hessen-DB aufbaut und dann mit Diffs loslegt, hat man 5 Minuten später alle Änderungen in Papua-Neuguinea drin, falls man nicht weitere Klimmzüge macht. Damit hab ich mich 2010/2011 rumgeschlagen und das will ich mir nicht mehr antun.
Den Planeten hatte ich ja auch schon seit Monaten aktiv, nur im osmosis/Snapshot-Schema und nicht im osm2pgsql-Schema.
Platz ist absolut kein Problem und es klemmt eigentlich nur beim Update per Diff-Files. “Früher” brauchte er etwa 20 Minuten für 1 Stunde Daten und jetzt braucht er dafür 2 Stunden - d.h. die DB hinkt immer mehr hinterher.
Entweder krieg ich das - mit eurer Hilfe - hin oder ist stelle wieder auf osmosis/snapshot um. Allerdings muß ich mich dann selber wieder um Sachen kümmern, die osm2pgsql “on the Fly” erledigt, wie den Umgang mit Multipoint-Relationen mit “Löchern”.
Gruss
walter
Ich hätte auch ein ungutes Gefühl, wenn alles auf einer einzigen ungespiegelten Platte liegt. Bei einer eventuellen Umfrage “Was sollen wir mit unserem Geld machen?” würde ich “SSD spiegeln” ankreuzen.
Gruss
walter
Hast Du vielleicht den Satz davor überlesen? (Hervorhebung von mir)
Wenn dessen Datenbank abraucht, ist das kein Drama, dann gibt’s halt (zweiter Server vernachlässigt) bis zum Neuaufbau keine neuen Kacheln. Beim primären Datenbankserver wäre das natürlich anders.
Wirklich kein Swift (ich spar mir mal die Punkte) bei SSD? Ich meine, ich hätte was anderes gelesen.
Ja, da bringt Swift auch nichts. Aber das kennen wir ja auch von den “richtigen” Platten.
Gruss
walter
Ein wenig schon. Aber das ist inzwischen geklärt.
Gruss
walter
ps: Damit das hier nicht untergeht: könnte postgresql.conf von Yevaud ganz gut gebrauchen.
Nachtrag: Die SSD, die bisher problemlos läuft, ist eine Kingston SV100S2 128GB.
Auf diesem Gebiet ist aber alles im Fluss und auch die Foren sind mit Vorsicht zu genießen: Da melden sich natürlich bevorzugt diejenigen, bei denen es Probleme gab, bei gängigen Typen eben deutlich mehr.
Es besteht eine gewisse Korrelation von höherem Preis zu Zuverlässigkeit, aber halt leider nicht zwingend.
Nachdem so schlecht über OCZ gesprochen wurde…
Hab ne 30 GByte OCZ Vertex seit Anfang 2009 in meinem Media Center PC im Einsatz und die läuft fast täglich und immer noch ganz problemlos. CrystalDiskInfo Zustand aktuell 93%
Auf meinem Hauptrechner habe ich ne Intel 30 GByte SLC SSD Systemplatte + Vertex Datenplatte drinnen (seit 2010). Die laufen auch noch ganz problemlos.
Wobei die Intel einmal Probleme gemacht hat - Ursache war das SATA Kabel.
Die Intel SSD hat allerdings einiges an Performance eingebüßt. Sie unterstützt kein Trim und hat kein “Garbage collection” wie die Vertex.
Die Performance der Vertex ist noch wie neu.
Nicht alle SSDs von OCZ sind schlecht und die Problemursache kann zT auch wo anders liegen (schlechte SATA Kabel).
Wichtig ist auch die SSD groß genug zu dimensionieren. SSDs sollte man nicht bis “zum Rand” voll machen.
Aktuell würde ich mir wohl entweder eine OCZ Vector oder eine Samsung 840 Pro kaufen.
Und damit aus einer sehr frühen Serie, in der die Qualität noch passte… Liest man die Erfahrungsberichte im Internet, so hat sich die Qualität von OCZ kontinuierlich verschlechtert.
Verschaff Dir selbst ein Bild und wirf einen Blick ins oben verlinkte OCZ-Forum, gerade die aktuellen Vertex- und Agility-Serien sind katastrophal und definitv keine Arbeitsgeräte!
Ich schätze mal, daß sich der Einsatz einer SSD in einem Media-Center wohl etwas von meiner geplanten Nutzung unterscheidet.
Auch bei den Festplatten gibt es ja Unterschiede zwischen den verschiedenen Anwendungen, die sich auch in den Preisen niederschlagen:
z.B. 1000GB Seagate Video 3.5 HDD ST1000VM002 für ca 54€ und dagegen 1000GB Seagate Enterprise Value HDD / Terascale HDD ST1000NC001 für ca 81€ beim gleichen Händler.
einmal Videos schnell abspielen und dagegen 24/7/365 Dauerbetrieb im Server.
Gruss
walter
Hab mir mal die ersten Auswertungen angesehen und hab da schon einen Kandidaten:
planet2=# select indexrelname,
idx_scan,
idx_tup_read,
idx_tup_fetch
from pg_catalog.pg_stat_user_indexes
where indexrelname like 'planet%'
order by idx_scan desc;
indexrelname | idx_scan | idx_tup_read | idx_tup_fetch
-------------------------------+----------+--------------+---------------
planet_osm_nodes_pkey | 41794098 | 40819507 | 361623
planet_osm_ways_pkey | 3691033 | 4113560 | 2145667
planet_osm_rels_parts | 1703546 | 982071 | 0
planet_osm_point_pkey | 1506524 | 104570 | 103328
planet_osm_ways_nodes | 1303080 | 402152 | 0
planet_osm_polygon_pkey | 442874 | 64867 | 42190
planet_osm_roads_pkey | 442760 | 91993 | 72423
planet_osm_line_pkey | 442760 | 655940 | 424225
planet_osm_rels_pkey | 58035 | 84276 | 54548
planet_osm_polygon_index | 560 | 6078783 | 215223
planet_osm_point_index | 205 | 218481 | 70466
planet_osm_roads_index | 103 | 8559 | 7386
planet_osm_ways_idx | 15 | 375353 | 196279
planet_osm_rels_idx | 15 | 49990 | 25454
planet_osm_line_index | 0 | 0 | 0
planet_osm_roads_tags_index | 0 | 0 | 0
planet_osm_point_tags_index | 0 | 0 | 0
planet_osm_polygon_tags_index | 0 | 0 | 0
planet_osm_line_tags_index | 0 | 0 | 0
(19 rows)
planet2=# \di+ planet_osm_nodes_pkey
List of relations
Schema | Name | Type | Owner | Table | Size | Description
--------+-----------------------+-------+----------+------------------+-------+-------------
public | planet_osm_nodes_pkey | index | postgres | planet_osm_nodes | 43 GB |
(1 row)
sind natürlich erstmal ziemlich grobe Eindrücke, aber planet_osm_nodes_pkey ist mein Spitzenkandidat.
Das deckt sich wohl in etwa mit dem Flatfile, wo ja genau die gleichen Daten der Nodes drin stehen sollen. Muß ich aber noch checken.
Sollte das flatfile wohl aktivieren. planet_osm_nodes ist riesig und der index ist auch net gerade klein. Ich hoffe nicht, dass das einen Re-Import mit osm2pgsql bedeutet 
Danke & Gruss
walter
ps: jetzt bekommt planet_osm_nodes_pkey erst einmal seine “eigene” Platte (noch nicht ssd), da ich noch eine fast unbenutzte 80 GB-Platte rumliegen habe.