PostgreSQL maximiert die Leistung der SSD

Ich werde eine riesige PostgreSQL 9.3-Datenbank mit vielen Tabellen mit mehr als 100 Millionen Einträgen pro Tabelle haben. Diese Datenbank wird grundsätzlich schreibgeschützt sein (sobald ich alle erforderlichen Tabellen gefüllt und die Indizes erstellt habe, werden keine Schreibvorgänge mehr für die Datenbank ausgeführt) und Einzelbenutzerzugriff (Ausführen und Benchmarking mehrerer Abfragen von localhost), da die Datenbank verwendet wird nur zu Forschungszwecken. Abfragen verwenden immer JOIN für Ganzzahl-DB-Felder.

Ich werde wahrscheinlich eine SSD (256-512GB) für diesen Zweck kaufen. Ich habe noch nie eine SSD für eine DB verwendet. Gibt es also etwas, vor dem ich Angst haben sollte? Kann ich die gesamte Datenbank oder nur die Indizes auf der SSD ablegen? Gibt es spezielle Ratschläge / Anleitungen zum Optimieren von PostgreSQL für SSDs? Beachten Sie, dass ich eine gute Workstation mit einem i7 und 32 GB RAM besitze. Vielleicht können Sie dort auch Ratschläge geben.

Gibt es etwas, vor dem ich Angst haben sollte?

Keine Backups. Wie jedes Speichergerät kann es sterben. Bewahren Sie Backups auf.

Wenn das Laden der Daten Ewigkeiten in Anspruch nehmen wird, würde ich die schreibgeschützte Datenbank nach dem Laden der Daten sichern, indem ich sie anhalte und kopiere. Auf diese Weise ist es später einfacher, etwas neu zu erstellen, wenn etwas schief gelaufen ist.

Kann ich die gesamte Datenbank oder nur die Indizes auf der SSD ablegen?

Wenn es passt, speichern Sie die gesamte DB.

Wenn dies nicht der Fall ist, platzieren Sie einen Tablespace auf der SSD und verwenden Sie ihn, um die Indizes und so viele der stark abgefragten Tabellen zu speichern, wie passen.

Gibt es spezielle Ratschläge / Anleitungen zum Optimieren von PostgreSQL für SSDs?

Die meisten Vorteile von SSDs sind für OLTP-Schreiblasten. Der Hauptvorteil für schreibgeschützte Ladevorgänge ist das schnelle Suchen, und slardiere hat dies abgedeckt.

Möglicherweise möchten Sie festlegen effective_io_concurrency = 5oder etwas, um die Tatsache widerzuspiegeln, dass SSDs schnelle Zufallslesevorgänge mit hoher Pipeline-Auslastung ausführen können. Dies wirkt sich jedoch nur auf Bitmap-Index-Scans aus und berücksichtigt dies in der Praxis random_page_costbereits.

Bei einer schreibgeschützten Last macht dies keinen großen Unterschied.

Informationen zum erstmaligen Laden von Daten finden Sie unter:

• /programming//q/12206600/398670
• /programming//q/758945/398670
• /programming//q/9407442/398670

Beachten Sie, dass ich eine gute Workstation mit i7 und 32 GB RAM besitze. Vielleicht können Sie dort auch Ratschläge geben.

Legen Sie einen großen Wert maintenance_work_memfür das Laden der Daten fest. Ich würde zumindest verwenden 8GB.

Stellen Sie ein großes work_memfür die abfragende Arbeit ein. Die geeignete Größe hängt ein wenig von der Komplexität der Abfrage ab. Beginnen Sie mit 500MBund gehen Sie von dort hoch.

Erhöhen Sie Ihren checkpoint_segments(massiven) Aufwand für das anfängliche Laden von Daten.

Denken Sie daran, das VM-Overcommit zu deaktivieren! (Siehe das PostgreSQL-Handbuch: http://www.postgresql.org/docs/current/static/kernel-resources.html )

In Bezug auf SSDs wird empfohlen, 'random_page_cost' in postgresql.conf zusätzlich zu den üblichen Einstellungen auf 1 zu senken (entspricht 'seq_page_cost').