Einsatz von SSD für die Datenbank

wambacher · 2013-10-23 12:50:07

Hi,

ich schlage mit massiven Performance-Problemen bei meiner Postgresql-Datenbank rum.
Habe -leider- auf osm2pgsql umgestellt und die Updates per Diff sind so langsam, daß das Lag von derzeit 11 Tagen so nie und nimmer abgebaut wird.

Hab einen nicht geraden kleinen Server und meine, daß ich PostgreSQL wohl großzügig konfiguriert habe. Ich sehen aber einen IO-Engpass (viele Waits) bei den Platten. Derzeit verteile ich die Indices auf mehrere Laufwerke und erhoffe mir davon einige Verbesserungen

Frage: Hat jemand praktische Erfahrungen mit SSD im Datenbankbereich?

Klar, eine 64GB oder 128 GB SSD einbauen und die Indices drauflegen, ist ja kein Problem. Das kriegt ich gerade noch so hin
Aber was ist mit der Stabilität? Indices werden sehr oft geschrieben und ich habe Sorgen mit der maximalen Anzahl an Schreibvorgängen bei SSD. Ich möchte schon, daß die mehrere Jahre durchhalten.

Für Tips in diese Richtung (Stabilität/Robustheit) würde ich mich freuen. Gute Quellen zum Kaufen natürlich auch.

Gruss
walter

Nadjita · 2013-10-23 13:12:13

In meiner Firma betreiben wir seit mehreren Jahren die Hauptdatenbank mit SSDs. Allerdings ist der zu erwartende Geschwindigkeitsgewinn davon abhängig, wie schlecht Indices im Speicher gehalten werden können. In der Regel hilft eine Erhöhung des Hauptspeichers mehr als eine Umstellung auf SSDs. Sobald die Indices alle in den Hauptspeicher passen, ist die Geschwindigkeit der Platten (außer bei fast ausschließlich Updates und Inserts) nicht mehr stark der Flaschenhals. Deshalb würde ich eher darauf achten, dass die Indices alle in den Hauptspeicher passen als dass sie auf einer SSD liegen. Unsere Indices sind z.B. 47 GB groß, die Datenbank hat 72GB Hauptspeicher. I/O ist für uns kein Thema. Darf ich fragen, wie groß Deine Indices insgesamt auf der Festplatte sind und wie viel Speicher Du hast? Nutzt Du ein 64bit Betriebssystem?

Um den zweiten Teil der Frage zu beantworten: Wir nutzen diese Platten hier: Intel® SSD 710 Series 300GB, 2.5in SATA Ausfälle gab es noch nie, wir haben davon 8 Stück als raid 1+0 im Dauerbetrieb und die Datenbank langweilt sich definitiv nicht ;o)

wambacher · 2013-10-23 13:34:26

Nadjita wrote:

In meiner Firma betreiben wir seit mehreren Jahren die Hauptdatenbank mit SSDs. Allerdings ist der zu erwartende Geschwindigkeitsgewinn davon abhängig, wie schlecht Indices im Speicher gehalten werden können. In der Regel hilft eine Erhöhung des Hauptspeichers mehr als eine Umstellung auf SSDs.

Klar, aber bei 32GB ist bei "normalen" Motherboards halt Schluß - und die hat meiner.

Sobald die Indices alle in den Hauptspeicher passen, ist die Geschwindigkeit der Platten (außer bei fast ausschließlich Updates und Inserts) nicht mehr stark der Flaschenhals. Deshalb würde ich eher darauf achten, dass die Indices alle in den Hauptspeicher passen als dass sie auf einer SSD liegen. Unsere Indices sind z.B. 47 GB groß, die Datenbank hat 72GB Hauptspeicher.
I/O ist für uns kein Thema. Darf ich fragen, wie groß Deine Indices insgesamt auf der Festplatte sind und wie viel Speicher Du hast? Nutzt Du ein 64bit Betriebssystem?

Server: 8-Core AMD, 32GB Memory, 12 TB Disk, Ubuntu 13.10, 64 Bit.

Die Planet-DB ist "etwas" größer:

planet2# \d+
                           List of relations
 Schema |        Name        | Type  |  Owner   |  Size   | Description 
--------+--------------------+-------+----------+---------+-------------
...
 public | planet_osm_line    | table | postgres | 45 GB   | 
 public | planet_osm_nodes   | table | postgres | 374 GB  | 
 public | planet_osm_point   | table | postgres | 13 GB   | 
 public | planet_osm_polygon | table | postgres | 57 GB   | 
 public | planet_osm_rels    | table | postgres | 1369 MB | 
 public | planet_osm_roads   | table | postgres | 7188 MB | 
 public | planet_osm_ways    | table | postgres | 111 GB  | 
...

und die Indices sind auch noch da:

 public | planet_osm_line_index         | index | postgres | planet_osm_line    | 5070 MB | 
 public | planet_osm_line_pkey          | index | postgres | planet_osm_line    | 1842 MB | 
 public | planet_osm_line_tags_index    | index | postgres | planet_osm_line    | 13 GB   | 
 public | planet_osm_nodes_pkey         | index | postgres | planet_osm_nodes   | 43 GB   | 
 public | planet_osm_point_index        | index | postgres | planet_osm_point   | 2717 MB | 
 public | planet_osm_point_pkey         | index | postgres | planet_osm_point   | 1047 MB | 
 public | planet_osm_point_tags_index   | index | postgres | planet_osm_point   | 8223 MB | 
 public | planet_osm_polygon_index      | index | postgres | planet_osm_polygon | 6937 MB | 
 public | planet_osm_polygon_pkey       | index | postgres | planet_osm_polygon | 2464 MB | 
 public | planet_osm_polygon_tags_index | index | postgres | planet_osm_polygon | 13 GB   | 
 public | planet_osm_rels_idx           | index | postgres | planet_osm_rels    | 264 kB  | 
 public | planet_osm_rels_parts         | index | postgres | planet_osm_rels    | 946 MB  | 
 public | planet_osm_rels_pkey          | index | postgres | planet_osm_rels    | 47 MB   | 
 public | planet_osm_roads_index        | index | postgres | planet_osm_roads   | 463 MB  | 
 public | planet_osm_roads_pkey         | index | postgres | planet_osm_roads   | 166 MB  | 
 public | planet_osm_roads_tags_index   | index | postgres | planet_osm_roads   | 1521 MB | 
 public | planet_osm_ways_idx           | index | postgres | planet_osm_ways    | 2641 MB | 
 public | planet_osm_ways_nodes         | index | postgres | planet_osm_ways    | 94 GB   | 
 public | planet_osm_ways_pkey          | index | postgres | planet_osm_ways    | 9345 MB |

Um den zweiten Teil der Frage zu beantworten: Wir nutzen diese Platten hier: Intel® SSD 710 Series 300GB, 2.5in SATA Ausfälle gab es noch nie, wir haben davon 8 Stück als raid 1+0 im Dauerbetrieb und die Datenbank langweilt sich definitiv nicht ;o)

Uii, das sprengt wohl meinen Kostenrahmen - aber für ne Firma sind das wohl nur Peanuts.

Ich werde mir wohl nach und nach 1-3 SSD zulegen und die wichtigsten Indices (*) drauflegen aber ich hab immer noch ein ungutes Gefühl bezüglich der Robustheit.

Danke für deine Antwort
Gruss
walter

*) wie krieg ich die raus? Muß mich wohl mal mit Postgresql-Monitoring beschäftigen.

@all: die UK-Toolchain in England macht ja das gleiche: Diff-Files mit osm2pgsql in die Postgresql-DB einspielen. Bei denen flutscht das prima. Kann man sich die Configs bei denen ansehen? Klar, die verwendete Software ist im Download, aber was ist mit den Live-Configs?
Ich taste mich mal ran.

Last edited by wambacher (2013-10-23 13:35:05)

seichter · 2013-10-23 13:34:51

Ich verwende seit zwei Jahren SSDs als Systemplatte. Die Stabilität ist so eine Sache: Es kommt gelegentlich vor, dass alle paar Stunden ein Bluescreen auftaucht. Nach ein paar Tagen ist der Spuk dann wieder vorbei. Bei der ersten SSD trat es dann aber so häufig auf, dass ich sie (auch wegen der Größe) ausgemustert habe. Bei einer dritten (auf einem anderen Rechner) war bisher Ruhe. Auf dieser Grundlage möchte ich aber keine Aussage über heutige SSDs machen. In der IT ist ein Jahr fast eine Ewigkeit.
Bei SSD ist das Schreiben ganz klar der kritischere Vorgang. Trotz der Verteilung der Schreibvorgänge (wear leveling) ist irgendwann Feierabend, wenn das zu häufig passiert. Es kommt aber darauf an, wieviel geschrieben wird. Der Index-File einer DB wird ja nicht jedesmal komplett neu geschrieben, oft werden ja nur ein paar Hash-Werte hinzugefügt. Ich habe mich jedenfalls getraut, den swapfile auch auf die SSD zu legen, da es Untersuchungen gibt, dass auf den gar nicht so viel geschrieben wird, wie man eigentlich annimmt.
Bis die SSD dann den Geist aufgibt, gibt es vielleicht so viel schnellere, günstigere und größere Exemplare, dass ich froh bin, einen unwiderlegbaren Grund zum Wechsel zu haben
Zur Aussage von Nadjita: Natürlich ist RAM schneller (und unempfindlicher) als eine SSD. Jede DB-SW wird daher einen Teil des Index im RAM als Cache zu halten versuchen. Je mehr RAM, desto besser. Wenn der Index zu groß für RAM ist, kommt es auf das Verhältnis Lesen/Schreiben an. Die SSD kann ihre Vorteile (gegenüber HD) vor allem beim Lesen ausspielen.

wambacher · 2013-10-23 13:39:46

seichter wrote:

Bei einer dritten (auf einem anderen Rechner) war bisher Ruhe. Auf dieser Grundlage möchte ich aber keine Aussage über heutige SSDs machen. In der IT ist ein Jahr fast eine Ewigkeit.

Danke für die Info.

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

Der Index-File einer DB wird ja nicht jedesmal komplett neu geschrieben, oft werden ja nur ein paar Hash-Werte hinzugefügt.

Derzeit laß ich autovacuum ziemlich oft über die Tabellen und auch Indices huschen. vacuum analyze ist ja nur lesend und vacuum alleine schreibt ja auch die Indices nicht neu - glaub ich zumindest. Nur ein Rebuild oder vacuum full schreibt das Zeug neu.
Ich glaub, ich werde das mal riskieren. Datenfiles liegen auf einem Raid und wenn ein Index abfackelt, kann man den jederzeit neu aufsetzen - wenn man es kann

Gruss
walter

Last edited by wambacher (2013-10-23 13:46:48)

chris66 · 2013-10-23 13:45:48

Moinsen,
ich nutze seit ca. 1 Jahr eine 500GB SSD von Samsung in meinem Laptop.
Bisher ohne Probleme.

Grüße
Chris

seichter · 2013-10-23 13:57:20

wambacher wrote:

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

querbeet: OCZ Agility 60GB, Samsung 830 128, die dritte kann ich im Moment nicht nachsehen

Nop · 2013-10-23 14:53:37

wambacher wrote:

Frage: Hat jemand praktische Erfahrungen mit SSD im Datenbankbereich?

Ja, nutze auf meinem Kartenserver seit einigen Jahren nur noch SSDs für die Datenbank.

Geschwindigkeitsgewinn bei Datenbankoperationen ca. Faktor 5, wenn Du flatfile benutzt könnte es auch mehr sein, das gabs bei meiner Vergleichsmessung damals noch nicht.

Probleme gab es bisher keine. DB wird alle 3 Tage komplett importiert und Server ist permanent am Rendern. Wichtig ist daß Dein Kernel eine saubere TRIM-Unterstützung hat, muß evtl. dafür neu gebaut werden.

Evtl. fährst Du günstiger wenn Du 2 kleinere SSDs nimmst und zu einem virtuellen Laufwerk zusammenlegst, so ist mein Server konfiguriert.

bye, Nop

Zecke · 2013-10-23 15:11:28

Ich würde bei einer DB (zumindest Oracle) erwarten, daß es performancemäßig am meisten bringt, die Redo-Logs auf SSD zu verlagern, erst nachrangig die Daten oder die Indizes. Keine Ahnung wie das bei pgsql heißt.

Gruß,
Zecke

aighes · 2013-10-23 16:25:49

Ich nutze aktuell eine Samsung 840 für die Generierung der RadReiseKarte. Bei den Größen deiner DB freue ich mich richtig, dass ich mit einem komprimierten planet arbeiten kann...

free_as_a_bird · 2013-10-23 16:37:34

wambacher wrote:

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

Auf keinen Fall OCZ. Bevor man sich diesen technischen Sondermüll antut, empfiehlt sich ein Blick ins OCZ-Forum

Nachdem die letzte RMA-Platte 10 Tage ausgehalten hat, bevor sie den Dienst quittiert hat, freue ich mich schon auf neue Abenteuer..

wambacher · 2013-10-23 17:54:00

Nop wrote:

wenn Du flatfile benutzt könnte es auch mehr sein, das gabs bei meiner Vergleichsmessung damals noch nicht.

Muß ich mir mal ansehen. Dachte, flatfile wäre irgend so ein altes Zeug. Ich importiere im Slim-Modus; damit und nur damit kann man Diffs einspielen. Und das ist wohl sowas ähnliches? Mal sehen.

Wichtig ist daß Dein Kernel eine saubere TRIM-Unterstützung hat, muß evtl. dafür neu gebaut werden.

TRIM im Kernel? Das sagt mir absolut nichts. Ansonsten fahr ich das allerneueste 13.10 Ubuntu mit 3.11.0-Kernel. Da sollte doch wohl alles sauber sein.

Evtl. fährst Du günstiger wenn Du 2 kleinere SSDs nimmst und zu einem virtuellen Laufwerk zusammenlegst, so ist mein Server konfiguriert.

Wenn - und das ist schon fast sicher - fange ich mit einer SSD an und schau mal was das bringt. Striping kommt, wenn ich noch eine 2. SSD von euch geschenkt bekomme kaufe

Gruss
walter

wambacher · 2013-10-23 18:16:35

Zecke wrote:

Ich würde bei einer DB (zumindest Oracle) erwarten, daß es performancemäßig am meisten bringt, die Redo-Logs auf SSD zu verlagern, erst nachrangig die Daten oder die Indizes. Keine Ahnung wie das bei pgsql heißt.

Danke für den Tip.
Die Redo-Logs nennen sich bei Postgresql WAL (Write Ahead Logging), liegen in der Directory pg_xlog und das man man natürlich überall hinlegen. (*)
Kommt auf jeden Fall ganz oben auf meine Liste.

Gruss
walter

*) Am besten in eine RAM-Disk, schneller geht es nimmer

Augustus Kling · 2013-10-23 18:16:36

wambacher wrote:

[…]
Ich werde mir wohl nach und nach 1-3 SSD zulegen und die wichtigsten Indices (*) drauflegen aber ich hab immer noch ein ungutes Gefühl bezüglich der Robustheit.
[…]
*) wie krieg ich die raus? Muß mich wohl mal mit Postgresql-Monitoring beschäftigen.
[…]

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.

Nop · 2013-10-23 19:03:53

wambacher wrote:

Nop wrote:
wenn Du flatfile benutzt könnte es auch mehr sein, das gabs bei meiner Vergleichsmessung damals noch nicht.
Muß ich mir mal ansehen. Dachte, flatfile wäre irgend so ein altes Zeug. Ich importiere im Slim-Modus; damit und nur damit kann man Diffs einspielen. Und das ist wohl sowas ähnliches? Mal sehen.
Wichtig ist daß Dein Kernel eine saubere TRIM-Unterstützung hat, muß evtl. dafür neu gebaut werden.
TRIM im Kernel? Das sagt mir absolut nichts. Ansonsten fahr ich das allerneueste 13.10 Ubuntu mit 3.11.0-Kernel. Da sollte doch wohl alles sauber sein.

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

Zu Ubuntu kann ich nix sagen, aber ich habe hier ein frisch installiertes aktuelles Debian Wheezy und da mußte man den Kernel für besseres TRIM nochmal bauen.

bye, Nop

wambacher · 2013-10-23 19:41:36

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

Interessant. wie ich sehe, hat kai krueger die finger drin. werd ich mal checken.

Zu Ubuntu kann ich nix sagen, aber ich habe hier ein frisch installiertes aktuelles Debian Wheezy und da mußte man den Kernel für besseres TRIM nochmal bauen.

So, bin endlich von einer Baustelle zurück, auf der ich mich verlaufen hatte: Trim ist für mich Zeichenkettenverarbeitung gewesen und das passte irgendwie nicht in den Kernel
TRIM für SSD sollte zumindest in meinem Ubuntu (13.10) drin sein. Zumindest weiss ich jetzt, dass ich darauf achten muß.

Gruss
walter

ps: wenn jetzt die letzte Tabelle (planet_osm_nodes mit 370 GB!) in einen anderen Tablespace verschoben wurde, schau ich mal ob es etwas schneller wird. Ab jetzt sind zumindest Indices und Daten physikalisch getrennt. Danach lege ich pg_xlog (Wal) mal auf ein eigenes Laufwerk, das hier ungenutzt in der Ecke liegt.

Nadjita · 2013-10-23 19:43:48

wambacher wrote:

Die Redo-Logs nennen sich bei Postgresql WAL (Write Ahead Logging), liegen in der Directory pg_xlog und das man man natürlich überall hinlegen. (*)
Kommt auf jeden Fall ganz oben auf meine Liste.
*) Am besten in eine RAM-Disk, schneller geht es nimmer ;) ;) ;)

Neee, RAM-Disk ist nicht die beste Lösung. Datenbanken sind Weltmeister darin, Speicher sinnvoll zu nutzen, alles was Du als RAM-Disk abzweigst fehlt zum Cachen. Abgesehn davon, dass bei vielen Updates und Inserts die WAL-Logs extrem groß werden. Diese auf eine SSD zu packen ist aber durchaus sinnvoll, da dort die meiste Aktivität ist. Wenn nicht auf eine SSD, dann zumindest auf ein separates Laufwerk. Wenn ich allerdings sehe, dass planet_osm_nodes_pkey 43GB groß ist (und planet_osm_ways_nodes noch größer), dann ist das durchaus ein Problem bei "nur" 32GB Arbeitsspeicher. Wenn der Index nicht in den Speicher passt, wird es einfach langsam, da die Datenbank dann swappen muss. Wenn es meine Datenbank wäre, würde ich den Index in Teile zerlegen die in den Speicher passen (z.B. in einen Index mit nodes id < 5000000000, einenen >= 5000000000 und < 10000000000, usw.). Wenn Du Dich allerdings mit Datenbanken im Allgemeinen und PostgreSQL im Speziellen nicht auskennst, fällt das vermutlich flach. Ich vermute mal, dass Du mit einer einzigen SSD von 128GB und einem Swapfile auf der Platte schon einen deutlichen Geschwindigkeitsgewinn bekommst. Hätte ich die Hardware hier, würde ich entsprechend schauen, ob ich deine Konfiguration nachbauen und optimieren kann, aber momentan fliegt das nicht hier herum ;o)

TRIM ist überhaupt kein Problem in neueren Ubuntu-Kerneln und die Anzahl der Schreiboperationen sollte man auch nicht überschätzen. Faktisch ist eine SSD schneller zu klein für ihren Einsatzzweck als dass sie den Geist aufgibt. Natürlich kann es Dir immer wieder passieren, dass sie sich nach einem Jahr verabschiedet wenn Du keine SSD wie die von mir gepostete nimmst, aber der Preisunterschied rechtfertigt es im privaten Umfeld einfach nicht. So lange keine sensiblen Daten darauf liegen, ist doppelt kaufen billiger als extrem teuer kaufen ;o)

seichter · 2013-10-23 19:51:04

wambacher wrote:

TRIM im Kernel? Das sagt mir absolut nichts. Ansonsten fahr ich das allerneueste 13.10 Ubuntu mit 3.11.0-Kernel. Da sollte doch wohl alles sauber sein.

TRIM (Mitteilung, dass Blöcke nicht mehr gebraucht werden) ist in Linux seit 2010 (2.6.33) dabei, bei MS seit W7. Es kann aber sein, dass es neuere Varianten (-> Nop) gibt.

wambacher · 2013-10-23 20:18:13

Nadjita wrote:

wambacher wrote:
Die Redo-Logs nennen sich bei Postgresql WAL (Write Ahead Logging), liegen in der Directory pg_xlog und das man man natürlich überall hinlegen. (*)
Kommt auf jeden Fall ganz oben auf meine Liste.
*) Am besten in eine RAM-Disk, schneller geht es nimmer
Neee, RAM-Disk ist nicht die beste Lösung. Datenbanken sind Weltmeister darin, Speicher sinnvoll zu nutzen, alles was Du als RAM-Disk abzweigst fehlt zum Cachen.

Voll drauf reingefallen - und dabei hab ich extra drei Smilies drangehängt. Wer die WAL-Files (bei mir übrigens 1.1 GB) in den Speicher legt, der gehört erschossen. Die werden doch genau dann gebraucht, wenn der Rechner abgestürzt ist - und dann ist der Memory natürlich auch weg. War wirklich nur ein Scherz.

Wenn der Index nicht in den Speicher passt, wird es einfach langsam, da die Datenbank dann swappen muss. Wenn es meine Datenbank wäre, würde ich den Index in Teile zerlegen die in den Speicher passen (z.B. in einen Index mit nodes id < 5000000000, einenen >= 5000000000 und < 10000000000, usw.). Wenn Du Dich allerdings mit Datenbanken im Allgemeinen und PostgreSQL im Speziellen nicht auskennst, fällt das vermutlich flach.

Nönö, das trau ich mir durchaus zu. Aber mit dem Aspekt hab ich mich noch nicht beschäftigt.

Ich vermute mal, dass Du mit einer einzigen SSD von 128GB und einem Swapfile auf der Platte schon einen deutlichen Geschwindigkeitsgewinn bekommst.

Meinst du wirklich, den Memory per Swap aufzubohren und den Postgresql zum Fressen geben? Also postgresql.conf noch mehr aufzubohren als es der reale Memory erlaubt? Fragt sich dann, was schneller ist: Daten von der Platte lesen oder Index swappen? Mal sehen, Swapfiles sind ja schnell erstellt und Plattenplatzt hab ich eh genug.

Hätte ich die Hardware hier, würde ich entsprechend schauen, ob ich deine Konfiguration nachbauen und optimieren kann, aber momentan fliegt das nicht hier herum ;o)

Ich schau mal im Keller nach, ob ich noch so eine Kiste zusammenbauen kann Nee, Danke für dein "Angebot" aber soooo kritisch ist die Sache ja auch nicht.

Natürlich kann es Dir immer wieder passieren, dass sie sich nach einem Jahr verabschiedet wenn Du keine SSD wie die von mir gepostete nimmst, aber der Preisunterschied rechtfertigt es im privaten Umfeld einfach nicht. So lange keine sensiblen Daten darauf liegen, ist doppelt kaufen billiger als extrem teuer kaufen ;o)

"Deine" Samsung 830 mit 128 GB gibt es für ca 125€, das sollte im November wohl drin sein. Aber ich mach mich gerade erst so richtig schlau über das Thema. Will halt keinen Schrott vom Discounter-Krabbeltisch kaufen.

Gruss
walter

Nadjita · 2013-10-23 21:14:34

wambacher wrote:

Voll drauf reingefallen - und dabei hab ich extra drei Smilies drangehängt.

Mift Aber wenn Du wüsstest, was ich schon alles gesehen habe... da sind WAL-Files in RAM-Disk noch harmlos...

seichter · 2013-10-23 21:31:01

wambacher wrote:

Die Planet-DB ist "etwas" größer:
planet2# \d+
List of relations
Schema | Name | Type | Owner | Size | Description
--------+--------------------+-------+----------+---------+-------------
...
public | planet_osm_line | table | postgres | 45 GB |
public | planet_osm_nodes | table | postgres | 374 GB |
public | planet_osm_point | table | postgres | 13 GB |
public | planet_osm_polygon | table | postgres | 57 GB |
public | planet_osm_rels | table | postgres | 1369 MB |
public | planet_osm_roads | table | postgres | 7188 MB |
public | planet_osm_ways | table | postgres | 111 GB |
...

Kleine Kollateral-Erkenntnis: Man muss im Moment noch kein schlechtes Gewissen haben, wenn man eine neue Relation erstellt.

amm · 2013-10-24 04:52:49

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!

amm · 2013-10-24 05:14:42

wambacher wrote:

Frage: Hat jemand praktische Erfahrungen mit SSD im Datenbankbereich?

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.

efred · 2013-10-24 06:11:03

free_as_a_bird wrote:

Auf keinen Fall OCZ. Bevor man sich diesen technischen Sondermüll antut, empfiehlt sich ein Blick ins OCZ-Forum

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.

toc-rox · 2013-10-24 06:48:55

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

Announcement

#1 2013-10-23 12:50:07

Einsatz von SSD für die Datenbank

#2 2013-10-23 13:12:13

Re: Einsatz von SSD für die Datenbank

#3 2013-10-23 13:34:26

Re: Einsatz von SSD für die Datenbank

#4 2013-10-23 13:34:51

Re: Einsatz von SSD für die Datenbank

#5 2013-10-23 13:39:46

Re: Einsatz von SSD für die Datenbank

#6 2013-10-23 13:45:48

Re: Einsatz von SSD für die Datenbank

#7 2013-10-23 13:57:20

Re: Einsatz von SSD für die Datenbank

#8 2013-10-23 14:53:37

Re: Einsatz von SSD für die Datenbank

#9 2013-10-23 15:11:28

Re: Einsatz von SSD für die Datenbank

#10 2013-10-23 16:25:49

Re: Einsatz von SSD für die Datenbank

#11 2013-10-23 16:37:34

Re: Einsatz von SSD für die Datenbank

#12 2013-10-23 17:54:00

Re: Einsatz von SSD für die Datenbank

#13 2013-10-23 18:16:35

Re: Einsatz von SSD für die Datenbank

#14 2013-10-23 18:16:36

Re: Einsatz von SSD für die Datenbank

#15 2013-10-23 19:03:53

Re: Einsatz von SSD für die Datenbank

#16 2013-10-23 19:41:36

Re: Einsatz von SSD für die Datenbank

#17 2013-10-23 19:43:48

Re: Einsatz von SSD für die Datenbank

#18 2013-10-23 19:51:04

Re: Einsatz von SSD für die Datenbank

#19 2013-10-23 20:18:13

Re: Einsatz von SSD für die Datenbank

#20 2013-10-23 21:14:34

Re: Einsatz von SSD für die Datenbank

#21 2013-10-23 21:31:01

Re: Einsatz von SSD für die Datenbank

#22 2013-10-24 04:52:49

Re: Einsatz von SSD für die Datenbank

#23 2013-10-24 05:14:42

Re: Einsatz von SSD für die Datenbank

#24 2013-10-24 06:11:03

Re: Einsatz von SSD für die Datenbank

#25 2013-10-24 06:48:55

Re: Einsatz von SSD für die Datenbank

Board footer