2016-11-07 3 views
0

Erhöhung ich eine PostgreSQL 9.2 Datenbank mit 3 Tabellen verwendet:Daten zwischen Datenbanken Migration keine Leistungs

A - contains 12 millions records 
B - contains 24 millions records 
C - contains 20 millions records 

Tabellen wie verbunden sind:

A (one to many) B 
B (one to zero/one) C 

I decieded haben/zu archivieren wandern ältere Daten zur 2. Datenbank, um meine Hauptdatenbank zu beschleunigen (weniger Daten = bessere Leistung).

Nachdem ich etwa 20% der Daten aus jeder Tabelle migriert habe, habe ich VACUUM ANALYZE auf meine Hauptdatenbanktabellen getan, um ein wenig aufzuräumen.

Ich dachte, dass die nächsten 20% viel schneller zu migrieren werden .... Ich lag falsch. Jeder nächste Prozent der Daten zu archivieren Prozess langsamer und langsamer ...

Ich dachte, vielleicht VAACUM FULL wird hier benötigt, aber ich habe gelesen, es ist nicht zu empfehlen. Darüber hinaus ist es eine sehr langsame Abfrage und benötigt fast doppelt soviel Speicherplatz (es erstellt eine neue Tabelle und löscht dann die alte).

Was kann ein Grund für eine langsamere Verarbeitung sein, obwohl weniger Daten übrig sind? Fehle ich einen Schritt, der die Datenbankgeschwindigkeit nach der Migration erhöhen kann? Irgendeine Art aufräumen anders als VACUUM ANALYZE

Müssen angeben, dass ich Messzeit der Verarbeitung 3 Schritte habe: Auswahl einer Daten aus der Hauptdatenbank zu kopieren, Einfügen in 2. Datenbank, löschen aus der Hauptdatenbank.

Das Auswählen von Daten ist ein Problem.

Über Archivierungsprozess:

  1. ich wählen A A Tabellenzeilen älter als Tage x. Kopiere es und entferne es dann.
  2. Dann wähle ich eine B-Reihe verbunden mit A-Zeilen zuvor ausgewählt. Kopiere es und entferne es dann.
  3. Zuletzt wähle ich eine C-Reihe verbunden mit B-Zeilen zuvor ausgewählt. Kopiere es und entferne es dann.

Conf:

8GB RAM.

max_connections = 100 
shared_buffers = 2GB 
effective_cache_size = 6GB 
work_mem = 32MB 
maintenance_work_mem = 512MB 
checkpoint_segments = 32 
checkpoint_completion_target = 0.9 
wal_buffers = 16MB 
default_statistics_target = 100 
random_page_cost = 2.0 
+1

Veröffentlichen Sie den SQL-Migrationscode und diese Tabellendefinitionen. –

+0

Wie ich verstehe, sind diese 3 Schritte unabhängig voneinander. Sind sie? Und dass Sie Schritt Nummer 1 als Schuldigen gefunden haben? –

+0

@ClodoaldoNeto Schritt 1 und 2 sind verbunden - 'in A einfügen aus wählen ....'. Allerdings habe ich versucht, ein 'select' unabhängig auszuführen und herauszufinden, dass es etwa 2 min dauert, wobei' insert' + 'select' 2,5min dauert. – ilovkatie

Antwort

0

Versuchen Sie herauszufinden, wo die Zeit verbracht wird. Ist es die SELECT, um die Reihen in B und C zu finden? Ist es die DELETE?

Sobald Sie die problematische Aussage gefunden haben, schauen Sie sich den EXPLAIN (ANALYZE) Ausgang dafür an; es wird dir sagen, wann die Zeit abgelaufen ist.

Löschen von Zeilen aus einer Tabelle macht es nicht kleiner und beschleunigt nicht unbedingt Abfragen auf der Tabelle. Was kann Hilfe ist VACUUM (FULL), insbesondere wenn es sequenzielle Scans gibt. Sie müssen es nicht auf alle Tabellen in der Datenbank ausführen; Wenn Platz ein Problem ist, können Sie es auf einem Tisch nach dem anderen tun.
Aber zuerst schauen Sie sich die Ausführungspläne an, um zu sehen, ob das überhaupt hilft.

+0

Ich habe einen Abfrageplaner überprüft - er verwendet nur den Index-Scan. Ist es möglich, dass 'REINDEX' in diesem Fall benötigt wird? – ilovkatie

+0

Dies ist insbesondere dann möglich, wenn der Index Scan größere Teile des Index scannt. Schwer zu sagen ohne Ausführungspläne. –

Verwandte Themen