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

Moin,

Das ist bestimmt eine komische Frage, aber wie designe ich eine Tabelle
für PG genauso,
dass der Postmaster sie optimal verarbeiten kann? Ich will einfach eine
Tabellenstruktur
erstellen die Postgres soweit entgegene kommt wie nur möglich.

Gibt es Analysemöglichkeiten für DDL Statemets die einen Verraten ob
die Tabellenstruktur
plausibel ist?

Mein Einsatzzweck:
Maximale SELECT Ausleseperformance für die Darstellung auf dynamisch
generieten Websites
für eine Suchmaske.

G, R

rudi(at)je-more(dot)de <rudi(at)je-more(dot)de> schrieb:

> Moin,
>
> Das ist bestimmt eine komische Frage, aber wie designe ich eine Tabelle
> für PG genauso,
> dass der Postmaster sie optimal verarbeiten kann? Ich will einfach eine
> Tabellenstruktur
> erstellen die Postgres soweit entgegene kommt wie nur möglich.

Mit der Normalform macht man seltenst Fehler.

> Mein Einsatzzweck:
> Maximale SELECT Ausleseperformance für die Darstellung auf dynamisch
> generieten Websites
> für eine Suchmaske.

Das Tool der Wahl ist EXPLAIN ANALYSE, dazu das Loggen aller Statements,
die lnger als X ms Ausfhrungszeit haben.

Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknow)
Kaufbach, Saxony, Germany, Europe. N 51.05082, E 13.56889

Danke für die schnelle Antwort!

>> Mit der Normalform macht man seltenst Fehler.
>>
hmm, naja gibt andere DB's die nehmen einen die Normalform schon eher krum,
da muss man dann spezielle Optimierungen vornehmen, die nicht ganz
Standardkonform
sind. Aber aus deiner Antwort schließe ich das PG die erfreuliche
Ausnahme ist ;D

>> Das Tool der Wahl ist EXPLAIN ANALYSE, dazu das Loggen aller Statements,
>> die l�nger als X ms Ausf�hrungszeit haben.
>> Andreas
>>
Hmm, weiß nicht ob mein Problem zu Abstrakt für EXPLAIN ANALYSE gestrikt
ist.

Ich habe eine Tabelle Messages, die aus den Feldern

ID int, SENDER int , SUBJECT, varchar 240, MESSAGEBODY text, DATE datetime
besteht.

Das Problemfeld sind hier die SELECTS und INSERTS die Konkurierend von
verschiedenen
Usern gleichzeitig ausgeführt werden. Aufgrund der Zeichenlänge im Feld
"Messagebody (text)"
dauert ein Insert/Select ewig lange und führt auf der WebApplikation
Oberfläche zu langen Wartezeiten
für dier User (Warnung: das momentane System läuft auf MySQL5 mit PHP4.x
unter Linux).

Die Messagetable ist jetzt knapp 700 GBytes groß und wächst beständig
weiter an. Wenn 10.000- 14.000
USer täglich eingeloggt sind gibts schon mal 20 bis 30 Sek. für ein
Insert und ca. 5 bis 20 Sek fürs
Selects, je nach kokurierendem Userverhalten (sprich wie hoch die
Hotspots nun mal gerade sind).

Die Tabelle Messages istzwar nicht groß und Komplex aber das Feld
Messageboy ist eine riesige
Datentonne wo ich nicht recht weiß wie ich auf Postgres Seite so
gestalten soll das ich keine Bauchschmerzen
mehr damit habe. In Zukunft soll die gesammt db so mit ca. 1 Terrabyte
bis 1 Exobyte keine Probleme
haben, so dass sich der Wechsel auf Postgres auch wirklich rechnet und
nicht in ein paar Jahren die
nächste DB Migration ins Haus steht.

ps: Nein, hab keine Kohle sondern will einfach nur meinen Job gut machen
und möchte
dafür Postgres verwenden :D

G.R

rudi(at)je-more(dot)de <rudi(at)je-more(dot)de> schrieb:

> Ich habe eine Tabelle Messages, die aus den Feldern
>
> ID int, SENDER int , SUBJECT, varchar 240, MESSAGEBODY text, DATE datetime
> besteht.
>
> Das Problemfeld sind hier die SELECTS und INSERTS die Konkurierend von
> verschiedenen
> Usern gleichzeitig ausgeführt werden. Aufgrund der Zeichenlänge im Feld
> "Messagebody (text)"
> dauert ein Insert/Select ewig lange und führt auf der WebApplikation
> Oberfläche zu langen Wartezeiten
> für dier User (Warnung: das momentane System läuft auf MySQL5 mit PHP4.x
> unter Linux).

IIRC speichert MySQL ja alles in einem File, PG nutzt TOAST. Alleine
schon deswegen vermute ich einfach mal, daß PG hier einen Vorteil hat.

Dann müßte man einfach mal sehen, wie sich so eine Tabelle unter PG
verhält, also INSERT und SELECT mal via EXPLAIN untersuchen.

>
> Die Messagetable ist jetzt knapp 700 GBytes groß und wächst beständig
> weiter an. Wenn 10.000- 14.000
> USer täglich eingeloggt sind gibts schon mal 20 bis 30 Sek. für ein
> Insert und ca. 5 bis 20 Sek fürs
> Selects,

Wie schaut denn so ein Select aus? MySQL kann IIRC nur ein Index pro
Select und Table verwenden, PG hat solch Limitierung nicht.

Ohne handfeste Tatsachen, also ein Explain Analyse, raten wir ja nur
herum.

>
> Die Tabelle Messages istzwar nicht groß und Komplex aber das Feld
> Messageboy ist eine riesige
> Datentonne wo ich nicht recht weiß wie ich auf Postgres Seite so
> gestalten soll das ich keine Bauchschmerzen

Man könnte auch darüber sinnieren, das nur im Filesystem zu speichern.
Aber das ist eine andere Baustelle.

>
> ps: Nein, hab keine Kohle sondern will einfach nur meinen Job gut machen
> und möchte
> dafür Postgres verwenden :D

Löblich.

Andreas
--
Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°

>
> IIRC speichert MySQL ja alles in einem File, PG nutzt TOAST. Alleine
> schon deswegen vermute ich einfach mal, daß PG hier einen Vorteil hat.
>
Hast Du da mal einen qualifizierten Link? Die beiden Begriffe in
Zusammenhang mit SQL DB's
habe ich noch nie gehört ;D
> Dann müßte man einfach mal sehen, wie sich so eine Tabelle unter PG
> verhält, also INSERT und SELECT mal via EXPLAIN untersuchen.
>
Naja, ich habe ein LAMP Operativsystem und das PG basierte ist gerade in
der Entwicklung
und da will ich die alten Probleme halt nicht wieder haben. Richtige
Liveresultate bekomme ich
also erst im Betrieb mit dem neuen System, bis dahin heißt so gut wie
möglich schätzen.
> Man könnte auch darüber sinnieren, das nur im Filesystem zu speichern.
> Aber das ist eine andere Baustelle.
Mit Bildern habe ich das eigentlich auch vor.

rudi(at)je-more(dot)de <rudi(at)je-more(dot)de> schrieb:

>>
>> IIRC speichert MySQL ja alles in einem File, PG nutzt TOAST. Alleine
>> schon deswegen vermute ich einfach mal, daß PG hier einen Vorteil hat.
>>
> Hast Du da mal einen qualifizierten Link? Die beiden Begriffe in
> Zusammenhang mit SQL DB's
> habe ich noch nie gehört ;D

Welche Begriffe? Einer wohl sicher TOAST, oder?
http://www.postgresql.org/docs/current/static/storage-toast.html

Und der andere?

Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°

On Sun, 11 May 2008 13:19:23 +0200 rudi(at)je-more(dot)de wrote:

> >> Mit der Normalform macht man seltenst Fehler.
> >>
> hmm, naja gibt andere DB's die nehmen einen die Normalform schon eher krum,

Das sind dann aber keine relationalen Datenbanken ... oder schimpfen
sich nur so.

> >> Das Tool der Wahl ist EXPLAIN ANALYSE, dazu das Loggen aller Statements,
> >> die l�nger als X ms Ausf�hrungszeit haben.

Dein Encoding hat irgendwo ein Problem ...

> Das Problemfeld sind hier die SELECTS und INSERTS die Konkurierend von
> verschiedenen
> Usern gleichzeitig ausgeführt werden. Aufgrund der Zeichenlänge im Feld
> "Messagebody (text)"
> dauert ein Insert/Select ewig lange und führt auf der WebApplikation
> Oberfläche zu langen Wartezeiten
> für dier User (Warnung: das momentane System läuft auf MySQL5 mit PHP4.x
> unter Linux).

PHP4 ist schon alt und ranzig, das Haltbarkeitsdatum ist abgelaufen.

Nicht alles, was auf MySQL irgendwie läuft, lässt sich 1:1 auf normale
relationale Datenbanken übertragen. Die Erfahrung lehrt jedoch, dass
dann eine (bislang fehlende) Normalisierung der Daten auf einmal Wunder
bewirkt. Gerade den Messagebody könnte man ggf. auslagern oder/und nur
einlesen, wenn er wirklich benötigt wird (beim Darstellen einer
Nachricht, nicht bei der Darstellung der Übersicht). Gleiches gilt
übrigens für die Applikation: ein "SELECT *" überträgt natürlich
Unmengen Daten, wobei man ggf. mit einem "SELECT id, sender, subject,
date" vollkommen ausreichen würde.

Da PostgreSQL durchgehend MVCC fährt, sollten sich schreibende (das
schliesst updatende Operationen aus) und lesende Operationen überhaupt
nicht stören. Das Problem ist also ev. etwas anders gelagert.

> Die Messagetable ist jetzt knapp 700 GBytes groß und wächst beständig
> weiter an. Wenn 10.000- 14.000
> USer täglich eingeloggt sind gibts schon mal 20 bis 30 Sek. für ein
> Insert und ca. 5 bis 20 Sek fürs
> Selects, je nach kokurierendem Userverhalten (sprich wie hoch die
> Hotspots nun mal gerade sind).

Ein INSERT sollte überhaupt keine Zeit kosten, weil die Datenbank -
zumindest PostgreSQL - dafür auf keine anderen Verbindungen warten muss.

> Die Tabelle Messages istzwar nicht groß und Komplex aber das Feld
> Messageboy ist eine riesige
> Datentonne wo ich nicht recht weiß wie ich auf Postgres Seite so
> gestalten soll das ich keine Bauchschmerzen
> mehr damit habe.

An sich sollte das kein Problem sein - bei Problemen kann man das
jedoch auslagern und bei Bedarf vernünftig joinen.

> In Zukunft soll die gesammt db so mit ca. 1 Terrabyte
> bis 1 Exobyte keine Probleme
> haben, so dass sich der Wechsel auf Postgres auch wirklich rechnet und
> nicht in ein paar Jahren die
> nächste DB Migration ins Haus steht.

Nun, die einzig sinnvolle Antwort an dieser Stelle: Testen.
Dann einen Datenbestand von 1 TB aufbauen und noch mal testen.
Danach den Datenbestand vergrößern und noch mal testen. Dabei tauchen
dann die Schwachstellen sowohl der gewählten Datenbank wie der
gewählten bzw. geschriebenen Applikation an allen Ecken und Enden auf
und man kann korrigierend eingreifen.

Es ist aber schon klar, dass zwischen 1 Terabyte und einem Exabyte 6
Zehnerpotenzen liegen?

Wenn man sich in Bereiche mit solchen Datenmengen begibt, fangen aber
ganz andere Probleme erst an. Wie z.B. stellt man ein Backup der
Datenbank her? Für all solche Fragen sollte man nicht als Neuling
anfangen sondern entweder selbst Wissen aufbauen (Schulungen
existieren, ich weiss da was) oder Wissen einkaufen. Alles andere führt
irgendwann zu Problemen, weil man Details übersieht, die sich hinterher
böse rächen.

Bis dann

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group

Ich glaube Postgres ist für meine Anforderungen doch nicht so das rechte.

Gerade hinsichtlich des Online Backups, des Skalierbarkeitspfads und der
Uptimemöglichkeiten die
mir ORACLE einfach out of the Box bietet und eben das ich es kenne wird
wohl dazu führen das ich
eher Oracle Express oder die Standardedition nehmen werde.

Auch Bilder innerhalb von Blobs sowie unfangreiche Textdokumente
scheinen mir bei Postgres
nicht ideal aufgehoben. Zwar habe ich mit Interesse verfolgt das in
Version 8.3 jetzt eine
Möglichkeit für Volltextindizierbare Dokumente möglich ist, aber auf ein
Erstrelease will ich
mich da einfach nicht verlassen ;d Der Lese und Darstellungsspeed bei
Blobinhalten sowie
das gesammte drumherrum ist etwas das ORACLE schon lange kennt und relativ
sicher abwickelt (ohne Krücken übers Filesystem mit Tempdateien u.s.w).

rudi(at)je-more(dot)de <rudi(at)je-more(dot)de> schrieb:
> Auch Bilder innerhalb von Blobs sowie unfangreiche Textdokumente
> scheinen mir bei Postgres
> nicht ideal aufgehoben. Zwar habe ich mit Interesse verfolgt das in
> Version 8.3 jetzt eine
> Möglichkeit für Volltextindizierbare Dokumente möglich ist, aber auf ein
> Erstrelease will ich
> mich da einfach nicht verlassen ;d Der Lese und Darstellungsspeed bei

Das ist, sorry, Bullshit. Die Volltextsuche ist seit 8.3 im Core-System
mit drin, früher war es als Modul verfügbar. Ein Erstrelease ist das
somit definitiv nicht.

> Blobinhalten sowie
> das gesammte drumherrum ist etwas das ORACLE schon lange kennt und relativ
> sicher abwickelt (ohne Krücken übers Filesystem mit Tempdateien u.s.w).

Auch das ist ist nicht korrekt, denn auch Oracle speichert seine Daten
im Dateisystem.

Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°

Andreas Kretschmer schrieb:
> rudi(at)je-more(dot)de <rudi(at)je-more(dot)de> schrieb:
>
>> Auch Bilder innerhalb von Blobs sowie unfangreiche Textdokumente
>> scheinen mir bei Postgres
>> nicht ideal aufgehoben. Zwar habe ich mit Interesse verfolgt das in
>> Version 8.3 jetzt eine
>> Möglichkeit für Volltextindizierbare Dokumente möglich ist, aber auf ein
>> Erstrelease will ich
>> mich da einfach nicht verlassen ;d Der Lese und Darstellungsspeed bei
>>
>
> Das ist, sorry, Bullshit. Die Volltextsuche ist seit 8.3 im Core-System
> mit drin, früher war es als Modul verfügbar. Ein Erstrelease ist das
> somit definitiv nicht.
>
Obs nun nen Release vorher schon als Einzelkomponente da war oder nicht
ist zweitrangig für mich.

>> Blobinhalten sowie
>> das gesammte drumherrum ist etwas das ORACLE schon lange kennt und relativ
>> sicher abwickelt (ohne Krücken übers Filesystem mit Tempdateien u.s.w).
>>
>
> Auch das ist ist nicht korrekt, denn auch Oracle speichert seine Daten
> im Dateisystem.
>
ORACLE speichert aber keine teporären Objekte im Dateisystem um
Blobinhalte in die Tablespaces
schreiben zu können. Das geht schon deswegen nicht weil ORACLE sich auch
komplett ohne ein
Filesystem RAW auf einer unformatierten Festplatte installieren lässt.

Von Postgres magst Du ja etwas verstehen aber bei ORACLE sollte ein
Anfänger wie Du nicht
das Wort ergreifen. Adäquate Hilfe oder KnowHow lässt sich recht leicht
besorgen oder
nicht vorhandenes Wissen einkaufen!

Guten Tag

rudi(at)je-more(dot)de <rudi(at)je-more(dot)de> schrieb:
>>> Möglichkeit für Volltextindizierbare Dokumente möglich ist, aber auf
>>> ein Erstrelease will ich
>>> mich da einfach nicht verlassen ;d Der Lese und Darstellungsspeed bei
>>>
>>
>> Das ist, sorry, Bullshit. Die Volltextsuche ist seit 8.3 im Core-System
>> mit drin, früher war es als Modul verfügbar. Ein Erstrelease ist das
>> somit definitiv nicht.
>>
> Obs nun nen Release vorher schon als Einzelkomponente da war oder nicht
> ist zweitrangig für mich.

Dann wird Dir auch egal sein, daß es das schon länger als ein Release
gibt. Egal.

>
>>> Blobinhalten sowie
>>> das gesammte drumherrum ist etwas das ORACLE schon lange kennt und relativ
>>> sicher abwickelt (ohne Krücken übers Filesystem mit Tempdateien
>>> u.s.w).
>>
>> Auch das ist ist nicht korrekt, denn auch Oracle speichert seine Daten
>> im Dateisystem.
>>
> ORACLE speichert aber keine teporären Objekte im Dateisystem um
> Blobinhalte in die Tablespaces
> schreiben zu können. Das geht schon deswegen nicht weil ORACLE sich auch
> komplett ohne ein
> Filesystem RAW auf einer unformatierten Festplatte installieren lässt.

Die Zeiten, wo RAW-Disk-Zugriff deutlich schneller als Filesystemzugriff
ist, liegt ebenfalls deutlich länger als ein Release zurück. Von daher
ist diese Diskussion, also bzgl. RAW-Disk-Zugriff, obsolet und im
übrigen schon mehr als einmal diskutiert worden.

> das Wort ergreifen. Adäquate Hilfe oder KnowHow lässt sich recht leicht
> besorgen oder
> nicht vorhandenes Wissen einkaufen!

Dann solltest Du aber noch etwas üben, das passende Medium für
kommerziellen ORA-Support zu finden. Hint: hier wohl nicht.

Wenn Du mit ORA so vertraut bist und es bevorzugst, was exakt willst Du
dann hier? Trollen?

Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°

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?

> Gerade hinsichtlich des Online Backups, des Skalierbarkeitspfads und der
> Uptimemöglichkeiten die
> mir ORACLE einfach out of the Box bietet und eben das ich es kenne wird
> wohl dazu führen das ich
> eher Oracle Express oder die Standardedition nehmen werde.

Es ist schön, wenn du Oracle von Haus aus gut kennst. Wenn ich mich
richtig erinnere, waren es gerade die Kosten, die dich dazu bewegt
haben, einmal einen Blick auf PostgreSQL zu werfen.

Das Thema Backup habe ich aufgeworfen, nicht du. Auf einmal ist es
interessant für dich, schau an - aber was genau hast du davon bei
PostgreSQL gesehen? Online Backup ist ohne weiteres möglich, nicht nur
seit gestern oder der aktuellsten PG-Version.

Uptime realisiert man nicht, indem man viel Geld dem
Datenbankhersteller hinterherwirft und hofft, dass die Patchdays nur
alle 3 Monate sind ... muss man halt die DB nur vier mal im Jahr
herunterfahren: Ziel erreicht. Nebenwirkungen egal.

Wenn ich zur Skalierbarkeit folgende Aussage von dir lese:

"Richtige Liveresultate bekomme ich also erst im Betrieb mit dem neuen
System, bis dahin heißt so gut wie möglich schätzen."

Und:

"In Zukunft soll die gesammt db so mit ca. 1 Terrabyte bis 1 Exobyte
keine Probleme haben"

Dann weiss ich jetzt schon, das du ca. bei 5-10 GB die nächsten
kleineren und vielleicht bei 100 GB die nächsten größeren Probleme
hast. Auch hier zählt, dass es nicht ausreicht, den DB-Hersteller das
Geld nachzuwerfen. Dafür muss man sich in seiner Anwendung und seiner
Datenbankstruktur auch schon mal Gedanken machen.

> Auch Bilder innerhalb von Blobs sowie unfangreiche Textdokumente
> scheinen mir bei Postgres
> nicht ideal aufgehoben.

Ich lese dauernd "scheinen mir".
Du hast deine Entscheidung zwar schon getroffen, aber kein einziges
stichhaltiges Argument dargelegt. Wie bist du zu der Aussage gekommen,
dass die Bilder nicht "ideal aufgehoben" sind, wie sah dein Testcase
dafür aus und welche Ergebnisse hat er geliefert?

> aber auf ein Erstrelease will ich mich da einfach nicht verlassen

Zum Thema "Erstrelease" hat Andreas Kretschmer schon ausführlich
Stellung bezogen.

> Der Lese und Darstellungsspeed bei Blobinhalten sowie
> das gesammte drumherrum ist etwas das ORACLE schon lange kennt und relativ
> sicher abwickelt (ohne Krücken übers Filesystem mit Tempdateien u.s.w).

Redest du von "large objects" oder redest du schlicht von "bytea"?
Wenn du nur von "Blobinhalten" sprichst, dürftest du "bytea" meinen ...
zeig mir doch mal, wo du dabei "Krücken übers Filesystem mit
Tempdateien" benötigst?

Auch hier: wie sah dein Testcase aus, wie das Ergebnis?

Oder war deine gesamte Betrachtung nur eine Luftnummer ohne dass du
irgendeinen realen Test gefahren hast?

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

Andreas Kretschmer schrieb:
> Die Zeiten, wo RAW-Disk-Zugriff deutlich schneller als Filesystemzugriff
> ist, liegt ebenfalls deutlich länger als ein Release zurück. Von daher
> ist diese Diskussion, also bzgl. RAW-Disk-Zugriff, obsolet und im
> übrigen schon mehr als einmal diskutiert worden.
>

Ja, ganz sicher. Mir scheint Du kennst die eigenen Performance Tips von
Postgres nicht einma
ansonsten würdest Du icht deartige Aussagen trffen. egal.
> Wenn Du mit ORA so vertraut bist und es bevorzugst, was exakt willst Du
> dann hier? Trollen?
>
>
> Andreas
Ich glaube es macht keinen Sinn mit jemanden zu diskutieren der
agressiv, unreflektiert und besserwisserisch
wie Du auftritt. Jeder andere hat hier offensichtlich mehr Ahnung von
der Thematik als Du und muss
sich deshalb nicht in Paranoider Hybris suhlen wie Du.

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

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

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.

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.

>> Gerade hinsichtlich des Online Backups, des Skalierbarkeitspfads und der
>> Uptimemöglichkeiten die
>> mir ORACLE einfach out of the Box bietet und eben das ich es kenne wird
>> wohl dazu führen das ich
>> eher Oracle Express oder die Standardedition nehmen werde.
>>
>
> Es ist schön, wenn du Oracle von Haus aus gut kennst. Wenn ich mich
> richtig erinnere, waren es gerade die Kosten, die dich dazu bewegt
> haben, einmal einen Blick auf PostgreSQL zu werfen.
>
Die Kosten sind hier erstmal gar kein Problem, da man mit der Express
Edition anfangen kann
um das System zu entwickeln. Aber auch die Standardedtion ist nicht
unbezahlbar.

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

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

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

> Ich glaube es macht keinen Sinn mit jemanden zu diskutieren der
> agressiv, unreflektiert und besserwisserisch
> wie Du auftritt. Jeder andere hat hier offensichtlich mehr Ahnung von
> der Thematik als Du und muss
> sich deshalb nicht in Paranoider Hybris suhlen wie Du.
du vergreifst dich arg im Ton. So disqualifizierst du dich selbst. Erst
denken dann schreiben.

/tm

Hallo,

Danke fuer deine kompetenten Antworten, was man leider hier nicht von jedem
behaupten kann. Ich wollte auch keinesfalls einen Flamewar anzetteln sondern
lediglich das fuer und wieder abwegen und auch ganz sicher keiner ORACLE Werbung
machen, nur weil ich einige Produktedetails in die aktuelle Debatte einbringe
die möglicherweise relevant sind.

Letztes Stichwort DB Filesystem;

Oracle hat ein gut funktionierendes DB-Filesystem, so
dass mann eine Oracle 8i9i10g11g DB ohne weiteres z.B
als Fileserver laufen lassen kann (um z.B Windows oder
Samba Server zu ersetzen). Das ganze ist auch recht performant
(zumindest wenn man dem Herrstelelr glauben darf). Wie auch immer,
SIEMENS in Führt haben eine oracle 8i DB +DB-Filesystems eingeführt
und konnten danach 70 WinNT Server abschaffen, weil der DB FS-Server
das jetzt auf einer SUN EK10 mit ordentlich Reservepuffer abwickelt.

Ich kenne auch keine einzige Firma oder Projekt die ein DB-FS
wie es Oracle nun mal besitzt auf die Beine gestellt hätte. Viele
haben es versucht, aber keiner hat es gemacht und auch bis zum Ende
durchgezogen (und das schon vor fast 10 Jahren!).

Fazit:
Bei einem DB basierten FS spielen sicherlich einige Dinge mehr als
BLOBS eine Rolle und der einzige der es je geschafft hat sowas zu bauen
schafft das ganze auch noch mit einer akzeptablen Performance (zumindest
ist das mein Eindruck nach einem Projekt damit).

Ich bezweifle auch mal ganz stark, dass die die Daten so bereitstellen wie
Du es aus deinerPostgres Sichtweise beschrieben hast, denn dann müssten
riesige Files wie Videos undendliche Ladezeiten haben, haben sie bei
Oracle aber nun mal nicht.

So und wenn Du oder jemand anderes mich jetzt anzicken und beleidigen
will, dann seis drum, ich habe nicht versucht zu flamen und wenn es
Spass bringt meinen Beitrag zu zerpflücken anstatt konstruktiv zu diskutieren
da
Peng

rudi(at)je-more(dot)de schrieb:
> Hallo,
>
> Danke fuer deine kompetenten Antworten, was man leider hier nicht von jedem
> behaupten kann. Ich wollte auch keinesfalls einen Flamewar anzetteln sondern
> lediglich das fuer und wieder abwegen und auch ganz sicher keiner ORACLE Werbung
> machen, nur weil ich einige Produktedetails in die aktuelle Debatte einbringe
> die möglicherweise relevant sind.

Kindchen, werd erwachsen. "Der Onkel war doof zu mir" zieht hier kaum.

> Letztes Stichwort DB Filesystem;

[..]

Die ganze Diskussion ist schon vor einigen Mails vom konstruktiven "Ich
möchte $x umsetzen, geht das mit pg?" in ein "Meine Datenbank ist größer
als deine" abgeglitten, und da kommt dann schlussendlich nichts
sinnvolles raus.

Die Quintessenz ist, dass Postgres primär ein RDBMS ist, und man beim
speichern von "Dateien" mit allen Vor- und Nachteilen eines RDBMS
gesegnet wird.

Wenn Oracle mehr in die Richtung Fileserver gegangen ist, ist das eine
Entwicklung die man sehr begrüßen kann und bei dem Hintergrund von
Oracle auch nachvollziehbar ist. Bei Postgres gibts sowas in der Form
und Verwendbarkeit nicht, und es ist auch fraglich ob solche Features
jemals in den main tree kommen.

Die Frage ist jetzt - wen interessiert das hier? Und wieso? :)

lg,
m.

--

Michael Renner
InQnet GmbH
Praterstraße 31
A-1020 Wien

Tel.: +43 1 212 7650 521
Fax.: +43 1 212 7650 610

Michael Renner schrieb:
> Wenn Oracle mehr in die Richtung Fileserver gegangen ist, ist das eine
> Entwicklung die man sehr begrüßen kann und bei dem Hintergrund von
> Oracle auch nachvollziehbar ist. Bei Postgres gibts sowas in der Form
> und Verwendbarkeit nicht, und es ist auch fraglich ob solche Features
> jemals in den main tree kommen.
>
> Die Frage ist jetzt - wen interessiert das hier? Und wieso? :)

Tach.

Nun ja, ein anderer hier hat ja schon gemeint dass das Thema DB-FS in
regelmässigen Abständen,
immer mal wieder aufkeimt und da auch Oracle von der reinen RDBMS Basis
gestartet ist, ist
das sicher auch für PG eine oder zwei Überlegungen wert.

rudi(at)je-more(dot)de <rudi(at)je-more(dot)de> schrieb:

> Michael Renner schrieb:
>> Wenn Oracle mehr in die Richtung Fileserver gegangen ist, ist das eine
>> Entwicklung die man sehr begrüßen kann und bei dem Hintergrund von
>> Oracle auch nachvollziehbar ist. Bei Postgres gibts sowas in der Form
>> und Verwendbarkeit nicht, und es ist auch fraglich ob solche Features
>> jemals in den main tree kommen.
>>
>> Die Frage ist jetzt - wen interessiert das hier? Und wieso? :)
>
> Tach.
>
> Nun ja, ein anderer hier hat ja schon gemeint dass das Thema DB-FS in
> regelmässigen Abständen,

Ja. Und?

> immer mal wieder aufkeimt und da auch Oracle von der reinen RDBMS Basis
> gestartet ist, ist
> das sicher auch für PG eine oder zwei Überlegungen wert.

Nicht wirklich. ORA hat da andere komplett andere Philosophie. PG erhebt
nicht den Anspruch, eine eierlegende Wollmilchsau zu sein, sondern ein
Ding, was eine bestimmte Aufgabe gut erledigt. Für das Drumherum benutzt
man halt die (guten) Dinge, die andere schon erfunden haben.

Wenn Du Dich bei ORA besser aufgehoben fühlst: nur zu, niemand hält
Dich. Und ich werd Dich auch nicht weiter füttern, versprochen.

Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°

Andreas Kretschmer schrieb:
> halt die (guten) Dinge, die andere schon erfunden haben.
>
> Wenn Du Dich bei ORA besser aufgehoben fühlst: nur zu, niemand hält
> Dich. Und ich werd Dich auch nicht weiter füttern, versprochen.
>
>
> Andreas
>

Ich weiß zwar nicht unter welchen Stein Du hervorgekrochen bist, aber
der einzige der hier
die ganze Zeit von Anfang bis Ende provoziert hast bist DU!

Es stimmt allerdings, ich hätte Dir schon bei deinen ersten Frechheiten
nicht mehr antworten
und Dir somit ein Forum bieten sollen. Seltsam dass Dich noch niemand
anderes auf
deine agressive, prenetrante, unangenehme Art angesprochen hat.

Du hast ein viel grösseres Problem als Dich zwischen DBx und DB y zu
entscheiden.

Mehr dag ich zu Dir ganz sicher auch nicht mehr.

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

>> Die Frage ist jetzt - wen interessiert das hier? Und wieso? :)
>
> Nun ja, ein anderer hier hat ja schon gemeint dass das Thema DB-FS in
> regelmässigen Abständen,
> immer mal wieder aufkeimt und da auch Oracle von der reinen RDBMS Basis
> gestartet ist, ist
> das sicher auch für PG eine oder zwei Überlegungen wert.

Naja, das mit dem "irgendwo mal angefangen haben" und sich "irgendwohin
weiterentwickeln" ist nicht immer gut und sinnvoll. MySQL war irgendwann
mal ein relationales Textfile und glaubt eine Datenbank werden zu
können. Wirklich schlimm wirds wenn andere Leute das auch anfangen zu
glauben ;).

Um ein Full-Featured "Fileserver" (think Samba) werden zu können ist
einiges an Arbeit notwendig um das ganze sinnvoll, performant und sicher
zu implementieren (seek, mmap, fcntl, non-triviale Permission-Systeme,
etc. pp.) und würde den bestehenden Code deutlich aufblasen, noch dazu
weil ein "normaler" Fileserver kaum die Requirements einer
"Enterprise-Applikation" abdecken könnte und da einiges mehr an
Funktionalität (die man eher in Dokumentenmanagementsystemen vermuten
würde) hineinfliessen müsste.

Allein eine Implementation von "BFILEs" wie bei Oracle würde harte
Diskussionswellen aufwerfen, da das die ganzen Persistence-Paradigmen
von PG über Bord werfen würde.

Deswegen schauen die meisten Leute, wenn sie mit der Aufgabe "Ich brauch
eine Storagelösung für Dateien $x mit Menge $y und Features $z (zB
garantierte Integrität, nicht-modifizierbarkeit, Automatische
Archivierung, ...)" konfrontiert werden, mit welchen Werkzeugen sie
diese Anforderungen umsetzen können.

Auf ein "Ich stell Ding $a hin und das macht das alles" läufts in den
wenigsten Fällen hinaus, ausser das Softwarebudget liegt irgendwo im
7-Stelligen Bereich. Allen anderen bleibt die Architektur des Systems
welches diese Anforderungen erfüllt nicht erspart ;).

lg,
michael

--

Michael Renner
InQnet GmbH
Praterstraße 31
A-1020 Wien

Tel.: +43 1 212 7650 521
Fax.: +43 1 212 7650 610

On Wed, 14 May 2008 20:23:39 +0200 rudi(at)je-more(dot)de wrote:

> Michael Renner schrieb:
> >
> > Die Frage ist jetzt - wen interessiert das hier? Und wieso? :)
>
> Tach.
>
> Nun ja, ein anderer hier hat ja schon gemeint dass das Thema DB-FS in
> regelmässigen Abständen,
> immer mal wieder aufkeimt und da auch Oracle von der reinen RDBMS Basis
> gestartet ist, ist
> das sicher auch für PG eine oder zwei Überlegungen wert.

Nein, du verwechselst da etwas. Hier kommen regelmäßig Fragen nach
einem eigenen Dateisystem für PostgreSQL, so dass die DB in Raw-Devices
schreibt und sich selbst um die Verwaltung kümmert.

Ein Datenbank-basiertes Dateisystem ist noch einmal eine ganz andere
Baustelle und beides hat nichts miteinander zu tun.

Bis dann

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

Andreas 'ads' Scherbaum schrieb:
> Ein Datenbank-basiertes Dateisystem ist noch einmal eine ganz andere
> Baustelle und beides hat nichts miteinander zu tun.
>
> Bis dann

Genau, das ist eins:
http://www.heise.de/newsticker/suche/ergebnis/?rm=result;q=ifs;url=/newsticker/meldung/9459/;words=IFS

am Thu, dem 15.05.2008, um 18:26:56 +0200 mailte rudi(at)je-more(dot)de folgendes:
> Andreas 'ads' Scherbaum schrieb:
> >Ein Datenbank-basiertes Dateisystem ist noch einmal eine ganz andere
> >Baustelle und beides hat nichts miteinander zu tun.
> >
> >Bis dann
>
>
> Genau, das ist eins:
> http://www.heise.de/newsticker/suche/ergebnis/?rm=result;q=ifs;url=/newsticker/meldung/9459/;words=IFS

Bekannt. Ich schrieb ja auch, daß ORA da eine andere Philosophie hat.
Aber was exakt hat das, was der Link da beschreibt, mit einer
relationalen DB zu tun?

Ein ähnliches Projekt gab es übrigens auch im PG-Umfeld:
http://www.edlsystems.com/psqlfs/

Es ist tot, warum wohl? Die Antwort darauf nannte ich schon. Geh zurück
und lese nach. Und warum diskutieren wir hier nach wie vor über
komplett OffTopic-Themen? Und warum füttere ich Dich schon wieder? ...

Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net

--On Mittwoch, Mai 14, 2008 10:24:15 +0200 rudi(at)je-more(dot)de wrote:

> Ich kenne auch keine einzige Firma oder Projekt die ein DB-FS
> wie es Oracle nun mal besitzt auf die Beine gestellt hätte. Viele
> haben es versucht, aber keiner hat es gemacht und auch bis zum Ende
> durchgezogen (und das schon vor fast 10 Jahren!).

IBM's "Filesystem" in der AS/400 war ein solches. Bereits das System/38 als
Vorläufer der AS/400 hatte das RDBMS fest integriert und bot entsprechende
Funktionalität. Und das (sehr) lange vor Oracle....

--
Thanks

Bernd

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

> 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 Problem beim IFS ist oft das Schreiben, denn alle Objekte werden u.U.
auch gleich indiziert und validiert. Das kostet und schlägt sich
mindestens in höherer Prozessorlast nieder.

"Schneller" ist ein sehr subjektives Wort, das schnell pauschalisiert.

--
Thanks

Bernd