Schrift
[thread]3485[/thread]

Bilder in der DB ablegen sinnvoll oder nicht?: eigenes CMS (Seite 2)

Leser: 1


<< |< 1 2 3 >| >> 21 Einträge, 3 Seiten
Gast Gast
 2004-07-21 21:08
#32434 #32434
[quote=ptk,21.07.2004, 18:04]Insbesondere kann ein Webserver die Kernel-Funktion sendfile(2) verwenden, um eine Datei an ein Socket zu schicken. Das ist wesentlich performanter, als es mit einer Datenbank je gehen koennte.[/quote]
und wie sieht sowas unter win2k aus?
ptk
 2004-07-21 21:36
#32435 #32435
User since
2003-11-28
3645 Artikel
ModeratorIn
[default_avatar]
Die Win32-API kenne ich nicht.
kabel
 2004-07-21 22:18
#32436 #32436
User since
2003-08-04
704 Artikel
BenutzerIn
[default_avatar]
[quote=murphy,21.07.2004, 14:51]Aber ich glaube, ich komme etwas vom Thema ab.[/quote]
ueberhaupt nicht. (gegen rant kann man einfach nix machen, andererseits sind gerade die seicht OT beitraege interessant zu lesen)

AFAIR wird das winfs unter anderem sowas koennen, d.h. auf NTFS kommt ne db-schicht, die sich per xml anpassen laesst (so oder so aehnlich, lang ists her, seit ich was drueber gelesen hab ...). das ist genau der punkt, den ich angesprochen habe. dann werden dateioperationen auf dboperationen abgebildet, die dann vom NTFS dateisystem beackert werden ... oder mei_ist_des_schrott faehrt zunaechst zweigleisig (native db+datei ops), dann irgendwann nur noch db ops. da die ein monopol haben, ist die strategie kein problem. support einstellen, und gut ist :kopfschuettel:
-- stefan
jan10001
 2004-07-22 00:29
#32437 #32437
User since
2003-08-14
962 Artikel
BenutzerIn
[default_avatar]
@Crain
Quote
Ich glaube ich würde auch nur die Pfade abspeichern. Aber es hängt davon ab, wie Deine Rahmenbedingungen so sind. Wenn alles in der DB ist hat man natürlich den Vorteil, dass ein Dump davon alles beinhaltet, aber den Nachteil, dass die DB eventuell sehr groß wird.

Hm, die Rahmenbedingungen:
Mein CMS basiert auf Perl 5.8, HTML:Template, MySQL und mod_rerwrite. Ziel ist es ein kleines leicht zu installierendes CMS zu generieren das äusserst flexibel, leicht verständlich ist und es zudem unmöglich macht eine komplette dynamische Webseite von einer Statischen zu unterscheiden.

Ich denke für erste werde ich bei den Pfaden bleiben und eventuell später falls die CPU Belastung nicht sehr hoch ist die Bilder in die DB ablegen.
kabel
 2004-07-22 01:11
#32438 #32438
User since
2003-08-04
704 Artikel
BenutzerIn
[default_avatar]
[quote=D,21.07.2004, 22:27]Kannst Du Deinen Text bitte einmal übersetzten?[/quote]
in welche sprache?\n\n

<!--EDIT|renee|1090558247-->
-- stefan
sri
 2004-07-22 19:12
#32439 #32439
User since
2004-01-29
828 Artikel
BenutzerIn
[Homepage] [default_avatar]
Auf die Frage ob Datenbank oder Dateisystem gibt es keine Patentlösung.

Speichern im Dateisystem ist immer schneller als in einer Datenbank, lässt sich aber z.B. durch vorangestellte mod_proxy Apache/Squids recht gut ausgleichen.

Es ist eine Frage der skalierbarkeit, denn bedenke, nicht alle Dateisysteme verhalten sich gleich, Ext2/3 z.B. bekommen bei mehreren Tausend Dateien in einem Verzeichnis ernste Probleme, so das eine generierte Verzeichnisstruktur ala "/f1/12/e3/23/12.jpg" nötig wird. (Recht einfach mit MD5 zu generieren, aber wenig skalierbar, Speicherfressend und schlecht für Backups).

Das einzige mir bekannte Dateisystem das hundert tausende Dateien in einem Verzeichnis ohne performance einbussen verträgt ist ReiserFS.

Das speichern in einer Datenbank dagegen ist sehr einfach und skalierbar. Backups sind ein Kinderspiel.

Postgresql kann grosse binär objekte sogar on-the-fly komprimieren! (Stichwort TOAST) :)

Bei einem grossen Projekt an dem ich gerade arbeite habe ich mich für eine hybridlösung entschieden.
Hierbei werden statische Dateien (ein paar hundert bilder/css/templates) im Dateisystem (auf einem geteilten NFS server), und durch den Benutzer hochladbare Dateien (viele tausend css/bilder) in einer Postgresql gespeichert.

Ergo: Wenn du mehr als Tausend Bilder hast greiffe zur Datenbank (benutze aber mod_proxy/squid), ansonsten nutze einfach das Dateisystem.
jan10001
 2004-07-22 22:03
#32440 #32440
User since
2003-08-14
962 Artikel
BenutzerIn
[default_avatar]
@sri
Quote
Speichern im Dateisystem ist immer schneller als in einer Datenbank, lässt sich aber z.B. durch vorangestellte mod_proxy Apache/Squids recht gut ausgleichen.

Es ist eine Frage der skalierbarkeit, denn bedenke, nicht alle Dateisysteme verhalten sich gleich, Ext2/3 z.B. bekommen bei mehreren Tausend Dateien in einem Verzeichnis ernste Probleme, so das eine generierte Verzeichnisstruktur ala "/f1/12/e3/23/12.jpg" nötig wird. (Recht einfach mit MD5 zu generieren, aber wenig skalierbar, Speicherfressend und schlecht für Backups).
Mit mod_proxy Apache/Squids habe ich keine Erfahrung, da müsste ich mich erst einlesen. Aber bei den Bildern wäre die Verzeichnisstruktur sowie so kein Problem, da sowohl die virtuellen und rellen Verzeichnisse in der DB gespeichert sind, sowie die Dateinamen aller vorhanden und virtuellen Dateien.

Quote
Speichern im Dateisystem ist immer schneller als in einer Datenbank, lässt sich aber z.B. durch vorangestellte mod_proxy Apache/Squids recht gut ausgleichen.
Das wäre nicht das Problem, da nur der Webmaster die Bilder oder sonstige Seiten erstellt.

Quote
Das speichern in einer Datenbank dagegen ist sehr einfach und skalierbar. Backups sind ein Kinderspiel.
Nach einer schlaflosen Nacht habe ich beschlossen gerade wegen des einfachen Backups bei einer DB doch die Bilder in der DB abzulegen. Nun stelle ich mir zwei Fragen.

1: Wie sieht eigentlich der Quellcode zur Ausgabe des Bildes aus?
2. Kann ich mit HTML::Template ein Bild überhaupt ausgeben?

Quote
Bei einem grossen Projekt an dem ich gerade arbeite habe ich mich für eine hybridlösung entschieden.
Hierbei werden statische Dateien (ein paar hundert bilder/css/templates) im Dateisystem (auf einem geteilten NFS server), und durch den Benutzer hochladbare Dateien (viele tausend css/bilder) in einer Postgresql gespeichert.

Ergo: Wenn du mehr als Tausend Bilder hast greiffe zur Datenbank (benutze aber mod_proxy/squid), ansonsten nutze einfach das Dateisystem.

Ein Hybridlösung wäre bei mir sicherlich leicht machbar (lediglich zwei Sub's im Eingabe und Ausgabe Script müssen geändert werden), aber dann würden die Grundvoraussetzungen nicht mehr stimmen. Mein Bruder möchte auch gern mein CMS nutzen da er aber keinen vollwertigen Rootserver hat würde es schwierig werden.

In meinem Anwendungsfall muß das CMS ca. 500 bis 1000 Bilder speichern und die Inhalte von mehreren hundert Webseiten.
renee
 2004-07-23 01:47
#32441 #32441
User since
2003-08-04
14371 Artikel
ModeratorIn
[Homepage] [default_avatar]
[quote=jan10001,22.07.2004, 20:03]1: Wie sieht eigentlich der Quellcode zur Ausgabe des Bildes aus?
2. Kann ich mit HTML::Template ein Bild überhaupt ausgeben?[/quote]
zu 1.) Wenn ich mich nicht irre:
Du öffnest das Bild open()
binmode FILEHANDLE
binmode STDOUT
print Bild
close...

2.) werde ich morgen mal testen...
wenn's nicht geht, weiß ich schon, worüber ich mir mal Gedanken machen kann ;)
OTRS-Erweiterungen (http://feature-addons.de/)
Frankfurt Perlmongers (http://frankfurt.pm/)
--

Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
Perl-Entwicklung: http://perl-services.de/
[E|B]
 2004-07-23 11:15
#32442 #32442
User since
2003-08-08
2561 Artikel
HausmeisterIn
[Homepage] [default_avatar]
Code: (dl )
1
2
3
4
5
6
7
8
9
open(F, "pic.gif") or die $!;
binmode(F);
local $/;
my $pic = <F>;
close(F);

binmode(STDOUT);
print "Content-type: image/gif\n\n";
print $pic;


Sollte funzen...
Gruß, Erik!

s))91\&\/\^z->sub{}\(\@new\)=>69\&\/\^z->sub{}\(\@new\)=>124\&\/\^z->sub{}\(\@new\)=>);
$_.=qq~66\&\/\^z->sub{}\(\@new\)=>93~;for(@_=split(/\&\/\^z->sub{}\(\@new\)=>/)){print chr;}

It's not a bug, it's a feature! - [CGI-World.de]
renee
 2004-07-23 11:43
#32443 #32443
User since
2003-08-04
14371 Artikel
ModeratorIn
[Homepage] [default_avatar]
Bei HTML::Template dürfte es nicht funktionieren, weil der Content-type ja text/html ist... Also einfach die Bilddaten printen dürfte nicht klappen...

...äähh.. das ist keine Reaktion auf eb's antwort, sondern eine Ergänzung zu meinem Beitrag vorher...\n\n

<!--EDIT|renee|1090568670-->
OTRS-Erweiterungen (http://feature-addons.de/)
Frankfurt Perlmongers (http://frankfurt.pm/)
--

Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
Perl-Entwicklung: http://perl-services.de/
<< |< 1 2 3 >| >> 21 Einträge, 3 Seiten



View all threads created 2004-07-21 10:40.