MySQL oder Filesystem?

[Ronny24]

Hallo,

ich programmiere leidenschaftlich gerne im Zusammenhang mit der Datenbank MySQL.
Nur in letzter Zeit bekomme ich immer wieder zu hören, dass ich die Finger davon lassen soll und lieber meine Daten in einem Filesystem abspeichern soll, weil anscheinend eine MySQL-DB bei einer hohen Zugriffszahl die Meldung *too many connections* bringt und dicht macht. Außerdem könnte, so sagt man der Provider (speziell Puretec) einfach den Hahn zudrehen und die Datenbank abschalten, wenn es zu viele Zugriffe werden. Nun zu meinen Fragen:

1. Stimmt das?
2. Was hat euch dazu veranlasst, ein Forum mit MySQL laufen zu lassen?
3. Was sind die Vorteile gegenüber Files?
4. Wenn ich davon ausgehe, dass bei mir die Besucherzahl explodiert, sollte ich mich dann für ein Forum auf MySQL-Basis oder File-Basis entscheiden?

Wäre für jede Hilfe dankbar, weil mich die Pessimisten schon langsam nerven.

MfG Rony

 

[style-guide!]

Die von Dir angesprochene FEhlermeldung kommt eigentlich nur, wenn die MySQL DB falsch konfiguriert ist oder aber der Server ein wenig für die Aufgabe falsch dimensioniert ist.

Auch könnte es von der Art der Programmierung abhängen, wie oft ein DB Server in die Grätsche geht....

Ich für meinen teil sehe bei der Verwendung nur Vorteile gegenüber der Verwendung des Filesystemes...

Forenbsp: UBB und VB:

Ich habe noch kein UBB gesehen, wo gleichzeitig ca. 1000 Uder online waren, ein VB hingegen schon.

Unterschiede der Forensysteme: VB auf DB Basis, UBB arbeitet mit dem Filesystem und einzelnen Dateien.

 

[digleu]

also ich hab nur gehört, dass Files langsamer arbeiten als ne mysql-db
ausserdem könnte purtec nicht nur die db einfach dicht machen sondern auch die ganze internetpräsenz, weil der filezugriff zu hoch ist (ich glaube die Rechenleistung dafür ist höher, weil mysql auch geschickt bufferd und sowas... also könnte ich mir denken, bin ja kein profi )

mfg digleu

 

[kutiku]

also, ich wüßte nicht warum das filesystem langsamer sein soll!

Eine DB speichert doch ihre Daten auch im FS!
Nur das es das organisiert macht, und geschickt sortiert!

Also, wenn Du deine Daten durchsuchen möchtest und Sie fett sind und Du Dir keine ausgefeilten Such, Sortier, Einfüge, Entferne Algorythmen ausdenken möchtest (und keine Rücksicht auf gleichzeitigen zugriff nimmst), dann nimm eine DB!

Ansonsten nimm files, da dies schon schneller (aber das ist fast egal) ist (Du sparst Dir die kommunikation und Prozessorleistung von mySQL).

 

[Michael B.]

Hm, eine ANmerkung:

100 Zugriffe auf Dateien belasten den Server 100 mal mehr als 100 Suchabfragen in einer MySQL DB.

Man muss immer sinn und nutzen sehen.

Bei MySQL wird nur auf eine Datei zugegriffen, bei FS eben auf 100. Die RAM Belastung mag bei MySQL höher liegen, aber die Prozessorbelastung ist eben noch gering.

Und wer nen guten Hoster hat, hat selbst bei 200 oder 300 gleichzeitigen MySQL Queries ne geringe Belastung, während das bei FS nicht der Fall ist, 100 gleichzeitge Festplattenzugriffe kann mann nicht kompensieren.

MfG

 

[Albu]

Also der Tipp auf Flat Files zu setzen, statt auf ein DBMS ist schon etwas kurzsichtig...

Es mag sein, daß ein Flat File System bei kleinen Datenmengen und einfach strukturierten Daten schneller und performanter ist, als eine vergleichbare DB Version. Aber:
- Durch Intelligentes Caching kann die DB einiges an Geschwindigkeit rausholen, wohingegen Flat Files nur als ganzes, einzeln vom OS gecacht werden können.
- Indexe und Hashes kann man in der DB einfach so anlegen, um Suchoperationen zu beschleunigen, bei Flat Files muß Du das extra programmieren und als eigene Datei ablegen.
- Komplexe Queries können ohne Probleme in der DB über SQL abgefackelt werden, eine Sprache die exakt für die Problematik bei großen Datenmengen geschrieben wurde. Mit einem einzigen SQL Befehl kann ich alle Datensätze der DB updaten, ein neues Feld hinzufügen, oder doppelte Einträge aufspüren, und das ohne einen einzigen Strich zu programmieren. In Flat Files sind nur einfachste Operationen möglich, da alles programmiert werden muß. Selbst das Sortieren der Daten nach einem anderen Kriterium erfordert langwieriges Umorganisieren.
- Locking ist in DBMSen auf Tabellen- oder Record-Basis möglich, sobald ich ein Lock ausgesprochen habe, so gehört das betroffene Objekt mir und kann von keinem anderen verändert werden. Locking bei Flat Files muß eigens programmiert werden.
- Lese und Schreib Zugriffe sind im DBMS alle über SQL möglich, für ein Flat File muß ich eine ganze Reihe von Programmbefehlen in der richtigen Reihenfolge zusammenstecken (Natürlich schreibt man das nur einmal und benutzt das dann als Klasse, aber man muß es schreiben!!).
- Die Geschwindigkeit des Zugriffs steigt in einem DBMS bei gleichzeitigem Anstieg der Datenmenge in der DB i.d.R. nur geringfügig an. bei FlatFiles stößt allein schon das Filesystem an seine Grenzen wenn mehrere tausend Dateien in einem Verzeichnis rumliegen (geschweige denn die Zugriffsdauer... schon mal ein ls -al in einem Verzeichnis mit > 3000 Dateien gemacht??) .
- Portierbarkeit: Eine richtig programmierte DB-Anwendung kann ich auf beliebigen DBMSen laufen lassen, ohne daß ich größere Umbauten oder Datenverluste hinnehmen muß. Wenn ein Flat File System plötzlich von Unix auf Windows umgestellt wird, könnte es sein, daß es Namenskonflikte gibt, weil Windows nachweislich keine Unterscheidung zwischen groß und klein macht.....
- Aufwand: Vom Aufwand her ist eine DB Anwendung geringer einzuschätzen, als eine gleichwertige Flat File Anwendung. Zumal man bei Flat Files immer irgendwelchen Einschränkungen unterworfen ist.

Mit Sicherheit wirst Du jetzt an Gegenbeispiele denken und das ein oder andere Argument aus den Angeln zu hebeln versuchen, aber ich rede hier nicht von Peanut Anwendungen sondern eher von Business Anwendungen. Und selbst ein noch so kleines Forum wird irgendwann mal so groß werden, daß eine Flat File Lösung einfach nur schnarcht.