Hallo Marcus,
Von: "Marcus Obst" marcus.obst@etit.tu-chemnitz.de
Ach ja: wenn Du kannst, verwende COPY anstelle INSERT, wenn es Bulk-Inserts sind. Ist um Größenordnungen schneller.
Geht leider nicht.
Ich hab jetzt nochmal ein bisschen weiter nachgeforscht. Das Problem scheint der BLOB zu seien. Wir speichern u.a. unkomprimierte Bilder ab, diese haben dann pro Eintrag eine Größe von ca. 300k. Sobald ich diese Einfügen will bricht die import Performance von 40MB/s auf 5MB/s ein.
Lasse ich die Bilder weg, geht alles wunderbar.
Dann lege die TOAST-Tabelle auf eine getrennte Festplatte. Moeglicherweise schluckt auch das Komprimieren der Bilddaten Rechenleistung.
Holger ___________________________________________________________ Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar
On 10.05.2011 13:42, Holger Dietze wrote:
Hallo!
Ich glaube das Problem grenzt sich wirklich auf die Binärdaten ein. Ich verwende im Moment dafür den Datentyp *bytea*. Nach allem was ich gelesen und glaube verstanden zu haben, ist das am Ende nix weiter als ,,escaptes'' ASCII, sprich sowohl Client also auch Server müssen irgendetwas konvertieren.
Dann lege die TOAST-Tabelle auf eine getrennte Festplatte. Moeglicherweise schluckt auch das Komprimieren der Bilddaten Rechenleistung.
Jetzt bin ich an dem Punkte angekommen, dass ich verstehe, warum es extra ,,Datenkbankadminstratoren'' gibt :)
Hatte bisher den Irrglauben, man könne eben mal fix ne DB aufsetzen und die geht dann auch EINFACH.
Auf jeden Fall erstmal danke für eure Hinweise!
P.S.: Das ganze liegt natürlich auch noch auf einem Hardware RAID-5...
Marcus
On 10.05.2011 13:55, Marcus Obst wrote:
Ich glaube das Problem grenzt sich wirklich auf die Binärdaten ein. Ich verwende im Moment dafür den Datentyp *bytea*. Nach allem was ich gelesen und glaube verstanden zu haben, ist das am Ende nix weiter als ,,escaptes'' ASCII, sprich sowohl Client also auch Server müssen irgendetwas konvertieren.
So, ich hab jetzt nochmal eine Postgres-Datenbank unter Linux aufgesetzt.
Hier ändert sich ebenfalls nix, außer dass ich das Tun des Servers etwas besser beobachten kann.
Sobald ich Daten Größer 30kb in die Tabelle mit dem Type bytea schreibe wird alles langsam. Serverseitig belegt der postgres-Daemon dann eine komplette CPU.
Demzufolge scheint also die Behandlung von bytea nur mit der CPU-Leistung zu skalieren.
Schade eigentlich.
apt-get remove postgresql
Marcus
Ich habe nun nicht *diese* Ahnung von PostgreSQL, aber wenn ich mir die Doku ansehe, dann steht da was zu "large objects", "lo_import" usw.
Das scheint die Objects nicht in der Tabelle zu vergraben, sondern "extern" und es ist beim Einfüllen der Daten herausfordernder (die müssten als Stream kommen(?)).
Vielleicht ist ja dieses bytea nicht das, was Du brauchst.
On 10.05.2011 15:04, Heiko Schlittermann wrote:
Ich habe nun nicht *diese* Ahnung von PostgreSQL, aber wenn ich mir die Doku ansehe, dann steht da was zu "large objects", "lo_import" usw.
Ja, hab ich auch gesehen, allerdings ist das dann ein ,,extra'' API. Ich müsste also den Code einigermaßen umschreiben, so stelle ich mir das aber irgendwie nicht vor.
Das scheint die Objects nicht in der Tabelle zu vergraben, sondern "extern" und es ist beim Einfüllen der Daten herausfordernder (die müssten als Stream kommen(?)).
Hab ich auch so verstanden
Vielleicht ist ja dieses bytea nicht das, was Du brauchst.
Vielleicht nicht, aber es ist das was ich wöllte :)
Mysql hätte es bestimmt gekonnt...
Marcus
Marcus Obst marcus.obst@etit.tu-chemnitz.de (Tue May 10 15:26:56 2011):
Mysql hätte es bestimmt gekonnt...
ohoh.
Hallo Marcus,
Marcus Obst marcus.obst@etit.tu-chemnitz.de
Jetzt bin ich an dem Punkte angekommen, dass ich verstehe, warum es extra ,,Datenkbankadminstratoren'' gibt :)
... die sich immer mal wieder mit den Anwendungsentwicklern streiten muessen.
Hatte bisher den Irrglauben, man könne eben mal fix ne DB aufsetzen und die geht dann auch EINFACH.
Fuer "kleine" Datenmengen/Zeit klappt das auch. Du hast diesen Bereich verlassen.
Der Vorteil einer Datenbank ist, dass man bei wachsenden Anforderungen nicht gleich die ganze Anwendung neubauen muss, da die Datenbank manche Dinge abstrahiert und der DBA auch Dinge tun kann, von denen die Anwendungslogik nicht direkt etwas wissen muss.
P.S.: Das ganze liegt natürlich auch noch auf einem Hardware RAID-5...
:-(
Holger
lug-dd@mailman.schlittermann.de
-
hdietze42＠web.de -
Heiko Schlittermann -
Holger Dietze
-
Marcus Obst