Ich habe eine ziemlich große Tabelle (20M Datensätze), die einen 3-Spalten-Index und eine Array-Spalte hat. Die Array-Spalte wird täglich (durch Hinzufügen neuer Werte) für alle Zeilen aktualisiert. Es gibt auch Einfügungen, aber nicht so viel wie es Updates gibt.
Die Daten im Array stellen tägliche Messungen dar, die den drei Schlüsseln entsprechen, etwa so: [[date_id_1, my_value_for_date_1], [date_id_2, my_value_for_date_2]] . Es wird verwendet, um ein Diagramm dieser täglichen Werte zu zeichnen. Angenommen, ich möchte den Wert für den Schlüssel (a, b, c) im Laufe der Zeit visualisieren, ich mache SELECT values FROM t WHERE a = my_a AND b = my_b AND c = my_c . Dann verwende ich das Array values , um das Diagramm zu zeichnen.
Die Leistung der Updates (die einmal täglich in einer großen Menge vorkommen) hat sich im Laufe der Zeit erheblich verschlechtert.
Verwenden von PostgreSQL 8.3.8.
Können Sie mir einen Hinweis geben, wo Sie nach einer Lösung suchen? Es könnte alles von der Optimierung einiger Parameter in Postgres bis zum Verschieben in eine andere Datenbank reichen (ich denke, dass eine nicht-relationale Datenbank für diese spezielle Tabelle besser geeignet wäre, aber ich habe nicht viel Erfahrung damit).
Ich würde mir den FILLFACTOR für den Tisch ansehen. Standardmäßig ist es auf 100 gesetzt, Sie können es auf 70 senken (um damit zu beginnen). Danach müssen Sie einen VACUUM FULL durchführen, um die Tabelle neu zu erstellen.
%Vor%Dies gibt UPDATE die Möglichkeit, die aktualisierte Kopie einer Zeile auf derselben Seite wie das Original zu platzieren, was effizienter ist als das Platzieren auf einer anderen Seite. Oder wenn Ihre Datenbank bereits von vielen vorherigen Updates fragmentiert ist, könnte es bereits genug sein. Jetzt hat Ihre Datenbank auch die Möglichkeit, HOT zu machen updates , vorausgesetzt, dass die Spalte, die Sie aktualisieren, nicht an einem Index beteiligt ist.
Nicht sicher, ob Arrays der richtige Weg sind.
Warum speichern Sie diese nicht in einer separaten Tabelle (ein Wert plus Schlüssel pro Zeile) dann wird Bulk-Update reine Einfügeaktivität sein.
Das Problem besteht in Updates. Ändern Sie das Schema von Array-basiert zu mehreren Zeilen pro Tag und das Leistungsproblem wird verschwinden.
Sie können Rollups zu Arrays hinzufügen, später mit einer Art Cronjob, aber vermeiden Sie Updates.
Nun, ein 3-Spalten-Index ist kein Grund zur Sorge. Das macht es nicht unbedingt langsamer. Aber diese Array-Spalte könnte tatsächlich das Problem sein. Sie sagen, dass Sie an diese Array-Spalte täglich Werte anhängen. Mit Anhängen meinen Sie Werte an alle 20 Millionen anzuhängen. Datensätze in der Tabelle? Oder nur ein paar Datensätze?
Die Situation ist mir nicht völlig klar, aber ich würde vorschlagen, Wege zu finden, diese Array-Spalte loszuwerden. Zum Beispiel eine separate Tabelle erstellen. Dies hängt jedoch von Ihrer Situation ab und ist möglicherweise keine Option. Es könnte nur ich sein, aber ich fühle mich immer 'schmutzig', wenn ich eine solche Spalte in einem meiner Tische habe. Und meistens gibt es eine bessere Lösung für das Problem, das Sie mit dieser Array-Spalte lösen wollen. Allerdings gibt es sicherlich Situationen, in denen eine solche Spalte gültig ist, aber im Moment kann ich mir keine vorstellen. Sicherlich nicht in einer Tabelle mit einem 20 mln. Rekordanzahl.
Tags und Links optimization postgresql performance