Daten in "DB vs. Filesystem" :)

jens · Mittwoch 8. Februar 2006, 16:02

Ich hab mir schon öfters Gedanken gemacht, welche Daten in eine DB gehören und welche in die Datenbank... z.Z. ist eigentlich alles bei PyLucid in der DB...
Ich überlege allerdings ob es Sinn macht HTML-Templates, CSS-Styles und JS-Dateien in das Dateisystem zu legen. Der Grund: zu 99% werden die Daten gelesen und nur zu 1% geändert. Ist das lesen aus der DB nicht langsamer als vom Filesystem? Stichwort Chaching...

Allerdings ist das größte Problem IMHO, das man ein Verzeichnis erstellen muß und im chmod 777 geben muß, da Skripte i.d.R. als Nobody ausgeführt werden.
Das hält mich irgendwie davon ab. Die Überlegung: Beim Shared-Webhosting kann man evtl. in fremden Verzeichnissen schreiben wenn es *jeder* darf...

Was noch für DB spricht, man kann dort die "Dateien"/Daten leichter organisieren, mit IDs usw. Allerdings kann natürlich genausogut auf einen Dateinamen/Pfad verweisen...

Neben Inhalte wie halt HTML-Templates, CSS-Styles und JS-Dateien könnte man evtl. auch Konfigurationen in einer Datei schreiben... Die Frage ist, ob das geschickte parsen einer Config Datei (Also per Hand, statt das Modul ConfigParser) schneller oder langsamer als ein DB Zugriff ist...

Wie sieht ihr das ganze?

modelnine · Mittwoch 8. Februar 2006, 19:26

Ich hab mir schon öfters Gedanken gemacht, welche Daten in eine DB gehören und welche in die Datenbank... z.Z. ist eigentlich alles bei PyLucid in der DB...

Da wo Du Datenbank schreibst meinst Du sicherlich Dateisystem, oder?

Aber, zur Frage: im Normalfall präferiere ich eine Ablage jeglicher Daten im Dateisystem, weil ich dann als Benutzer schneller/besser an die Daten rankomme wenn ich mal was ändern will. Siehe zum Beispiel Konfigurationsdateien, bei Windows brauch ich einen Registry-Editor um sie zu verändern (ist ja im Endeffekt auch nichts anderes als eine hierarchische Datenbank), während ich in den meißten Fällen unter Unix nix anderes als einen Texteditor brauche um mir die Datei anzugucken. Zur Not brauch ich noch nicht mal den.

Datenbanken sind meines erachtens nur in folgenden Fällen gerechtfertigt:

1. Wenn man schnelle Suchen über die Daten haben will, nicht nur über den Primärschlüssel (der ja im Normalfall der Dateiname sein wird),
2. Wenn man bei den Inhalten einzelne Felder schnell verändern will (siehe zum Beispiel ein Pickle der im Dateisystem liegt, den muß ich bei einer Veränderung eines Feldes neu erstellen, vollständig, eine Datenbank erlaubt nur ein Feld eines Schlüssels, also einer Zeile, zu ändern, und das schnell), wobei das darauf ankommt wie ich die Dateisystemstruktur hierarchisch aufbaue,
3. Wenn ich Joins oder ähnliches brauche, also im Prinzip wie bei 1. erweiterte SQL-Funktionalität die ich nicht leicht emulieren kann.

Zugriffsgeschwindigkeitstechnisch macht es keinen Unterschied ob ich eine Datenbank habe oder das Dateisystem nutze; in beiden Fällen werden die Daten vom Betriebssystem gecached, und es sollte normalerweise zu vernachlässigender Overhead sein den man zur Kommunikation mit der Datenbank braucht, der aber natürlich umso größer wird je mehr Einträge ich in einer Tabelle habe, wobei auch Dateisysteme extrem langsam werden wenn ich viele Dateien in einem Verzeichnis habe.

Im Endeffekt kommts denk ich drauf an was Du präferierst.

Ganz davon abgesehen: es gibt auch Zwitter-Systeme. Zum Beispiel kann ich meine Daten in einer XML-Datenbank speichern, wo ich das Datei-Format auf der Platte noch relativ gut lesen und verändern kann, allerdings ein System draufsetze was bereits optimiert ist um nach bestimmten Knoten/Inhalten/etc. zu suchen. Mittels XPath lässt sich ein Großteil von SQL nachbilden, und die meißten Implementierungen von XPath sind entsprechend schnell; schneller als wenn man das im Dateisystem macht.

Wobei auch hier wieder gilt: XML ist eigentlich kein menschenlesbares Format, auch wenn es immer so gehyped wird. Also: benutze mit bedacht.

BlackJack · Mittwoch 8. Februar 2006, 23:19

modelnine hat IMHO einen Punkt für eine DB vergessen: Wenn es mehrere Schreiber gibt, die gleichzeitig auf die gleichen Daten zugreifen, dann ist es schön, dass sich die DB um den gegenseitigen Ausschluss und die Konsistenz kümmert.

Ansonsten wäre für so eine Webgeschichte, wenn deutlich mehr gelesen als geschrieben wird, vielleicht wirklich ein hybrider Ansatz überlegenswert. Zum Beispiel ist CSS doch meistens sehr statisch und kann vom Browser auch direkt per URL abgeholt werden anstatt erst durch ein Skript aus der DB geholt zu werden. Je nachdem wie (un)dynamisch die Site ist, kann man sicher auch nicht ganz so statische HTML-Seiten aus der DB ins Dateisystem verlagern.

modelnine · Mittwoch 8. Februar 2006, 23:40

modelnine hat IMHO einen Punkt für eine DB vergessen: Wenn es mehrere Schreiber gibt, die gleichzeitig auf die gleichen Daten zugreifen, dann ist es schön, dass sich die DB um den gegenseitigen Ausschluss und die Konsistenz kümmert.

Das ist definitiv kein Problem sich auch bei Dateien drum zu kümmern dass man gegenseitig bei der Bearbeitung ausschließt. Klar, bei der Datenbank bekommt man es "relativ" frei Haus mit, gerade mit den einfachen "Primitives" wie Transactions, die man natürlich im Dateisystem nicht hat, aber wenn's um das separate Zugreifen auf Daten geht ist die Benutzung von flock()* auch nicht umbedingt umständlich...

jens · Donnerstag 9. Februar 2006, 07:24

Gut das ich mal nachgefragt hab

Ich seh nämlich schon, das ich mit einer Umstellung gleich ein paar mehr Probleme hab. Ist zwar alles Lösbar, aber kostet Arbeit...

Noch ein Punkt für eine reine DB Lösung: Ein Backup kann natürlich leichter, bzw. in einem Rutsch mit einem SQL-Dump erledigt werden.

Vielleicht hab ich aber eine Andere "Lösung". Benutzung des Dateisystems nur für das Caching. Also z.B. sind die CSS Daten eigentlich in der DB, dort werden sie verwaltet. Nach einer Änderung schreib ich aber parallel ins Dateisystem.

modelnine · Donnerstag 9. Februar 2006, 11:08

Noch ein Punkt für eine reine DB Lösung: Ein Backup kann natürlich leichter, bzw. in einem Rutsch mit einem SQL-Dump erledigt werden.

Ahem... Nichts ist einfacher als ein Dateisystembackup:

Code: Alles auswählen

tar cvfj test data

jens · Donnerstag 9. Februar 2006, 11:14

Schon klar... Aber ein SQL-Dump muß man so oder so machen... Dafür hab ich ja ein Plugin schon fertig. Für ein Dateisystem Backup muß man sich was anderes einfallen lassen. Ist auch nicht so kompliziert, aber es muß gemacht werden

BlackJack · Donnerstag 9. Februar 2006, 23:52

modelnine hat geschrieben:
modelnine hat IMHO einen Punkt für eine DB vergessen: Wenn es mehrere Schreiber gibt, die gleichzeitig auf die gleichen Daten zugreifen, dann ist es schön, dass sich die DB um den gegenseitigen Ausschluss und die Konsistenz kümmert.
Das ist definitiv kein Problem sich auch bei Dateien drum zu kümmern dass man gegenseitig bei der Bearbeitung ausschließt. Klar, bei der Datenbank bekommt man es "relativ" frei Haus mit, gerade mit den einfachen "Primitives" wie Transactions, die man natürlich im Dateisystem nicht hat, aber wenn's um das separate Zugreifen auf Daten geht ist die Benutzung von flock()* auch nicht umbedingt umständlich...

Aber vielleicht unmöglich weil es vom Dateisystem abhängen kann. Bei NFS kann es sein das `flock()`s keine Wirkung haben. Klar kann man den gegenseitigen Ausschluss selbst programmieren, aber das ist unter Umständen nicht ganz trivial und wie Du ja sagst: Bei einer DB gibt's ACID frei Haus. Wenn man das alles braucht dann implementiert man im Endeffekt eine Datenbank nach. Davon gibt's schon ein paar in verschiedenen Ausführungen, so dass man nicht gleich eine 2GB Oracle Installation auf ein Problem werfen muss.

Grundsätzlich bin ich auch eher dafür gut zu überlegen was in eine DB gehört und was sich im Dateisystem verwalten lässt. Wenn man anfängt ACID zu implementieren, dann sollte man IMHO eine DB in Erwägung ziehen.

modelnine · Freitag 10. Februar 2006, 00:05

Bei NFS kann es sein das `flock()`s keine Wirkung haben.

Hmm... Im Normalfall ist flock() auch über NFS korrekt. Wenn es das nicht ist sollte man ernsthaft überlegen den NFS-Server zu wechseln.

Grundsätzlich bin ich auch eher dafür gut zu überlegen was in eine DB gehört und was sich im Dateisystem verwalten lässt. Wenn man anfängt ACID zu implementieren, dann sollte man IMHO eine DB in Erwägung ziehen.

Das seh ich nicht als Argument eine Datenbank zu benutzen. Es ist viel wichtiger wie die Inhalte aussehen ob man eine Datenbank benutzen sollte oder nicht, zumindest aus meiner Sicht. Aber, ja, darüber läßt sich gerade in so grenzwertigen Fällen die dann ja meißtens eben einen "Reimplementierung" von ACID bedeuten streiten.

jens · Freitag 10. Februar 2006, 07:54

OK, meine Überlegung ist nun folgende: Wie ich schon geschrieben hab, bleibt alles eigentlich beim alten. d.h. CSS, JS Daten/Dateien sind so wie jetzt in der DB hinterlegt und werden dort verwaltet.
Zusätzlich wird allerdings alle Daten ins Dateisystem geschrieben. Nachdem ein User eine Änderung in der DB vorgenommen hat, werden die Daten im Dateisystem ausgelagert. Und diese Dateien werden normal in's HTML eingebunden.

Nicht nur hier, sondern generell muß ich mir aber dann mal Gedanken zum locking von Daten in der DB machen. Zu [wiki]DB Transaktionen[/wiki] hatte ich schnell eine Wiki-Seite geschrieben, weil mir im IRC erklärt wurde, wie das geht. Kann mir jemand locking erklären bzw. eine Wiki-Seite zu schreiben?

Außerdem noch mal meine Frage, wie seht ihr das mit Verzeichnissen und chmod 777 ?