Sehr lange Texte - MYSQL oder Dateien?

[Inselmensch]

Hi Leute,

ich bin grad echt am Grübeln.

Geplant ist ein System in welchem die registrierten Benutzer Texte von mehreren Seiten online hochladen können.

JEtzt frage ich mich, ob ich hier wie üblich einfach per MYSQL arbeiten soll. Oder lieber die TExte an sich in einer Datei aufm Server speichern soll.

Die Frage ist hier: ist MYSQL was das angeht performant genug oder sollte ich wirklich das DAteisystem (öffnen bzw. auslesen und schreiben der dateien) belasten.

Hat jemand von euch evtl schon erfahrungen gemacht diesbezüglich? Ich mein bei Bildern usw. verfährt man ja auch lieber per Dateisystem Aber das sind halt Texte die evtl auch einfach für Formatierungszwecke mal eben ausgelesen und angezeigt werden müssen .

Hat da wer erfahrungen machen dürfen?

Liebe Grüße

Inselmensch.

[Amstelchen]

MySQL's string-datentypen wie TEXT, MEDIUMTEXT und LONGTEXT können bis zu 2^16, 2^24 und 2^32 bytes speichern.

wenn du also eine variable anzahl an usern und texten hast, würde ich das durchaus in der datenbank speichern, allerdings userseitig begrenzen und nur reinen text und allenfalls keine binärdaten erlauben - nicht dass der user 4 GB grosse UDF/ISO-images hochlädt, falls das nicht ohnehin durch den webserver/die scriptsprache eingeschränkt wird.

wenn du, sagen wir 200 user hast, von denen jeder sein eigenes user-verzeichnis hat, kannst du das auch über das dateisystem machen.

\ www

 - css

 - misc

 - users

 \-- susi

  -- hansi

  -- seppi

alles was darüber hinausgeht, würde ich über eine userid und eine datenbanktabelle mit userid und text machen.

bedenke auch, dass die daten gesichert werden müssen, egal, ob sie direkt im FS liegen oder als datenbankdatei im FS. wenn du dir da leichter tun willst, kennt InnoDB z.b. automatisch erweiterbare datendateien, stichwort autoextend.

s'Amstel

s'Amstel

[Inselmensch]

danke für deine nette antwort.

könntest evtl noch etwas begründen? oder ist es dir schon zu spät?

ich will ja die aspekte der beiden methoden durchleuchten.

ich weiß beispielsweise, dass mysql EIGENTLICH damit klarkommen wird. ABER ich will ja auch, dass die seite flink genug ist und keine 10 Sekunden ladezeiten hat, weil gerade 100 leute gleichzeitig online sind um ihre daten zu aktualisieren. deswegen der thread.

an sich sind wir uns aber einig, dass datenbank schon okay ist/wäre.

rein von den userzahlen werden es sicherlich WEIT mehr als 200.

[Amstelchen]

hier kommt es zwar sicherlich hauptsächlich auf die dimensionierung des mysqld, aber auch des webservers an. ist letzterer vorgegeben, wird irgendein applikationsserver eingesetzt?

wenn 100 concurrent user ein UPDATE eines 50 MB grossen LONGTEXT machen, betrifft das nicht nur die datenbank. ein gutes cacheing, vorausschauend geplant, für das holen der daten, und ein sauberer datenbanklayer, der requests zügig verarbeitet, macht das aber sicher möglich.

ich würde das durch testen evaluieren. 20 clients, die parallele HTTP-requests absetzen, und dabei jeweils 50 MB an daten POSTen. wenn dann der webserver oder der mysqld in die knie gehen - sei es durch bottlenacks bei platten-I/O, oder netzwerk, oder CPU, oder... - dann siehst du das früh genug.

EDIT: wegen begründung - ich würde ungern, sei es aus administrativen gründen oder sonst, "WEIT mehr als 200" user samt deren texten über ein filesystem (sei es mit grep und find) verwalten wollen, wenn ich das mit SQL kann.

und nein, ist noch nicht zu spät, ich geh aber dann heia

s'Amstel

[Inselmensch]

ich würde das durch testen evaluieren. 20 clients, die parallele HTTP-requests absetzen, und dabei jeweils 50 MB an daten POSTen. wenn dann der webserver oder der mysqld in die knie gehen - sei es durch bottlenacks bei platten-I/O, oder netzwerk, oder CPU, oder... - dann siehst du das früh genug.

EDIT: wegen begründung - ich würde ungern, sei es aus administrativen gründen oder sonst, "WEIT mehr als 200" user samt deren texten über ein filesystem (sei es mit grep und find) verwalten wollen, wenn ich das mit SQL kann.

und nein, ist noch nicht zu spät, ich geh aber dann heia

s'Amstel

ich glaub, ich setz das system einfach in beiden varianten um, handelt sich ja "noch" um ein privates projekt . da darf man mehr zeit investieren.

dann wird mal getestet und das system welches überzeugt (nicht nur vom processing, sondern auch vom verwaltungsaspekt her) wird genommen.

was ich aber sagen wollte: ich würde natürlich per sql im dateisystem fall die pfade speichern. um nicht davon ausgehen zu müssen, dass textx1 irgendwo liegen müsste bla bla bla.

ansonsten weiß ich was du meinst, es ging mir lediglich um derartige dimensionen wegen extremen texten usw.

danke für deine hilfe falls es noch weitere meinungen zum thema gibt, wäre ich happy.

liebe grüße

inselmensch.

[Aiun]

das ist auch eine Frage der Details

- willst du durch den Text durchsuchen ?

- wird immer ein ganzer Text angezeigt oder können es auch mehrere in einer Anzeige sein ?

- Wie häufig werden die Texte geändert ?

- Wieviele User greifen gleichzeitig zu ?

ich würde es evtl. als Verschwendung ansehen, die Texte in die Datenbank zu legen, obwohl du sie nie dort brauchst. (z.B. Sql-Abfragen, übersichten, sortierung etz.)

dann eher (abhängig von den Details) die Variante nur Dateinamen in der DB zu hinterlegen. mit einem guten OR/Mapping sollte der unterschied im Quelltext nicht zu groß sein.

[geloescht_JesterDay]

Die Frage ist hier: ist MYSQL was das angeht performant genug oder sollte ich wirklich das DAteisystem (öffnen bzw. auslesen und schreiben der dateien) belasten.

Sicher ist MySQL performant genug. Im allgemeinen sind DB-Operationen immer viel performanter als Dateisystemoperationen!

Bilder macht man vorallem deshalb übers FS, weil sie dan leichter einzubinden sind etc Mit der Performance hat das denke ich nicht wirklich was zu tun. Es sei denn, der DB-Server wird eh viel genutzt, für wichtigeres. außerdem können bilder so vom Client gecached werden, was bei einer Abfrage aus der DB nicht unbedingt so toll zu machen wäre (und bei Skripten ja auch meist verhindert wird).

Also ja, von daher hat es schon Performance Gründe, aber nicht die du du anspricht direkt.

wir haben das früher mal gedacht, alle Bilder in unserem CMS (zumindest die "Systembilder") über die DB zu machen. Das hat halt einen ziemlichen Administations-Overhead. Einfach mal kurz ein Bild ansehen, ändern oder hinzufügen etc. ist da nicht. Auch das einbinden in die Seite ist übers FS leichter (man muss keine ID suchen o.ä.)

Ansonsten ist der Zugriff über eine DB aber, wie schonmal gesagt, performanter als über's FS selbst.

[geloescht_JesterDay]

ansonsten weiß ich was du meinst, es ging mir lediglich um derartige dimensionen wegen extremen texten usw.

Ich finde die Verwendung von "extem" in so Fällen immer lustig 200 Lese-/Schreibzugriffe auf vielseitige (also viele Seiten) Dokumente... Ich würde mal sagen, das bringt den MySQL-Server gerade mal zum Gähnen

Ein DB-Server, der mit bei den Zahlen an seine Grenzen stößt, wäre mit sicherheit nicht(!) so weit verbreitet im Web-Umfeld. Gerade im Hosting Bereich. Meinst du da hat jeder nutzer seinen eigenen Server? Da sind manchmal tausende User auf einem Server.

Und bei dir ist das ja nur 1 User, der eben 200 Zugriffe macht. Aber die mit Sicherheit nicht in 1 Sekunde. Also ich meine einen DB-User.

Ein DB-Server wird ja gerade für sowas gemacht, viele Zugriffe und schnell. Er hätte sein Ziel verfehlt, wenn deine Daten schon "extrem" wären

[Inselmensch]

Ich finde die Verwendung von "extem" in so Fällen immer lustig 200 Lese-/Schreibzugriffe auf vielseitige (also viele Seiten) Dokumente... Ich würde mal sagen, das bringt den MySQL-Server gerade mal zum Gähnen

Ein DB-Server, der mit bei den Zahlen an seine Grenzen stößt, wäre mit sicherheit nicht(!) so weit verbreitet im Web-Umfeld. Gerade im Hosting Bereich. Meinst du da hat jeder nutzer seinen eigenen Server? Da sind manchmal tausende User auf einem Server.

Und bei dir ist das ja nur 1 User, der eben 200 Zugriffe macht. Aber die mit Sicherheit nicht in 1 Sekunde. Also ich meine einen DB-User.

Ein DB-Server wird ja gerade für sowas gemacht, viele Zugriffe und schnell. Er hätte sein Ziel verfehlt, wenn deine Daten schon "extrem" wären

jop soweit hatte ich das auch im kopf, nur gehts mir an sich ja vielmehr darum, dass der DB-User 200 Anfragen an den MYSQL-SErver stellt und dieser im, sagen wir 2GB an texten zurückwirft.

das ist auch eine Frage der Details

- willst du durch den Text durchsuchen ?

im moment wäre eine derartige funktionalität nur ansatzweise angedacht. evtl gibts autoersetzungen von gewissen phrasen bzw. urls usw. usf.

- wird immer ein ganzer Text angezeigt oder können es auch mehrere in einer Anzeige sein ?

es könnten auch mehrere in einer anzeige werden. sprich die ersten ausschnitte eines textes in einer groben auflistung. bzw. die ersten zeilen eines textes als kurzer "anreisser"

je nach funktionalität halt. es wird auf jedenfall sehr viel mit den texten gemacht.

- Wie häufig werden die Texte geändert ?

wenn ALLES gut läuft, wird ein text einmal angelegt und dann nie wieder angefasst. aber änderungen können je nach user immer mal vorkommen. bzw. je nach user verschieden OFT vorkommen.

- Wieviele User greifen gleichzeitig zu ?

eine genaue statistik ist im moment noch schwer zu machen. aber ich rechne im moment mit knapp bzw. ungefähr 200 usern die tagtäglich stätig auf der seite aktiv sein werden. natürlich wird das ständig variieren . aus diesem grund halt ich mich mal vorsichtig mit der annahme an usern

ich würde es evtl. als Verschwendung ansehen, die Texte in die Datenbank zu legen, obwohl du sie nie dort brauchst. (z.B. Sql-Abfragen, übersichten, sortierung etz.)

das ganze projekt wäre von diesen texten sehr abhängig, sie werden zur diskussion freigegeben usw. usf.

das projekt handelt sozusagen mit den texten, warum ich mir aus diesem grund ja speziell die gedanken machen

dann eher (abhängig von den Details) die Variante nur Dateinamen in der DB zu hinterlegen. mit einem guten OR/Mapping sollte der unterschied im Quelltext nicht zu groß sein.

Das war mein erster Ansatz als ich darüber nachgedacht habe, was der mysql-variante das wasser reichen könnte. auch wenn ich nicht wirklich davon ausgehe, dass FS ein ersatz für eine datenbank ist. ich bin mysqlfan und weiß so im groben WAS ich damit leisten kann aber trotzdem zweifelt man bei manchen speziellen themen sehr oft an einem lösungsansatz deswegen der thread.

[geloescht_JesterDay]

jop soweit hatte ich das auch im kopf, nur gehts mir an sich ja vielmehr darum, dass der DB-User 200 Anfragen an den MYSQL-SErver stellt und dieser im, sagen wir 2GB an texten zurückwirft.

2GB an Daten vom FS sind auch 2GB Daten Ob der Prozessor mit dem FS beschäftigt ist oder dem mysqld... Das macht in dem Fall wohl wenig unterschied, nur das FS fragmentiert wohl mehr und bei vielen Einträgen (tausende pro Directory) macht das FS irgendwann schlapp. Eine DB wurde genau deswegen erfunden

Und 2 GB an Texten... hm... 1 Buchstabe = 1 Byte (Ich geh mal nicht von Unicode aus).

2 GB = 2048 MB

2048 MB = 2.097.152 KB

2.097.152 KB = 2.147.483.648 Byte

Also einen Text mit 2 Milliarden Buchstaben? Gehen wir mal von 10 Zeichen pro Wort im Schnitt aus, so sind das mehr als 200 Millionen Wörter.

Ich hab grade mal geschaut:

"Nach über sieben Monaten ununterbrochener Schreibtätigkeit hat der Industrieroboter »bios [bible]« alle 66 Bücher der Bibel vom 1. Buch Mose bis zur Offenbarung des Johannes auf Papierbahnen mit einer Gesamtlänge von 900 Metern geschrieben. Das sind bei den 1189 Kapiteln rund 31 000 Verse oder 800 000 Wörter."

200 000 000 Wörter = 250 Bibeln.

Willst du deiner Bibliothek Konkurrenz machen? Und das als Hobbyprojekt?

Nachtrag:

Außerdem musst du auch 200 sehr fleißige Benutzer haben, wenn von denen jeder im Schnitt mal eben 0,8 Bibeln in dein Projekt einstellt

[Inselmensch]

2GB an Daten vom FS sind auch 2GB Daten Ob der Prozessor mit dem FS beschäftigt ist oder dem mysqld... Das macht in dem Fall wohl wenig unterschied, nur das FS fragmentiert wohl mehr und bei vielen Einträgen (tausende pro Directory) macht das FS irgendwann schlapp. Eine DB wurde genau deswegen erfunden

Und 2 GB an Texten... hm... 1 Buchstabe = 1 Byte (Ich geh mal nicht von Unicode aus).

2 GB = 2048 MB

2048 MB = 2.097.152 KB

2.097.152 KB = 2.147.483.648 Byte

Also einen Text mit 2 Milliarden Buchstaben? Gehen wir mal von 10 Zeichen pro Wort im Schnitt aus, so sind das mehr als 200 Millionen Wörter.

Ich hab grade mal geschaut:

200 000 000 Wörter = 250 Bibeln.

Willst du deiner Bibliothek Konkurrenz machen? Und das als Hobbyprojekt?

Aus genau DIESEM grund hab ich den thread erstellt danke dir (bzw. euch allen!) vielmals für deine (eure, damit auch die Grammatik noch stimmen darf ) Mühe und kompetente hilfe. Ich war wirklich nicht sicher, aber mittlerweile bin ich überzeugt, dass meine Datenbank, meine neue Bibel speichern wird. HAHA

Was sich aus dem Projekt entwickelt weiß ich noch nicht, ist ja noch nicht online aber mal schauen ^^.