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

On Mon, 12 May 2008 22:06:34 +0200 rudi(at)je-more(dot)de wrote:

> Andreas 'ads' Scherbaum schrieb:
> >
> > Warum?
> > Hier werde ich jetzt stutzig:
> > - entweder du willst direkte Verbindungen
> > oder:
> > - du willst connection-pooling.

Ich sehe immer noch nicht, was genau du willst.
Und wieso willst du auf der einen Seite Pooling und auf der anderen
Seite dieses Pooling auf Teufel komm raus durchbrechen ...

> > Und um meine Frage von vorhin zu wiederholen, sprechen wir von large
> > objects oder von bytea?
> >
> Du ich komme von der ORACLE-Seite und da gibts nur BLOB's und CLOBS

Da würde ich mal sagen, Hausaufgaben nicht gemacht:

http://www.postgresql.org/docs/8.3/interactive/datatype-binary.html

Du versuchst mit Gewalt dein von Oracle bekanntes Konzept auf einer
anderen Plattform durchzusetzen. Ist logisch, dass das schief geht.

> <What are CLOBs?>

Ich weiss, was CLOBs sind. So ein bischen kenne ich mich abseits von
PostgreSQL auch aus ...

> Man kann also sagen ORACLE hat mit Binärdaten in der DB selbst keinerlei
> Probleme

Hat PG auch nicht ... wenn man es richtig angeht.

Lies dir meinen Absatz zu dem Thema noch mal durch, ich habe nirgendwo
geschrieben, dass PG Probleme mit diesem Konzept hat ... ich habe nur
aufgezählt, warum man das eigentlich nicht haben möchte. Wer das
trotzdem braucht ... kein Thema.

> es empfehlen, anstatt die Binärobjekte im Filesystem abzulegen, weil es
> aus der DB wesentlich nun mal wesentlich schneller geht.

Du möchtest mir sagen, dass ein random Zugriff auf die Festplatte plus
Weg durch den Datenbanklayer (wesentlich) schneller als der Zugriff
durch das Betriebssystem ist? Klar, bei RAW-Devices kann man dadurch
noch mal ein Stück Performance gewinnen, aber das hat alles seine Vor-
und Nachteile.

> Das spiegelt sich auch in meinen Erfahrungen wieder. Ich habe mal PDF's
> innerhalb eines Dokumentenmanagement-Projekts
> darin abgelegt und kann nur bestätigen das die Performance
> (Schreib/Lese) sehr gut ist.

Und wie groß waren deine PDFs im Durchschnitt? kB Bereich, MB Bereich?
Das liest die Platte mal eben in einem Schwung, dass hat nichts mit der
Performance der Datenbank zu tun. Ausserdem erhöht das den
Speicherverbrauch nicht messbar.

Wenn du anfängt, größere Objekte durch die DB zu schieben, muss die
Datenbank den Speicher trotzdem reservieren. Wie anders soll sie dir
sonst dein Ergebnis bereitstellen? Nach der Datenbank kommt dann noch
deine Applikation, dazwischen vielleicht noch dein Tomcat, die alle
reichen die Daten Stück für Stück (oder auch als ganzes Stück) durch,
bis ganz am Ende dann die Daten endlich ins Netzwerk geschickt werden.
Du siehst, da sind ein Haufen Zwischenstellen im Weg, die man direkt
umgehen könnte. Wenn du Performance misst, solltest du das alles mit in
Betracht ziehen.

> Wie ORACLE das intern handelt ist leider nicht ohne weiteres einsehbar,
> allerdings funktioniert es
> ohne erhöten Speicherverbrauch und ist auch schneller als wenn man es
> vom FS liest.
>
> http://www.oracle.com/technology/products/intermedia/index.html

Toll, Marketing vom Hersteller als Argumente anführen. Aber wenn du
schon damit anfängst:

http://www.oracle.com/technology/products/intermedia/htdocs/why_images_in_database.html

Da steht nur, dass sie das so schnell wie das FS hinbekommen (Abschnitt
Performance), schneller geht auch fast gar nicht.

> > All diese netten Vorteile, die dir ein Filesystem liefert, verlierst
> > du, wenn du die Daten in der Datenbank ablegst. Dass das bei Oracle
> > anders läuft, wage ich mal zu bezweifeln.
> >
> Es läuft dort definitv anders. Sonst würden sie es a) nicht ausdrücklich
> empfehlen

Können wir aufhören, dem Hersteller zu glauben?
Es gibt Argumente dafür und dagegen, wie immer und überall.
Oracle wird dir keine Argumente dagegen liefern, dann würdest du
im Ergebnis diese Software nicht einsetzen.

So, um das Thema "Filesystem oder Datenbank" hier abzuschliessen:
das geht auch unter PostgreSQL wunderbar, entsprechende Infos habe ich
dir weiter oben gepostet.

> Die DB findet ihre Daten wesentlich schneller wenn alles
> sie zu 100% mit ihren eigenen Mechanismen innerhalb der ORACLE Word
> danach suchen kann.

Das Thema wurde anderweitig (nicht in diesem Thread) schon zur Genüge
diskutiert. Wenn es dich interessiert: für PostgreSQL kommt ca. einmal
im Jahr die Frage, warum wir kein eigenes Filesystem entwickeln. Die
Möglichkeiten wären gegeben, entsprechende Antworten findest du im
Mailinglisten Archiv. Auch hier gilt: es hat seine Vor- und Nachteile.
Nicht alles, was in 30 Jahren Betriebssystemerfahrung steckt, sollte
man einfach so über Bord werfen.

> Wenn Du da mehr Infos brauchst ließ mal das:
> http://www.rz.uni-karlsruhe.de/rd/4631.php#Vorteile

Ich weiss, wie man das installiert. Mehr steht da auch nicht.

So, um diese Diskussion abzuschließen:

wir brauchen hier keine Vor- oder Nachteile von Konzepten zu
diskutieren. Du hast deine Entscheidung offensichtlich schon getroffen.
Die Argumente sind nicht ganz nachvollziehbar bzw. wurden teilweise
schon widerlegt, aber das ist (mir) nun egal.

Einen schönen Abend

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors