Einzelnen Beitrag anzeigen

Furtbichler
(Gast)

n/a Beiträge
 
#11

AW: Postgre Query Performance Problem

  Alt 28. Aug 2012, 08:15
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.
  Mit Zitat antworten Zitat