Re: Wie Binärdateien verwa lten? Filesystem / bytea / Large-Object?

Hallo,

wollte mich bei allen bedanken, die sich mit meiner Frage beschäftigt 
haben. Ich werde das jetzt voraussichtlich mit einem bytea Feld lösen.

MfG

Thomas


Am 19.02.2014 12:47, schrieb Albe Laurenz:
> Thomas Uzunoff schrieb:
>> ich habe eine Anwendung, in der Dateien verarbeitet werden. Diese
>> werden, wenn man sie im Programm speichert, auf einem FTP Server
>> abgelegt und nur wenige Infos (die kaum Speicherplatz benötigen) in
>> einer Datenbank Tabelle gespeichert. Das Konstrukt sollte ursprünglich
>> verhindern, dass die Datenbank in kurzer Zeit sehr groß wird, was
>> (vermutlich) langfristig zu Perfornmance-Problemen geführt hätte. Jetzt
>> ist es leider so, dass die Anbindung an den FTP-Server andauernd
>> Probleme bereitet, weshalb ich den FTP-Teil gerne austauschen würde.
>>
>> Jetzt meine Frage:
>>
>> Wie sollten diese Binärdaten am besten gespeichert werden?
>>
>> Überlegung 1: Statt FTP zu nutzen, die Dateien direkt in das Dateisystem
>> schreiben.
>> Überlegung 2: In die Tabelle, in der die anderen Infos zur Datei
>> gespeichert werden, noch eine Spalte vom Typ bytea einfügen und die
>> Dateiinhalte dort speichern
>> Überlegung 3: Die Dateien als Large-Objects behandeln (obwohl ich noch
>> nicht ganz verstanden habe, was das bedeutet)
>>
>> Momentane Konfiguration des Servers:
>>
>> - PostgreSQL Version: 9.1
>> - Application Server: Glassfish
>> - Programm ist in Java geschrieben
>> - OS: Debian 6.0.4
>>
>> In vermutlich 90% der Fälle liegt die Dateigröße bei unter 50kb
>> zu 1% vermutlich über 1 MB
>> und der Rest dazwischen.
>> Dateien größer als 15MB sind extrem unwahrscheinlich, aber nicht
>> auszuschließen
>> Im Schnitt sind die Dateien rund 160kb groß
>>
>> Natürlich möchte ich auch zukünftig verhindern, dass es langfristig zu
>> Performance-Problemen beim Arbeiten oder Backup kommen könnte.
> Meine Meinung:
>
> Überlege zuerst, ob Du die Dateien in der Datenbank haben willst oder nicht.
>
> Vorteil: Binärdaten und andere Daten sind automatisch konsistent. Dadurch
> wird auch die Applikation einfacher zu schreiben.
>
> Nachteil: Die Performance ist schlechter, die Backups werden groß.
>
> Überlege Dir, wie groß die Datenbank im Endausbau werden wird und wie
> viele Zugriffe pro Sekunde Du erwartest. Und wie wichtig Konsistenz
> zwischen Binärdaten und dem Rest ist. Das sollte bei der Entscheidung
> helfen.
>
> Bei der erwarteten Größe der Binärdaten würde ich bytea verwenden,
> weil das in der Handhabung einfacher ist als large objects.
>
> Liebe Grüße,
> Laurenz Albe


-- 
GrizzlyCRM
Thomas Uzunoff
Inhaber
Barbarossastr. 15
53721 Siegburg

Telefon: +49 (0)89 21 55 19 39
Mobil:   +49 (0)163 83 46 34 0
E-Mail:  [email protected]
URL:     www.grizzlycrm.de

Diese E-Mail kann rechtlich geschützte und/oder vertrauliche Informationen enthalten. Sollten Sie nicht der richtige Adressat sein oder irrtümlich diese E-Mail erhalten haben, vernichten Sie diese E-Mail und benachrichtigen Sie den Absender. Weitergabe und Kopie an Unbefugte ist untersagt.

AGB: http://www.grizzlycrm.de/agb

This e-mail may contain proprietary and / or confidential information. If you are not the intended recipient or have received this email by mistake, please delete this e-mail and notify the sender. Transfer and copy is prohibited to unauthorized.



-- 
Sent via pgsql-de-allgemein mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein