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

On Mon, 12 May 2008 19:37:54 +0200 rudi(at)je-more(dot)de wrote:

> Andreas 'ads' Scherbaum schrieb:
> > On Mon, 12 May 2008 01:12:37 +0200 rudi(at)je-more(dot)de wrote:
> >
> >
> >> Ich glaube Postgres ist für meine Anforderungen doch nicht so das rechte.
> >>
> > Das möge sein, kannst du diese Aussage aber auch mit einigen Tests
> > deinerseits belegen oder sind dies bloss Vermutungen, teilweise
> > basierend auf Aussagen unsererseits?
> >
> Nun, es gibt da wirklich ein Problem das ich mit Postgres bei meiner
> Tomcat WebApplication hätte
> wenn ich Postgres einsetzen würde wollen. Das Problem ist nicht direkt
> ein Postgres Problem, ist
> aber trotzdem ein KO Kriterium.

Ah so.

> Apache DBCP, das für Tomcat der Standard Connectionpooler ist
> unterstützt keine direkten Verbindungen, was bei
> Blob-Schreib/Lesezugriffen zu einem handfesten
> Problem wird.

Warum?

Und um meine Frage von vorhin zu wiederholen, sprechen wir von large
objects oder von bytea?

> Es gibt zwar den Tweak sich auf die native Connection zu
> verbinden, dann jedoch
> wird das Gesammte Connectionmanagemnet durch DBCP komprommitiert, was
> sehr unschön ist.

Hier werde ich jetzt stutzig:

- entweder du willst direkte Verbindungen

oder:

- du willst connection-pooling.

Was du da schreibst, ergibt so recht keinen Sinn für mich.

> Ein anderes Problem ergibt sich durch die Tatsache dass der Class 4 JDBC
> Treiber für Postgres 8.1.x
> kein direktes Insert in die Blobspalte ohne Zwischenschritt über ein
> temporäres Uploadverzeichnis
> ermöglicht (was ORACLE jedoch wieder beherrscht).

Man möchte PG 8.3 haben, nicht 8.1. Das ist zwei Jahre alt.

> Auch ergibt sich aus meinen Recherchen und der Diskussion hier
> (insbesondere mit BLOB-Feldern
> in Tabellen) langsam der Eindruck, dass Blobs aber auch Textfelder (PG
> Datentyp TEXT) nicht
> wirklich geeignet sind um Gigabyte/Terrabyte Datenbanken damit zu
> betreiben. Praktisch jeder
> Foren und Listen Beitrag in diese Richtung rät davon ab und empfielt
> Auslagerung auf das Filesystem
> und das ist etwas was ich definitiv nicht möchte.

Mooooment mal.
Da steht sicherlich auch, warum das so nicht empfehlenswert ist, oder?
Und ich verrate dir etwas: das ist bei Oracle nicht anders.

Das Problem ist, dass die Daten durch die gesamte SQL-Engine in die
Datenbank wandern müssen ... und beim Auslesen den gleichen Schritt
zurück. Das bedeutet auch, dass beim Ausliefern eines Ergebnisses erst
mal die Daten alle in den Speicher geladen werden, bevor sie zum Client
gehen. Hätte man dort ein simples fopen(), gefolgt von einem fread(),
wird nur soviel Speicher verbraucht wie die Applikation wirklich
benötigt. Wenn man Dateien z.B. 1:1 in das Netz ausliefert, öffnet man
diese erst gar nicht sondern lässt sendfile() diese Aufgabe direkt
erledigen. Speicherverbrauch dabei: nahezu Null. Du kannst dir
sicherlich vorstellen, dass es wesentlich langsamer ist, wenn jede
Stelle erst mal komplett die Daten liest und erst dann an die nächste
Stelle weiterreicht.

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. Und auch dort musst du die
Daten beim Auslesen erst mal komplett durch die Datenbank und den
Hauptspeicher schicken, ehe der Client diese empfangen kann.

Die Thematik "Backup" wird auch um ein vielfaches einfacher, da man nur
ein inkrementelles Backup der großen Datenmenge sichern muss. Bei einem
Online Backup der Datenbank speicherst du manche Daten doppelt und
vergrößerst somit den verbrauchten Plattenplatz.

Wird dir nun verständlich, warum man überall empfiehlt, dass größere
Datenmengen nach Möglichkeit nicht in der DB abgelegt werden?

> Da ich nur schätzen kann was nun die beste DB für meinen Einsatzzweck
> ist, entscheide ich mich lieber
> für eine DB von der ich weiß das sie alle Anforderungen beherrscht.

Verständliche Vorgehensweise. Nur: das hättest du dir auch vorher
denken können.

Deine Intention war hoffentlich: "PostgreSQL kann das alles so einfach,
dass ich mir da keine Gedanken mehr machen muss". Weil jeder andere
Grund läuft letztendlich darauf hinaus, dass du doch bei der Datenbank
bleibst, für die Fachwissen im Haus vorhanden ist - damit hättest du
dir deine Frage(n) schenken können.

Bis dann

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