Hallo Marcus,
"Marcus Obst" marcus.obst@etit.tu-chemnitz.de
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.
large objects: "partially obsolete" :-) (Doku zu PostgreSQL 9.0)
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 :)
bytea ist schon das, was Du willst. Vermutlich macht das Insert zuviel Bloedsinn.
[Beispiel in etwa fuer Perl DBI) Fuer Bulk-Inserts ist es guenstig, zuerst das Statement mit Platzhaltern zu parsen
$sth = $dbh->prepare (q[INSERT INTO tabelle (id, beschreibung, bild) values (?, ?, ?)]);
und dann fuer jeden Datensatz das vorbereitete Statement mit den speziellen Werten aufzurufen:
foreach (@werte) { $sth->execute ($_->{id}, $_->{beschreibung}, $_->{bilddaten}); }
Das spart a) das staendige Neuparsen der Anweisung und die Erstellung des Ausfuehrungsplans, und b) die Konvertierung der Binaerdaten in "Escaped ASCII" weil das Protokoll fuer diesen Fall eine Rohdatenuebertragung vorsieht.
COPY waere vielleicht schneller (wenn man die Binaerdaten schnell genug eingepackt bekommt).
Mysql hätte es bestimmt gekonnt...
wzbw. (was zu beweisen waere)
PostgreSQL kann es, Du hast eben noch nicht alles rausgekitzelt.
BTW, Raid-5 ist fuer Datenbanken nicht so der Bringer. Besser ist Raid-1 oder davon abgeleitete Varianten.
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 17:52, Holger Dietze wrote:
Hallo Holger!
large objects: "partially obsolete" :-) (Doku zu PostgreSQL 9.0) bytea ist schon das, was Du willst. Vermutlich macht das Insert zuviel Bloedsinn.
Okay, so ähnlich hab ich es auch gelesen und deswegen gar nicht erst mit large object angefangen :)
Fuer Bulk-Inserts ist es guenstig, zuerst das Statement mit Platzhaltern zu parsen
Platzhalter habe ich schon und mache sogar Multi-Insert...
COPY waere vielleicht schneller (wenn man die Binaerdaten schnell genug eingepackt bekommt).
Wahrscheinlich. Allerdings ist mir bei COPY der Anwendungsfall nicht so richtig klar. Ich will die Daten ja nicht vorher aufwendig vorbereiten...
Mysql hätte es bestimmt gekonnt...
wzbw. (was zu beweisen waere)
Naja, ich habe jetzt als Trotzreaktion einfach einen Standard-Mysql5 Server auf meinem schwarbrüstigen Laptop installiert, die Queries etwas angepasst und es ausprobiert. Out-of-the-box schaffe ich mit Mysql 15MB/s...
Sogar das nervige Warten beim DELETE ist weg.
PostgreSQL kann es, Du hast eben noch nicht alles rausgekitzelt.
Was zu beweisen waere :)
BTW, Raid-5 ist fuer Datenbanken nicht so der Bringer. Besser ist Raid-1 oder davon abgeleitete Varianten.
Jupp, das könnte auch ein Problem sein. Erklärt doch aber nicht vollständig, warum er bei 300k bytea in die Knie geht (auf meinem Laptop ohne RAID verhält sich genau so).
Marcus
Hej!
2011-05-10 18:06, Marcus Obst skrev:
Naja, ich habe jetzt als Trotzreaktion einfach einen Standard-Mysql5 Server auf meinem schwarbrüstigen Laptop installiert, die Queries etwas angepasst und es ausprobiert. Out-of-the-box schaffe ich mit Mysql 15MB/s...
MySQL verwendet verschiedene Tabellentypen. Der Standard ist MyISAM. Und MyISAM unterstützt keine Transaktionen*!
Du vergleichst also wahrscheinlich gerade Äpfel mit Birnen.
Sogar das nervige Warten beim DELETE ist weg.
Manche Datenbanken markieren Einträge in solchen Fällen mit "gelöscht", ohne sie wirklich zu löschen. Das geschieht erst, wenn z.B. der Platz alle wird. Dein Delete läuft also schnell, ein Select wird aber durch den rumliegenden Müll immer noch gebremst.
(IBM DB2 z.B. legt gleich beim Anlegen einer Tabelle gleich eine große Datei auf der Platte an, damit es online beim Einfügen wirklich nur noch das Unvermeidliche erledigen muss. CREATE ist dadurch bei der Konkurrenz naturgemäß schneller ...)
PostgreSQL kann es, Du hast eben noch nicht alles rausgekitzelt.
Was zu beweisen waere :)
BTW, Raid-5 ist fuer Datenbanken nicht so der Bringer. Besser ist Raid-1 oder davon abgeleitete Varianten.
Solange ein RAID-5 die volle Plattengeschwindigkeit dauerhaft zu schreiben im Stande ist (das sollte jeder aktuelle RAID-Controller, der nicht gar zu billig ist), bremst es nicht.
Viele Grüße Fabian
* jeder einzelne Befehl wird nur gekapselt transaktional behandelt
On 10.05.2011 18:26, Fabian Hänsel wrote:
MySQL verwendet verschiedene Tabellentypen. Der Standard ist MyISAM. Und MyISAM unterstützt keine Transaktionen*! Du vergleichst also wahrscheinlich gerade Äpfel mit Birnen.
Da gebe ich dir Recht. Da mir allerdings Postgres beim Einfügen der Daten in einem großen Transaktionsblock eine Out-of-Memory Exception wirf, ist das bis jetzt nur ein theoretischer Vorteil.
Sogar das nervige Warten beim DELETE ist weg.
Manche Datenbanken markieren Einträge in solchen Fällen mit "gelöscht", ohne sie wirklich zu löschen. Das geschieht erst, wenn z.B. der Platz alle wird. Dein Delete läuft also schnell, ein Select wird aber durch den rumliegenden Müll immer noch gebremst.
Klar, kann ich mir alles lebehaft vorstellen. Wenn ich aber eine (fast) unendlich große Platte habe wie in meinem Falle, gibt es keine Grund zu warten bis irgendwelche Daten *endlich* weg sind. Das muss eine modernen Datenbank doch einfach können.
Marcus
Marcus Obst marcus.obst@etit.tu-chemnitz.de wrote:
On 10.05.2011 18:26, Fabian Hänsel wrote:
MySQL verwendet verschiedene Tabellentypen. Der Standard ist MyISAM. Und MyISAM unterstützt keine Transaktionen*! Du vergleichst also wahrscheinlich gerade Äpfel mit Birnen.
Da gebe ich dir Recht. Da mir allerdings Postgres beim Einfügen der Daten in einem großen Transaktionsblock eine Out-of-Memory Exception wirf, ist das bis jetzt nur ein theoretischer Vorteil.
Praktischer Vorteil für viele wäre, Du würdest das mal ganz offiziell als Bug melden.
Sogar das nervige Warten beim DELETE ist weg.
Manche Datenbanken markieren Einträge in solchen Fällen mit "gelöscht", ohne sie wirklich zu löschen. Das geschieht erst, wenn z.B. der Platz alle wird. Dein Delete läuft also schnell, ein Select wird aber durch den rumliegenden Müll immer noch gebremst.
Klar, kann ich mir alles lebehaft vorstellen. Wenn ich aber eine (fast) unendlich große Platte habe wie in meinem Falle, gibt es keine Grund zu warten bis irgendwelche Daten *endlich* weg sind. Das muss eine modernen Datenbank doch einfach können.
Ähm. Ja. Du kannst gerne vorschlagen, wie man ACID besser implementiert. Bedenke: es können N Transaktionen laufen, jede davon kann M Zeiteinheiten lange laufen. Jetzt den Spinat, ähm Spagat, zu finden, wie man es sauber hinbekommt, daß jede der N Transaktionen noch nach M Zeiteinheiten exakt das sehen, was sie zu Begin der Transaktion sahen, ist nicht trivial. Der Weg, der PG geht, nämlich die Datensätze erst mal nur mit XMIN und XMAX zu versehen und einen 'Aufräumjob' (VACUUM) zu haben, kann man diskutieren. Man sollte dann aber, wenn man drüber nörgelt, auch Alternativen in der Hand haben.
Und ja: Binärdaten in einer DB speichern: kann man machen, kann man aber auch vermeiden¹. Denn der Aufwand, dies zu tun, ist nun mal enorm, und jede I/O der Binärdaten muß irgendwie durch die DB. Und jedes Schreiben von N MByte Nutzdaten ist unterm Strich mind. 2 * N MByte schreiben, nämlich Nutzdaten + WAL. Wenn Dir die Daten nicht wichtig sind: nehme MySQL & MyISAM. Oder gleich Blackhole, ist noch flotter.
¹ Abwägen, ob der Vorteil (Transaktionssichere Binärdaten) den Nachteil (Performace) überwiegt. Alternative: das gute alte Filesystem für Binärdaten nutzen.
Oder anders:
wenn Du mit PG Speed haben willst, dann:
- Config anpassen! - kein RAID 5! - unterschiedliche Spindeln für Daten, Index, WAL - COPY statt INSERT - TRUNCATE statt DELETE - Optimierung für Masseninserts, z.B. Indexe abschalten, Trigger abschalten - binäre Daten: auf Komprimierung verzichten, wenn schon komprimiert - schauen, ob Checkpoints zum Problem werden (checkpoint_completion_target) - Design der DB prüfen: PG kann z.B. Tabellen partitionieren - und und und ...
Marcus
Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Andreas
Hi!
On 10.05.2011, at 18:26, Fabian Hänsel wrote:
2011-05-10 18:06, Marcus Obst skrev:
Naja, ich habe jetzt als Trotzreaktion einfach einen Standard-Mysql5 Server auf meinem schwarbrüstigen Laptop installiert, die Queries etwas angepasst und es ausprobiert. Out-of-the-box schaffe ich mit Mysql 15MB/s...
MySQL verwendet verschiedene Tabellentypen. Der Standard ist MyISAM. Und MyISAM unterstützt keine Transaktionen*!
bei einem aktuellen Mysql stimmt das so pauschal nicht.
"With MySQL 5.5, InnoDB becomes the default storage engine" http://blogs.innodb.com/wp/2010/09/mysql-5-5-innodb-as-default-storage-engin...
Jens
-- Jens Krämer Finkenlust 14, 06449 Aschersleben, Germany VAT Id DE251962952 http://www.jkraemer.net/
Moin Moin
Zitat von Jens Krämer jk@jkraemer.net:
Hi!
On 10.05.2011, at 18:26, Fabian Hänsel wrote:
2011-05-10 18:06, Marcus Obst skrev:
Naja, ich habe jetzt als Trotzreaktion einfach einen Standard-Mysql5 Server auf meinem schwarbrüstigen Laptop installiert, die Queries etwas angepasst und es ausprobiert. Out-of-the-box schaffe ich mit Mysql 15MB/s...
MySQL verwendet verschiedene Tabellentypen. Der Standard ist MyISAM. Und MyISAM unterstützt keine Transaktionen*!
bei einem aktuellen Mysql stimmt das so pauschal nicht.
"With MySQL 5.5, InnoDB becomes the default storage engine" http://blogs.innodb.com/wp/2010/09/mysql-5-5-innodb-as-default-storage-engin...
Ach Jens du alter Spielverderber. Lass doch die kleinen Jungen über MySQL schimpfen. Du weißt doch, und wehe jemand anderes behauptet das Gegenteil: Nur PostgreSQL ist das einzig Wahre! Das beide Datenbanksysteme ihre Arbeit erfüllen, für eine optimale Performance entsprechend konfiguriert werden müssen und das man sich nun mal bei MySQL die passende Engine raussuchen muss wenn man unbedingt Transaktionen braucht ist doch beim Anti-MySQL-Flame total nebensächlich.
Für MySQL gilt das selbe wie für PostgreSQL: Der Entwickler muss sich mit der Datenbank befassen um optimale Ergebnisse zu bekommen. Für meine Bedürfnisse brauche ich keine Transaktionen und mir ist auch noch kein Datensatz abhanden gekommen. Brauche ich Transaktionen setze ich halt InnoDB ein. Wo ist das Problem? Ach ja, man kann dann nicht über MySQL schimpfen.
Wollen wir nun noch ausdiskutieren ob Debian, Ubuntu oder Suse das bessere Linux sind? Oder doch lieber das PostgreSQL-Problem von Marcus lösen?
(Wer Ironie findet darf sie behalten)
Jens
Falk
lug-dd@mailman.schlittermann.de
-
Andreas Kretschmer -
Fabian Hänsel -
falk.doering＠fadoe.de -
Holger Dietze -
Jens Krämer -
Marcus Obst