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