Einsatz von SSD für die Datenbank

Zecke · 2013-10-24 09:43:50

amm wrote:

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.

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

SimonPoole · 2013-10-24 10:26:37

Zecke wrote:

amm wrote:
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.
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

Last edited by SimonPoole (2013-10-24 10:27:23)

quasilotte · 2013-10-24 10:35:22

Zecke wrote:

amm wrote:
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.
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

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 ....

wambacher · 2013-10-24 10:48:34

amm wrote:

Die postgresql Datenbank dafuer benoetigt hingegen ueber 100GB wenn ich mich nicht taeusche.

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.

Insofern wuerde ich jedem, der einen vollen Planet importiert, die Option flatnodes empfehlen!

Yes, Sir

Gruss
walter

wambacher · 2013-10-24 11:09:18

amm wrote:

"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!

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.

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.

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.

wambacher · 2013-10-24 11:27:26

toc-rox wrote:

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?

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

wambacher · 2013-10-24 11:33:50

Zecke wrote:

amm wrote:
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.
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.

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

Oli-Wan · 2013-10-24 11:43:18

wambacher wrote:

Zecke wrote:
amm wrote:
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.
...
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.

Hast Du vielleicht den Satz davor überlesen? (Hervorhebung von mir)

amm wrote:

Der haupt Kachelserver von Openstreetmap verwendet eine SSD um die osm2pgsql Datenbank zu speichern und hat damit sehr gute Erfahrung gemacht.

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.

wambacher · 2013-10-24 11:43:31

quasilotte wrote:

Leider gibt es bei den SSD nicht sowas wie s.w.i.f.t das Problem vorher ankündigen könnte

Wirklich kein Swift (ich spar mir mal die Punkte) bei SSD? Ich meine, ich hätte was anderes gelesen.

- wenn der interne Controller ausfällt ist halt nur noch der Zwischenspeicher da fertig ....

Ja, da bringt Swift auch nichts. Aber das kennen wir ja auch von den "richtigen" Platten.

Gruss
walter

wambacher · 2013-10-24 11:47:53

Oli-Wan wrote:

Hast Du vielleicht den Satz davor überlesen? (Hervorhebung von mir)
amm wrote:
Der haupt Kachelserver von Openstreetmap verwendet eine SSD um die osm2pgsql Datenbank zu speichern und hat damit sehr gute Erfahrung gemacht.
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.

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.

Last edited by wambacher (2013-10-24 11:49:54)

seichter · 2013-10-24 16:06:11

wambacher wrote:

Kannst du mir sagen, welchen Hersteller du bevorzugst und welchen Typ du einsetzt?

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.

nesol · 2013-10-24 17:47:49

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.

free_as_a_bird · 2013-10-24 20:16:46

nesol wrote:

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.

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!

wambacher · 2013-10-24 21:02:35

free_as_a_bird wrote:

nesol wrote:
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.
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

wambacher · 2013-10-26 08:04:30

Augustus Kling wrote:

Sieh dir die Dokumentation unter http://www.postgresql.org/docs/9.3/stat … stats.html insbesondere zu pg_stat_user_indexes und pg_statio_user_indexes an. Damit solltest du dir ein Bild von der Wichtigkeit der Indizes für deine Abfragen machen können.

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.

Last edited by wambacher (2013-10-26 08:14:00)

Netzwolf · 2013-10-26 09:11:58

Moins,

ganz allgemein zu Datenbank, Index, Plattengeschwindigkeiten und SSD:

Über den Index finde ich schnell heraus, wo die gewünschten Datensätze liegen. Wenn die aber zufällig über eine große Tabelle verteilt sind, wird die Geschwindigkeit des Einsammelns nicht über die Transferrate der Disk, sondern über die Seek-Geschwindigkeit begrenzt. Und da ist die SSD absolut überlegen bis zu einem Faktor 100. Die Tabelle auf einer langsamen SSD kann deshalb schneller sein als auf einer schnellen Drehdisk.

Ich kenne mich mit der Einspielroutine nicht aus, daher weiß ich nicht, ob anwendbar: wenn die meisten Abfragen auf die Datenbank kleine Gebiete betreffen, kann es sinnvoll sein, die Node-Datensätze vor dem ersten Einspielen “geographisch” zu sortieren, z.B. nach Quadtree-Werten. Das erhöht die Lokalität, oft gemeinsam genutzte Nodes liegen meist nah beieinander, damit braucht es weniger Seeks und die Geschwindigkeit geht hoch. Ohne zusätzliche Hardware.

Gruß Wolf

wambacher · 2013-10-26 09:53:04

Netzwolf wrote:

Ich kenne mich mit der Einspielroutine nicht aus, daher weiß ich nicht, ob anwendbar: wenn die meisten Abfragen auf die Datenbank kleine Gebiete betreffen, kann es sinnvoll sein, die Node-Datensätze vor dem ersten Einspielen “geographisch” zu sortieren, z.B. nach Quadtree-Werten. Das erhöht die Lokalität, oft gemeinsam genutzte Nodes liegen meist nah beieinander, damit braucht es weniger Seeks und die Geschwindigkeit geht hoch. Ohne zusätzliche Hardware.

Bei Projekten mit dem osm2pgsql-Schema sind zwei verschiedene Aspekte zu beachten:
- Aufbau und Update der globalen Datenbank
- Benutzung der Datenbank für GIS-Anwendungen

Punkt 1 kann keinerlei geographische Indices verwenden, da die Updates in aufsteigender Reihenfolge nach OSM-IDs geortnet sind und diese Updates völlig zufällig über den ganzen Planeten verteilt sind. 1x Paris,Texas und gleich darauf Papua-Neuguinea und dann Glabotki-Mitte.

Für Punkt 2 werden selbstverständlich geographische Indices aufgebaut und auch verwendet. So hat z.B. die Tabelle planet_osm_point, die alle wichtigen POI enthält, einen spatialen Index. Andere Tabellen ebenso.

planet2=# \d planet_osm_point

            Table "public.planet_osm_point"
       Column       |         Type         | Modifiers 
--------------------+----------------------+-----------
 osm_id             | bigint               | 
 access             | text                 | 
 addr:housename     | text                 | 
 addr:housenumber   | text                 | 
---snip---
 tags               | hstore               | 
 way                | geometry(Point,4326) |                                <-----------
 traffic_sign       | text                 | 
Indexes:
    "idx_point_admin_level" btree (admin_level) WHERE admin_level <> ''::text, tablespace "tablespace2"
    "idx_point_place" btree (place) WHERE place <> ''::text, tablespace "tablespace3"
    "idx_point_postcode" btree ("addr:postcode") WHERE "addr:postcode" <> ''::text, tablespace "tablespace2"
    "idx_point_traffic_sign" btree (traffic_sign) WHERE traffic_sign <> ''::text, tablespace "tablespace3"
    "planet_osm_point_index" gist (way), tablespace "tablespace2"           <----------
    "planet_osm_point_pkey" btree (osm_id), tablespace "tablespace3"
    "planet_osm_point_tags_index" gin (tags), tablespace "tablespace2"
Tablespace: "tablespace4"

hier "planet_osm_point_index" gist (way) , wobei way die Koordinaten enthält. Dadurch wird bei der Auswertung (Karte) viel an Durchsatz gewonnen.

tl;dr: Mit Bordmitteln ist schon fast alles ausgereizt, die Hardware muß einfach schneller werden.

Gruss
Walter

Netzwolf · 2013-10-26 10:31:17

Nahmd,

wambacher wrote:

Für Punkt 2 werden selbstverständlich geographische Indices aufgebaut und auch verwendet. So hat z.B. die Tabelle planet_osm_point, die alle wichtigen POI enthält, einen spatialen Index.

Natürlich gibt es diesen Index.

Ich sprach aber von der Tabelle, dem Speicher für die Datensätze. Da liegen die Nodes (vor dem ersten Update) in der Reihenfolge des Einspielens. Wenn in OSM-Id-Reihenfolge eingespielt, geographisch weitgehend zufällig. Führt dazu, dass der Index 1000 Fundstellen meldet, die über 20Gb verteilt sind. Heißt: 1000 Seeks. Heißt: warten.

Sortiert man die Nodes vor dem Einspielen um, liegen geographisch nahe Punkte mit hoher Wahrscheinlichkeit auch auf der Disk nahe beieinander, das erspart Seeks und der Zugriff kann signifikant schneller werden.

Natürlich geht diese Ordnung mit den Updates langsam verloren; das aber kann man mit einem Reorganisationslauf beheben.

Ich hab mit diesem Vorgehen in der Vor-SSD-Zeit eine lahme Anwendung in eine "jede Anfrage mit 2 Diskzugriffen beantwortet" umgebaut. Weil es da aber um eine "N×M" Zuordnung ging, also über jeweils eine von zwei Spalten gesucht wurde, die Tabelle verdoppelt, eine physisch nach N, eine phsisch nach M sortiert. Geht natürlich nur, wenn man ein Zeitfenster für die Reorganisationsläufe hat.

Just my 2.38¢.

Gruß Wolf

wambacher · 2013-10-26 10:51:35

Netzwolf wrote:

Nahmd,
Ich sprach aber von der Tabelle, dem Speicher für die Datensätze. Da liegen die Nodes (vor dem ersten Update) in der Reihenfolge des Einspielens. Wenn in OSM-Id-Reihenfolge eingespielt, geographisch weitgehend zufällig. Führt dazu, dass der Index 1000 Fundstellen meldet, die über 20Gb verteilt sind. Heißt: 1000 Seeks. Heißt: warten

alle klar. Das Kind nennt sich bei PostgreSQL Cluster - nicht zu verwechseln mit einem Database Cluster.

Das Clustern von Tabellen ordnet die Daten passend zum Index an. Nimmt man dazu den Spatialen Index, so liegen räumlich nahe Daten auch auf der Platte eng beieinander. Das Clustern wurde automatisch beim Import der Rohdaten gemacht und sollte ab und zu mal neu angestoßen werden.Das Blöde ist nur: so ein Clustern lockt die Tabelle exklusiv, braucht ca den 3-fachen Plattenplatz der Tabelle und dauert ewig (Tage!) Während dieser Zeit ist die Anwendung down, wenn man nicht mit Kopien arbeitet - also noch mehr Platz braucht. Updates müssen dann auch warten.

Gruss
walter

Nop · 2013-10-26 12:38:57

wambacher wrote:

Das Blöde ist nur: so ein Clustern lockt die Tabelle exklusiv, braucht ca den 3-fachen Plattenplatz der Tabelle und dauert ewig (Tage!) Während dieser Zeit ist die Anwendung down, wenn man nicht mit Kopien arbeitet - also noch mehr Platz braucht. Updates müssen dann auch warten.

Hm, ich hab das kürzlich eingeführt, läuft bei mir ca. 90 Minuten. Die Datenmenge ist hier geringer, habe einen Großteil von Europa drin, aber auch hochgerechnet auf einen Planet komme ich nicht auf Tage. Liegt aber auch auf einer SSD und Hauptspeicher ist reichlich vorhanden.

bye, Nop

Netzwolf · 2013-10-26 13:42:05

Nahmd,

wambacher wrote:

alle klar. Das Kind nennt sich bei PostgreSQL Cluster - nicht zu verwechseln mit einem Database Cluster.
Das Clustern von Tabellen ordnet die Daten passend zum Index an. Nimmt man dazu den Spatialen Index, so liegen räumlich nahe Daten auch auf der Platte eng beieinander. Das Clustern wurde automatisch beim Import der Rohdaten gemacht und sollte ab und zu mal neu angestoßen werden.

Ich nehme alle Vorschläge mit dem Ausdruck größten Bedauerns zurück und stelle hiermit fest: Du machst alles perfekt richtig und solltest keinesfalls irgendetwas ändern.

Gruß Wof

Das Blöde ist nur: so ein Clustern lockt die Tabelle exklusiv, braucht ca den 3-fachen Plattenplatz der Tabelle und dauert ewig (Tage!) Während dieser Zeit ist die Anwendung down, wenn man nicht mit Kopien arbeitet - also noch mehr Platz braucht. Updates müssen dann auch warten.

wambacher · 2013-10-27 11:20:32

Nop wrote:

Flatfile ist ein neueres Feature und cached die Koordinaten der Nodes in einer simplen Datei anstatt in der Datenbank. Viel weniger Platzverbrauch, viel schnellerer Zugriff und auf einer SSD rockt das. :-)

amm wrote:

Insofern wuerde ich jedem der einen vollen Planet importiert die Option flatnodes empfehlen!

So, ich habe auf flatfile umgestellt ohne neu zu importieren (*).

Dadurch wurde aus einer 370GB großen planet_osm_nodes + 49 GB Index ein 20 GB großes Flatfile. Das liegt jetzt auf der gleichen Platte wie die WAL-Files und die ist damit zu bis zum Anschlag ausgelastet. SSD wird heute gekauft. 64 GB sollten dafür reichen. done.

vielen Dank an die Kollegen für die wertvollen Tips.

Gruss
walter

*) ich habe dazu einen osm2pgsql-Patch reaktiviert, der ein Tool dafür zur Verfügung stellt. siehe http://gis.19327.n5.nabble.com/template … ser=339234 und ff.
Kurzfassung: Der Tool liest planet_osm_nodes und macht da ohne Umwege ein Flatfile raus. Laufzeit für über 2 Milliarden Datensätze ca 2 Stunden!
Flatfile aktivieren, planet_osm_nodes truncaten, vacuum full planet_osm_nodes, feddich.

Last edited by wambacher (2013-10-27 23:40:19)

Announcement

#26 2013-10-24 09:43:50

Re: Einsatz von SSD für die Datenbank

#27 2013-10-24 10:26:37

Re: Einsatz von SSD für die Datenbank

#28 2013-10-24 10:35:22

Re: Einsatz von SSD für die Datenbank

#29 2013-10-24 10:48:34

Re: Einsatz von SSD für die Datenbank

#30 2013-10-24 11:09:18

Re: Einsatz von SSD für die Datenbank

#31 2013-10-24 11:27:26

Re: Einsatz von SSD für die Datenbank

#32 2013-10-24 11:33:50

Re: Einsatz von SSD für die Datenbank

#33 2013-10-24 11:43:18

Re: Einsatz von SSD für die Datenbank

#34 2013-10-24 11:43:31

Re: Einsatz von SSD für die Datenbank

#35 2013-10-24 11:47:53

Re: Einsatz von SSD für die Datenbank

#36 2013-10-24 16:06:11

Re: Einsatz von SSD für die Datenbank

#37 2013-10-24 17:47:49

Re: Einsatz von SSD für die Datenbank

#38 2013-10-24 20:16:46

Re: Einsatz von SSD für die Datenbank

#39 2013-10-24 21:02:35

Re: Einsatz von SSD für die Datenbank

#40 2013-10-26 08:04:30

Re: Einsatz von SSD für die Datenbank

#41 2013-10-26 09:11:58

Re: Einsatz von SSD für die Datenbank

#42 2013-10-26 09:53:04

Re: Einsatz von SSD für die Datenbank

#43 2013-10-26 10:31:17

Re: Einsatz von SSD für die Datenbank

#44 2013-10-26 10:51:35

Re: Einsatz von SSD für die Datenbank

#45 2013-10-26 12:38:57

Re: Einsatz von SSD für die Datenbank

#46 2013-10-26 13:42:05

Re: Einsatz von SSD für die Datenbank

#47 2013-10-27 11:20:32

Re: Einsatz von SSD für die Datenbank

Board footer