Postgre Query Performance Problem

[Furtbichler]

Die einzig legitime Anwendergruppe.

Wie groß ist die Datenmenge in etwa in kB, die übertragen wird? Angenommen, es sind 200 Bytes pro Datensatz, dann wären das alleine schon 200k x 0,2k = 40 MB+Overhead, die irgendwie vom Server zum Client geschaufelt werden müssen. Das dauert ja auch seine Zeit.

Ändern sich viele oder nur wenige Datensätze pro Query?

Wenn es nur relativ wenige sind, dann könnte ein Cache helfen, der nur die zwischen zwei Abfragen veränderten DS liefert. Ich hatte es einmal mit einer Auftragsliste mit ca. 40k Einträgen zu tun (ca. 5k pro Eintrag). Jeder Datensatz (Auftrag) hat einen PK. Meine Query enthielt also pro Datensatz den PK und die Nutzdaten. Diese Query hat den Aufbau

Code:

SELECT * FROM View_Auftrag WHERE <Bedingung>

Es dauerte ziemlich lange, bis die Query komplett abgearbeitet wurde.

Eine ähnliche Query, die jedoch nur die PK der Aufträge lieferte, also

Code:

SELECT * FROM View_Auftrags_ID WHERE <Bedingung>

war jedoch wesentlich schneller.

Mein Cache führte also nur die 2 Abfrage durch und erstellte eine Liste der PK, die geändert oder neu hinzugekommen war. Anschließend wurde die 'View_Auftrag' nur für diese PK aufgerufen, was auch widerum wesentlich schneller war, als ständig die 200k Datensätze abzufragen.

Na ja, und das Cachemodul hat dann also die bereits bekannten mit den neuen Datensätzen vermischt, die nicht mehr vorhandenen entfernt und dann dieses Paket geliefert.

Alternativ kannst Du im Server auch beim Ändern eines Auftrags dessen PK in einer Liste ablegen und der Cache zieht sich also diese Liste, löscht sie und lädt dann nur die PK dieser Liste (sie enthält ja nur die PK der Datensätze, die verändert wurden).

Vorher: 20s.
Nachher: 0,5s.

Wenn Du allerdings nur am Server rumschrauben kannst, bringen o.g. Ideen natürlich nichts.

[361]

Hallo Furtbichler,

und vielen Dank für Deine Antwort.

Also zwecks Datenmenge: Die ID-Spalten sind character(26) und die Quantity ist ein Integer.

Ansonsten ändern sich öfter mal Datensätze und mal nicht, das ist schwer zu sagen und je Anwenderkreis unterschiedlich. Die Datenschicht hat bereits einen Cache, der allerdings immer wieder die gesamten Daten lädt und nicht selektiv die Änderungen (Manko). Dieser Schritt ist geplant, zeitlich allerdings etwas intensiver. Bevor ich mich an diese Umsetzung mache, wollte ich grundsätzlich erst einmal optimieren. Hierbei ist mir Dank Eurer Antworten einerseits der Teil Server-Resourcen/Optimierung aufgefallen und die Art der Datenabfrage (weniger Daten und selektiv den Datencache refreshen) könnte noch verbessert werden.

Eine Frage an die Postgre-Spezialisten. Besteht die Möglichkeit eine solche "View" vom Server aus schon im Speicher vorzuhalten, sprich eine Art MemTable bei der der Server die Daten in dieser "View" immer aktuell hält und die Abfragezeit dadurch minimiert wird. Wenn ja, wie geht das?

[jobo]

Ich bin kein Postgres Spezialist, daher kann ich Dir auch die ältere Frage an mich nicht beantworten- hast Du selbst schon hinbekommen.

Vielleicht hilft das Stichwort Materialized View weiter. Soweit ich das überflogen hab, ist Postgres da etwas zurück, aber es gibt Anleitungen zur Handarbeit. Schau mal, ob es für Dich passen könnte. Vielleicht mit Hilfe einer kleinen Testtabelle.

http://tech.jonathangardner.net/wiki...rialized_Views
http://wiki.postgresql.org/wiki/Materialized_Views

Das sind einfach die ersten 2 google Treffer zu dem Thema, sieht ganz gut aus, aber ohne Gewähr meinerseits.