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

Andreas 'ads' Scherbaum schrieb:
> 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?
> 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.
Steht näher hier beschrieben. Dort wird auch der Trick verraten wie man
durch DBCP hindurch auf eine
native Connection casten kann. Damit wird jedoch das ganze
Connectionpooling ausgeknockt,
was sicher nicht das Maß der Dinge ist.
http://www.michael-brockhaus.de/howtos/java/tomcat_dbcp_postgres.html
> 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

<What are CLOBs?>

Basically, LOBs (Large Objects) are designed to support large
unstructured data such as text, graphic images, still video clips, full
motion video, and sound waveforms. A typical employee record may be a
few hundred bytes, but even small amounts of multimedia data can be
thousands of times larger. Oracle supports the following two types of LOBs:

*
Those stored in the database either in-line in the table or in a
separate segment or tablespace, such as BLOB(Binary LOB), CLOB
(Character LOB) and, NCLOB (National Character LOB). As the
name signifies, BLOB holds binary data while the CLOB holds textual data
and the NCLOB holds, character data that corresponds to the national
character set defined for the Oracle database.
*
Those stored as operating system files, such as BFILEs.

</>
Einige Banken nutzen die CLOBS um DB's grösser 32-Terrabyte damit zu
fahren (Eingescannte Belege als hochauflösende Bilder).

Man kann also sagen ORACLE hat mit Binärdaten in der DB selbst keinerlei
Probleme und sagt sogar ausdrücklich das sie
es empfehlen, anstatt die Binärobjekte im Filesystem abzulegen, weil es
aus der DB wesentlich nun mal wesentlich schneller geht.
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.

>> 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.
>
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

> 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 und b) sind
Dateisysteme für ORACLE Tablesaces zumindest eher ein Hinderniss anstatt
ein sinnvolles
Feature. Gerade moderne Filesysteme sind Journalingfilesysteme die im
Datenbankenbereich
unnötigen Overhead verursachen. Die DB findet ihre Daten wesentlich
schneller wenn alles
sie zu 100% mit ihren eigenen Mechanismen innerhalb der ORACLE Word
danach suchen kann.

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