| From: | Michael Renner <renner(at)inqnet(dot)at> |
|---|---|
| To: | pgsql-de-allgemein(at)postgresql(dot)org |
| Subject: | Re: [pgsql-de-allgemein] Die Optimale Tabellenstruktur für Postgres 8.1-8.3 ? |
| Date: | 2008-05-15 17:27:25 |
| Message-ID: | 482C727D.6050902@inqnet.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-de-allgemein |
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