Website DB-basiert versus Filebasiert

[Delbor]

Hi zusammen

Mich beschäftigt schon länger eine Konzeptfrage zur Umsetzung eines Webauftrittes.
Grundsätzlich sieht mein bisheriges Konzept eine vollkommen DB-basierte Lösung vor. Das heisst, alles, was irgendwie mit der Webseite zu tun hat, stammt aus einer Datenbank: HTML, CSS, Javascript ebenso wie Infos zu registrierten Usern etc.
Das Gegenstück wären dann mehr Filebasierte Websites, wie sie von den IIS unterstütz werden: HTML, CSS, Javascript und mediale Inhalte stammen aus Dateien, die auf dem gemieteten Wbspace abgelegt sind.

So oder so wird die Site auf meinem Rechner entwickelt und anschliessend die werden die benötigten Infos zum Server übertragen.
Die Frage ist: was ist schneller?

Gruss
Delbor

[Delbor]

Hi zusammen

Inzwischen habe ich da was dazu gefunden.
Trotzdem - oder gerade deswegen? - würden mich eure Meinungen weiterhin interessieren!

Gruss
Delbor

[mm1256]

Zitat von Delbor:

Die Frage ist: was ist schneller?

Geht es nur um die Geschwindigkeit (Seitenaufbau) oder auch darum, was ist schneller realisierbar? Einfacher zu pflegen? Ich denke, da wird es jetzt auf die gleichen Antworten wie im og. Forum hinauslaufen. Hinzu kommt: ohne detaillierte Informationen über Seitenanzahl und Seitengröße (Datenumfang) bringt ein Vergleich sowieso nichts.

Ich persönlich habe filebasierte Sites im Einsatz und auch welche mit einer DB (Joomla und MySQL). Es sind relativ einfache Seiten, da merkt man überhaupt keinen Performance-Unterschied.

Wobei das auch wieder auf deinen Provider ankommt und wie viele User gleichzeitig auf den Seiten sind. Du gibst dir Mühe und optimierst alles, holst jede Millisekunde raus, aber nützen wird es dir nichts, wenn dein Provider mit seiner Bandbreite Oberkante Unterlippe fährt.

[himitsu]

Ich benutzte quasi ein halbes DB-basiertes System, da die Seiteninhalte in der DB liegen und der Rest (Bilder usw.) im Dateisystem.

Im Grunde könnte man ein DB-basiertes System mit nur einer einzigen winzigen PHP-Datei erzeugen, welches Alles (HTML, Bilder, CSS, JS usw.) aus der DB zieht.

Der Vorteil bei einem reinen statischen dateibasierten System wäre, daß man eben keine DB brauch und praktisch keine Sicherheitslücke existiert, wenn im Webserver kein Code ausgeführt wird. (solange der FTP- und der HTTP-Server sicher sind)

Was man bei der Webseite erstmal betrachen sollte, ob CMS oder nicht.
Es gibt immernoch genügend Leute, welche auf dem PC die Webseite bearbeiten/generieren und dann via FTP hochladen,
während andere eben ein sich selbt bearbeitbares CMS bevorzugen.


Wie bereits erwähnt, kann man das Schneller nicht beantworten, ohne die genaue Webseite, deren Daten und auch den Server zu kennen.
Werden die Daten life generiert (bei jedem Zugriff) oder gibt es eine Cache, bzw. ein Zwischending, wo nur gewisse Teile vorgeneriert/gecached sind
oder sind alle Daten bereits fertig auslieferbar?
Bei Letzterem kommt es dann nur noch daauf an, wie schnell der Speicher (Dateisystem oder DB) die Daten liefern kann.

Man nehme nur mal das alte QC von Borland/Embarcadero, wo am anderen Ende kein "normaler" Webserver, sondern ein Delphiprogramm hängt.

PS: http://www.opensourcecms.com/

[Delbor]

Hi mm1256

Danke für deine Antwort.
Der Provider stellt ADSL zur verfügung - zahlenmässig weiss ich jetzt gerade nicht auswendig, wie gross die Bandbreite ist, aber das dürfte wohl guter Durchschnitt sein (so in etwa 30 - 35 kb/s).

Zitat:

Geht es nur um die Geschwindigkeit (Seitenaufbau) oder auch darum, was ist schneller realisierbar? Einfacher zu pflegen?

Der Seitenaufbau ist sicher mal zentral. Aber auch die Pflege/Weiterentwicklung der Site ist wichtig, werden meine Webseiten doch dynamisch mit Webbroker erstellt.
Im ersten Schritt werden Fotogalerien verwirklicht. Deren HTMLseiten dürften erstmal (fast) alle gleich sein, wobei die Dinger Platzhalter aufweisen, an deren Stelle Webbroker die HTML- bzw. CSS-Texte für die Menues, bzw. die Fotos einfügt. Dabei müssen bei jeder neuen Seite sämtliche Menues upgedatet/ersetzt werden.
Bei Verwendung einer Datenbank würden diese Änderungen vorerst auf meinem Rechner vorgenommen und anschliessend die DB auf dem Server upgedatet. Bei Verwendung einer filebasierten Website müsste das Menuefile und das zugehörige CSS-File jeder schon vorhandenen Seite ausgewechselt werden, einmal, weil das Menue jeder Seite ein neues Item enthält, aber auch, weil das Menueitem der aktuell sichtbaren Seite keinen Klick auslösen darf.

Zitat:

...und wie viele User gleichzeitig auf den Seiten sind.

Mein Hoster stellt mir 25 Datenbanken zur Verfügung - ich werde ihn mal danach fragen müssen, aber ich gehe davon aus, dass es sich dabei um Instanzen handelt, so dass gleichzeitig 25 Sessions ablaufen können.

Gruss
Delbor

[himitsu]

Ich glaub ja eher, daß du falsch rangehst.

Auch wenn das System dateibasiert ist, können Inhalte dynamisch sein.
Die Menüs könnten z.B. beim Auslesen generiert und an die jeweilige Seite angepasst werden. Dabei ist es egal ob die Daten dafür aus einer DB oder einer Datei kommen.



Die eigentliche Frage lautet doch:
Welche Systeme sind ausreichend genug, für mein Vorhaben, und was ist davon am effizientesten.

Und zusätzlich müsstst du dir noch andere Fragen stellen:

• wie will ich lokal mene Daten verwalten
• wie werden sie auf dem Server verwaltet
• wie lässt es sich für mich am Einfachsten Besten verwalten
• wie sieht es mit Backup und Co. aus
• was für Techniken will und kann ich überhaupt benutzen
  • statisch und ohne Laufzeitcode im Server
  • vorgefertigte Inhalte nur noch um Menü usw. erweitern
  • Templates mit Inhalten und Menüs füllen
  • alles komplett selber zusammensetzen (IntraWeb, WebSnap, WebBroker, ...)

Der Vorteil bei rein Dateibasiert ist, daß du nur einen Übertragungskanal hast.
> nur Dateien (z.B. FTP)
Ansonsten müsste man ja Dateisystem und Datenbank mit Daten füttern,
außer die veränderlichen Daten sind ausschließlich in der Datenbank und im Dateisystem ist nur der statische Teil der Webseite.
> dann halt nur eine DB-Verbindung

[Delbor]

Hi himitsu

Zitat von himitsu:

Was man bei der Webseite erstmal betrachen sollte, ob CMS oder nicht.
Es gibt immernoch genügend Leute, welche auf dem PC die Webseite bearbeiten/generieren und dann via FTP hochladen,
während andere eben ein sich selbt bearbeitbares CMS bevorzugen.

Das Webserverprogramm wird mit Delphis Webbrokertechnologie erstellt, wie ich oben schon geschrieben habe. Ich hab mir sagen lassen, dass das schon ein CMS ist. Da ich Typo3 halbwegs kenne, wollte ich es allerdings nicht so nennen.

Zitat von himitsu:

Werden die Daten life generiert (bei jedem Zugriff) oder gibt es eine Cache, bzw. ein Zwischending, wo nur gewisse Teile vorgeneriert/gecached sind
oder sind alle Daten bereits fertig auslieferbar?
Bei Letzterem kommt es dann nur noch daauf an, wie schnell der Speicher (Dateisystem oder DB) die Daten liefern kann.

Die Daten werden life per Stream generiert - entweder vom DB-BlobStream oder von einem Filestream an den Webbroker ContentStream übergeben. Dabei gibt es einen Stream, der die eigentliche Webseite liefert, einen HTML-MenueStream, einen CSS-MenueStream und je einen Stream für die anzuzeigenden Fotos.

Um meine Dateien auf den Server hochzuladen, habe ich WebMatrix zur Verfügung.

Gruss
Delbor

PS:

Zitat:

oder gibt es eine Cache, bzw. ein Zwischending, wo nur gewisse Teile vorgeneriert/gecached sind

Nein, bislang gibt es keinen Cache. In Bezug Caching werde ich mich noch genauer informieren müssen - Webbroker selbst cacht zwar auch, aber nur bis zur Auslieferung.

[Phoenix]

Aus Erfahrung (ich baue die letzten 5 Jahre ein CMS) kann ich sagen, alles, was Du aus Dateien ausliefern kannst, solltest Du auch auch Dateien ausliefern.

Zumindest, wenn das was Du auslieferst, auch einigermassen schnell sein soll.

Filebasiert hat viele Vorteile: Der Webserver und auch das Betriebssystem darunter haben viele Möglichkeiten das Zeug intern zu cachen.
Wenn Du Files da liegen hast, dann kann der Webserver zu Deinen Dateien die richtigen Cache-Header setzen (z.B. E-Tag, last Modified) und kann anhand der Fileangaben auch automatisch die richtigen Header zurücksenden (z.B. 304 Not Modified). Das ganze müsstest Du sonst für dynamischen Content alles selber bauen. Also sowohl das interne cacheing vor der Auslieferung als auch das korrekte Handling der Http Caches.

Statischer Content hat noch mehr Vorteile: Du kannst das, was statisch dort liegt, besser skalieren und ausfallsicher gestalten. Einfach das gleiche Zeug auf mehrere Webserver klatschen, ein Loadbalancer-Pärchen vorne dran, und gut ist. Wenn eine Kiste oder ein LB ausfällt übernimmt einfach ein anderer und gut ist.

Zudem braucht sowas natürlich deutlich weniger CPU und RAM, als wenn das alles zur Laufzeit berechnet werden muss. Das heisst man kann mit weniger Hardware eine deutlich größere Menge an Usern versorgen.

Lieferst Du dynamisch aus, musst Du zusätzlich noch dafür sorgen das auch die Datenbank ausfallsicher bereitgestellt wird. Denn fällt die DB aus, liefert Deine Anwendung sonst gar nichts mehr aus. Das erhöht die Komplexität der Systems um einiges. Und dann stellt sich die Frage: Kommt die Anwendung selber ohne Statushaltung aus? Wenn Du im Code sowas wie Sessions benutzt um den Zustand des Clients zu speichern, dann musst Du auch in der Lage sein, das irgendwo hin zu persistieren, für den Fall das ein Webserver ausfällt.

Das heisst natürlich nicht, das man zur Verwaltung hier keine DB nutzen sollte.
Aber ein Verfahren, das aus dem Inhalt in der DB den auszuliefernden Content (= die HTML-Generierung) nicht zur Laufzeit macht, sondern aus dem DB-Inhalt alles statisch vorgeneriert und dann lediglich ins Filesystem zur Auslieferung legt, ist der volldynamischen Generierung beim Request vorzuziehen.

Wie gesagt sowohl zur besseren Nutzung von Ressourcen (Hardware), zum besseren Handling von Skalierung und Ausfallsicherheit, als auch zur besseren Ausnutzung der eigentlich für die Auslieferung von statischem Content optimierten Webserver.

Man kann das natürlich auch mischen. Alles was geht, aus files, und wenn dann wirklich was dynamisch generiert werden muss, diesen Teil auf das nötigste beschränken. Ist letzten Endes immer ne Fallentscheidung, aber so als Richtlinie sollte man immer versuchen, Dateien den Vorzug zu geben.

[sx2008]

Ein Dateisystem ist übrigens auch eine Datenbank und zwar handelt es sich um eine Key-Value Datenbank.
Der Key ist der Dateiname inklusive Pfad und der Value ist der Inhalt der Datei. Die API ist im Betriebssystem integriert und Managementtools sind auch schon an Bord.

Man benötigt nicht immer eine relationale Datenbank sondern gerade bei Webserver reicht meistens eine NoSQL Datenbank aus.

Wenn man z.B. MySQL nur dazu verwendet um statische Blobs (z.B. JPegs, Html, Javascriptdateien) zu speichern und die Features von SQL (Joins, Aggregatfunktionen, Views,...) nicht in Anspruch nimmt dann hat man das falsche Werkzeug benützt.
Möchte man ein Forum abbilden (mit User, Benutzerechten, Unterforen, Tags, Suchfunktion,...) dann ist eine relationale Datenbank natürlich sehr nützlich. Es kommt halt immer auf die Anwendung an.

PS: statische Inhalte - also Dateien die vom Entwickler der Webseite erstellt wurden - sollte man immer als Dateien und nicht in einer rel. Datenbank speichern.

[Delbor]

Hi zusammen
Erst mal vielen Dank für eure ausführlichen Antworten. Sie enthalten interessantes Futter für meine grauen Zellen

Zitat:

Aus Erfahrung (ich baue die letzten 5 Jahre ein CMS) kann ich sagen, alles, was Du aus Dateien ausliefern kannst, solltest Du auch auch Dateien ausliefern.

Also fällt eine komplett DB-basierte Webserveranwendung aus. In einer DB wären allenfalls Angaben über registrierte Nutzer, ausgelieferte Cookies(?) etc abzulegen.
Ein Argument pro DB meinerseits war, dass die Daten da etwas besser vor Angriffen geschützt sein dürften.

Allerdings muss ich doch nochmal nachfragen; die Unklarheiten betreffen die Begriffe 'statisch' unhd 'dynamisch'. Unter statisch verstand ich bislang eine Webseite, die schon fix und fertig auf dem Server vorliegt, also mit dem kompletten HTML, CSS und allenfalls Javasript, bzw. verweisen im HTML zu Dateien, die CSS oder Javascript enthalten.
Unter 'dynamisch' verstand ich Webseiten, die zB. von Webbroker zusammengebaut werden. Hier kann ja die durch Platzhalter gekennzeichnete Stelle im HTML-String durch beliebige andere Inhalte ergänzt werden - einen CSS-String, der den Hintergrund rot färbt oder einen anderen, der grün färbt zum Beispiel.

So gesehen, wären meine Webseiten immer dynamisch, auch wenn Änderungen im Code nicht vorgesehen werden. Egal, ob die entsprechenden Inhalte aus einer Datei oder einer Datenbank (auf dem Server) stammen.

Zitat:

Das heisst natürlich nicht, das man zur Verwaltung hier keine DB nutzen sollte.
Aber ein Verfahren, das aus dem Inhalt in der DB den auszuliefernden Content (= die HTML-Generierung) nicht zur Laufzeit macht, sondern aus dem DB-Inhalt alles statisch vorgeneriert und dann lediglich ins Filesystem zur Auslieferung legt, ist der volldynamischen Generierung beim Request vorzuziehen.

Auf meinem Rechner läuft meine (Bild-)Datenbankapplikation(MySQL), mit deren Hilfe ich HTML-Seiten per Drag&Drop zusammmenstellen kann. Diese sollen dann per Webdav in meinem Webaccount auf dem Server abgelegt werden. Auf dem Server soll eine Webbroker-Anwendung laufen, die aus diesen Dateien die Webseiten zusammenbaut.
Konkret heisst das: es gibt eine TPageproducer, die Anhand des Requests eine bestimmte HTML-Seite lädt. An bestimmten Stellen des HTML-Strings sind Platzhalter eingefügt, die Webroker mit CSS, Bildaten etc ersetzt, indem er diese Daten per Filestream ausliest, wobei für HTML,CSS etc. jeweils eigene TPageproducers zuständig sind.
Wenn ich obiges Zitat richtig verstanden habe, plädierst du allerdings für ein Verfahren, das eine Datei vorsieht, die gleich nebst Html auch CSS und Javascript enthält und demnach nur noch die Bilder eingebunden werden müssen.

Gruss
Delbor