"static" content via WSGI anbieten

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Antworten
Benutzeravatar
keppla
User
Beiträge: 483
Registriert: Montag 31. Oktober 2005, 00:12

Hallo!
Bei allen WSGI-Frameworks und Helferlein bin ich bis jetzt über die Warnung gestolpert, man solle "statischen" Inhalt nicht selber serven, da wäre der Webserver besser geeignet.
Jetzt stehe ich vor der Situation dass ich eine Art Bildergalerie habe, bei der die Bilder hochladbar sind. Bequemerweise kann ich die in Blobs in der Datenbank speichern, womit sie strenggenommen ja nicht mehr "static content" sind, aber vermutlich doch in das fallen, was man nicht per wsgi serven sollte.
Als Probleme fallen mir ein

1. dass das Handling des Webservers vmtl etwas intelligenter mit client-caching umgeht (304 als antwort auf "if-modified-since"), was ich als Prinzipiell lösbar betrachte, und,

2. dass der Webserver die statischen bilder selber cached, was im verhältnis zu die bilder aus der db, ins wsgi, zum webserver zu schubsen, besser sein könnte.

Die Frage ist nun: Habe ich weitere Probleme übersehen, und ist Problem 2. wirklich schlimm (die Seite wird nicht gerade slashdot-traffic haben).
Benutzeravatar
tiax
User
Beiträge: 152
Registriert: Samstag 23. Juli 2005, 17:28
Kontaktdaten:

Ne invoces expellere non possis
[url=xmpp://florian@florianheinle.de]xmpp:florian@florianheinle.de[/url]
Benutzeravatar
keppla
User
Beiträge: 483
Registriert: Montag 31. Oktober 2005, 00:12

wäre also "problem 2". Dann werd ich mal Benchmarken, wie groß der Geschwindigkeitsnachteil ist. Bzw gucken, ob ich die "beim Erstaufruf cachen"-Sache aus den Kommentaren irgendwie hinbekomme.
Danke
Zuletzt geändert von keppla am Mittwoch 21. November 2007, 19:31, insgesamt 1-mal geändert.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Ist die Frage: Warum Bilder als BLOBs in die Datenbank schieben? Es gibt spezielle Datenbanken, die extra dafür da sind, solche BLOBs zu speichern. Sie werden Dateisysteme genannt.
Django macht das ja so, dass man zwar scheinbar die Bilder in die DB speichert, aber letztendlich landen sie sowieso im Dateisystem. Weil man sich damit eben eine ganze Menge spart, da der Webserver sich darum kümmert, die richtigen Header zu senden etc.

Zum Cachen würde man aber eher einen Caching Proxy verwenden. Also etwa Squid. Macht Wikipedia auch, da MediaWiki nicht annähernd so skaliert wie es nötig wäre, also haben sie mehrere Dutzend Apache-Server und ähnlich viele Squids davorgeschaltet.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Benutzeravatar
keppla
User
Beiträge: 483
Registriert: Montag 31. Oktober 2005, 00:12

Leonidas hat geschrieben:Ist die Frage: Warum Bilder als BLOBs in die Datenbank schieben? Es gibt spezielle Datenbanken, die extra dafür da sind, solche BLOBs zu speichern. Sie werden Dateisysteme genannt.
Das ist mir klar. Das Dateisystem hat aber einige Nachteile, insbesondere stört mich die zusätzliche Konfigurationsarbeit des nutzers, (z.B. dem Webserver mitzuteilen, dass er nochwas serven darf und schreibrechte setzen), die schwerere Verbindungsmöglichkeit von RDBMS und Dateisystem, und die niedrigere Bequemlichkeit beim programmieren (wir Programmieren auch python, obwohl es in asm sicher schneller wäre).

Mal auf der gleichen schiene geantwortet: Texte sind auch nur spezielle Blobs, und trotzdem speichern CMS diese in RDBMS,
Django macht das ja so, dass man zwar scheinbar die Bilder in die DB speichert, aber letztendlich landen sie sowieso im Dateisystem. Weil man sich damit eben eine ganze Menge spart, da der Webserver sich darum kümmert, die richtigen Header zu senden etc.
sowas werd ich mir wohl abgucken, halte ich für ne recht akzeptable Lösung.
Zum Cachen würde man aber eher einen Caching Proxy verwenden. Also etwa Squid. Macht Wikipedia auch, da MediaWiki nicht annähernd so skaliert wie es nötig wäre, also haben sie mehrere Dutzend Apache-Server und ähnlich viele Squids davorgeschaltet.
Klingt etwas oversized. Wie gesagt, es geht hier nicht um slashdot oder flickr.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

keppla hat geschrieben:Mal auf der gleichen schiene geantwortet: Texte sind auch nur spezielle Blobs, und trotzdem speichern CMS diese in RDBMS,
Richtig, weil sie indiziert werden können. Aber du kannst nicht einfach so `SELECT * FROM my_images WHERE überwiegende_farbe = blau;` machen. Insofern hast du durch das Speichern der Dateien mehr Nachteile als Vorteile. Zum Beispiel fällt die Möglichkeit weg ImageMagick auf einfache Weise über die Bilder laufen zu lassen.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Benutzeravatar
keppla
User
Beiträge: 483
Registriert: Montag 31. Oktober 2005, 00:12

Leonidas hat geschrieben:
keppla hat geschrieben:Mal auf der gleichen schiene geantwortet: Texte sind auch nur spezielle Blobs, und trotzdem speichern CMS diese in RDBMS,
Richtig, weil sie indiziert werden können.
Nicht zwangsläufig deshalb, ich habe schon oft CMSe gesehen, die keine Volltextsuche konnten.
Der interessante Punkt sind imho die Relationen.
Aber du kannst nicht einfach so `SELECT * FROM my_images WHERE überwiegende_farbe = blau;` machen. Insofern hast du durch das Speichern der Dateien mehr Nachteile als Vorteile.
Hab ich bei den Bildern auch:

Code: Alles auswählen

select distinct images.data
from images inner join tags on tags.imageid = images.id
where images.gallery = 23
   and tag.name = "python"
Mein Punkt ist die Einfachheit des Programmierens und des Administrierens, und da gewinnen Blobs in meinen Augen ganz klar.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Also um das Beispiel was du mir da vorführst lauffähig zu bekommen braucht man die Bilder doch gar nicht in BLOBs zu haben. Du fragst eben die Metadaten ab, die Text sind der in der Datenbank gespeichert wird. Das hast du ohne BLOBs genau so. Nur greifst du dann auf die eigentlichen Daten des Bildes dann nicht mehr via SQL zu sondern via Dateipfaden.
Was in meinen Augen noch sinnvoll wäre - eine Erweiterung des DBMS welches die Metadaten des Bildes direkt abfragt. Habe aber bisher von so etwas noch nicht gehört, aber vielleicht weißt du ja was dazu.

Das es einfacher ist zu Programmieren mag sein, aber da kann man auch einen Wrapper nutzen, der die Bilder "transparent" in das Dateisystem speichert. Viele Leute nutzen sowieso ORMs, Django macht so etwas ähnliches (obwohl ich es nicht getestet habe), da ist das ziemlich egal wo es letztendlich abgespeichert wird. Und am Ende ist es möglicherweise sogar mehr zu Programmieren, weil du dich noch darum kümmern musst, die Bilder anständig zu serven (Header setzen, MIME-Type, etc).

Von Administrationsaufwand her.. hmm, zum Einrichten ist es sicherlich einfacher. Aber ich gebe dir mal ein Beispiel aus einem meiner Projekte. Dort werden etwa 400 Produkte verwaltet, jedes hat mehrere Bilder, in verschiedenen Auflösungen. Jetzt kann man diese Bilder ganz einfach mit SFTP hochladen (oder `wget` runterladen, oder wie auch immer ins FS bekommen). Man kann also die Bilder mit Standardsoftware hochladen und gut ist. Oder man lädt nur eine Version der Bilder hoch und lässt von einem Shellskript die anderen Bilder errechnen und richtig einsortieren. Das alles läuft so ziemlich nach dem KISS-Prinzip, denn was könnte einfacher sein, als eine Shell mit ImageMagick zu verkuppeln und ein paar Dateien zu verschieben. Mit BLOBs habe ich an der Stelle zusätzliche Komplexität (und schlechtere Performance, da meine BLOBs erstmal durch Unix-Sockets laufen müssen, statt direkt Fileoperationen zu verwenden). Ich mag das jetzt auch nicht alles mit dem Performance-Argument erschlagen, aber ich sehe in BLOBs zu wenige Vorteile.

Vielleicht denke ich aber auch zu enterprisey und mache mir zu viele Sorgen um Skalierbarkeit ;)
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

keppla hat geschrieben:Mal auf der gleichen schiene geantwortet: Texte sind auch nur spezielle Blobs, und trotzdem speichern CMS diese in RDBMS
Ein wichtiger Unterschied besteht jedoch darin, dass der Webserver Bilder ohne weiteres an den User-Agent senden kann, da sie "self-contained", autark oder wie auch immer man es nennen will, sind.

Texte dagegen müssen in aller Regel erst in die Website dynamisch eingefügt werden, wofür es ohnehin schon des Weges über die Web-Applikation, anders als bei direkt auszuliefernden Bildern, bedarf.


Irgendwo im Rattenschwanz des von tiax genannten Artikels wird auch vorgeschlagen, hochgeladene Bilder zunächst in die Datenbank zu speichern. Bei einem Request eines Bildes wird dieses dann, sofern noch nicht geschehen, aus der Datenbank entfernt und ins Dateisystem geschrieben; alternativ auch irgendwann per Cronjob.
Dabei ging es jedoch um (optimierbare) Performance, die in deinem Fall, wie du sagtest, eher wenig von Belang ist.


Ich persönlich halte wenig von Bildern (und anderen großen, speziell binären, Dokumenten) in Datenbanken, weil ich lieber die Daten in Dateiform sichere als in Form von riesigen Datenbank-Dumps. Letztere komprimieren in Nur-Text-Form besser, lassen sich auch gut in einer Versionskontrolle unterbringen* und man stößt weit später oder gar nicht an Größenbegrenzungen beim Wiedereinspielen von Dumps (z.B. über phpMyAdmin, was wiederum auch nicht zuletzt von den Einstellungen von PHP und dem Webserver abhängt, sofern PMA da selbst nicht schon früher ein Limit setzt/forciert).

*: Bei kleineren Projekten stopfe ich auch gerne neben Datenbank-(SQL-)Dumps hochgeladene Dateien mit in die Versionskontrolle. Werden letztere mal getauscht oder ergänzt, ist es mit einer einfachen Operation getan. Sind diese Daten jedoch alle in Form von BLOBs im Dump enthalten, muss ich jedes Mal den *kompletten* Dump committen, was schon bald ziemlich lange dauern kann.
Antworten