Re: [pgsql-de-allgemein] Die Optimale Tabellenstruktur für Postgres 8.1-8.3 ?

[Michael Renner <renner(at)inqnet(dot)at>]

rudi(at)je-more(dot)de wrote:

> > Stimmt. Ich meine mich erinnern zu können, wie Tom Lane auf der
> > general-Liste zu dem Thema mal sagte, dass Oracle zu einem Zeitpunkt
> > entstand, als die filesysteme noch nicht so ausgereift waren wie heute 
> > und
> > die Entwickler deswegen viel von dem, was ein modernes filesystem leisten
> > kann, in die db eingebaut haben. Postgres ist jünger, und bedient sich
> > unbefangen aus den (mittlerweile luxuriösen) filesystem-APIs, sozusagen.
> Tja, wenn das stimmt, dann sollten solche Test nicht solche Ergebnisse 
> erzielen, denn hier sind es
> gerade die neuen Filesysteme mit Journaling (in diesem Fall EXT3) die 
> Postgres ganz gewaltig ausbremsen
> können, wie diese Messung zeigt:

Besser als Hauptabendprogramm hier...

Ja, wenn die Datenbank direkt auf ein Blockdevice schreibt (und dafür 
optimiert ist!) wird man in nahezu allen Fällen flotter sein als wenn 
man über eine FS-Abstraktionsebene geht (ich glaub das kann man sogar 
mathematisch/logisch Beweisen wenn man möchte).

Ja, wenn die Datenbank direkt auf ein Blockdevice schreibt verliert man 
viel an Flexibilität die man mit einem Filesystem drüber hätte.

Ja, wenn die Datenbank direkt auf ein Blockdevice schreiben soll, muss 
man verdammt viel mehr Code pflegen als wenn man sich für viele 
Teilbereiche auf den Kernel, der POSIX-genügende Funktionen zur 
Dateimanipulation bereitstellt, verlässt.

Ja, wenn die Datenbank direkt auf ein Blockdevice schreiben soll, muss 
man deutlich mehr Logik einbauen (und erst mal testen!), damit die Daten 
auf dem Blockdevice konsistent sind.


Oracle hat die Arbeit investiert direkten Blockdevice-Support 
einzubauen. Damals hat das wahrscheinlich auch Sinn gemacht, weil Oracle 
"schon ein Zeiterl" Datenbanken macht, und bei vielen Betriebssystemen 
bei unterschiedlichen Lastmustern die Performance unter aller Sau war 
oder man im Produktiv-Betrieb unter Last fröhlich auf (V)FS-Bug-Jagd 
gegangen ist. (Dieser Absatz beruht lediglich auf Mutmaßungen).

Oracle kann sichs auch leisten, weil die einen nicht zu verachtenden 
Entwicklerstab haben.

Wenn du bei einem Opensourceprojekte fragst "Wollt ihr die Codebasis im 
Persistence-Bereich verdoppeln um unter gewissen Umständen $n% 
Mehrleistung rauszuholen als mit einem sinnvollen Filesystem- und 
Blockdevice-Setup" wird die Antwort wohl relativ eindeutig ausfallen.



Und wenn ich dir noch länger die Welt erklären soll, muss ich wohl 
langsam Anfangen Rechnungen auszustellen ;).


lg,
michael