Community ohne Datenbank bauen?

[BTCStorage]

Hallo, ich habe zur Zeit die Idee eine Community Webseite zu bauen und ich will das gerne ohne Mysql Datenbank aufbauen. Anstelle von Mysql habe ich mir gedacht, das ich Daten in Json Dateien speichern kann und dadurch auch weniger Risiken habe wegen zum Beispiel Mysql Injection oder anderen aehnlichen Sachen. Aber genrell ist meine Idee das ich die Performance der Webseite damit vielleicht steigen kann indem ich ohne Datenbank arbeite, so koennte man sich Datenbankabfragen sparen usw. Ist meine Idee realistisch oder habe ich da eine schwachsinnige Idee, ich koennte einnige Tipps von erfahren Leuten gebrauchen?

 

[Coca_Cola]

Ist natürlich die Frage was für ne Community Website das ist. Bei 5 Nutzern wird es egal sein, 5 Millionen sieht es wieder anders aus. Was spricht gegen eine Datenbank?

 

[Piktogramm]

[...]eine schwachsinnige Idee[...]

Die Antwort steckt in der Frage :=)

So solltest grob verstanden haben was eine Datenbank macht und was Json-Files sind. Dann wird eigentlich sehr schnell klar, wieso Datenbanken deutlich schneller sind.

Sicherheit ist auch kein Argument. SQL Injections ist ja nur eine Möglichkeit. CrossSiteScripting eine Andere. So oder so musst du dich damit beschäftigen, wie du den Eingaben von böswilligen Inhalten bereinigst bzw. prinzipiell verhinderst.

 

[Grantig]

Saublöde Idee.
Von der Performance her ist ein Filesystem bei vielen Zugriffen auf kleine Datensätze wesetnlich langsamer als ne Datenbank.
Von der Sicherheit her wird ne selbstgezimmerte Lösung von dir auch nichts taugen im Vergleich zu einem etablierten, gut getestetem und gut gewartetem Datenbanksystem.

Setz lieber auf ein etabliertes Datenbanksystem und benutz ein ORM Framework zum Zugriff darauf.

Btw. nach diesem Post würde ich dir keine Bitcoins anvertrauen

 

[pseudopseudonym]

ich koennte einnige Tipps von erfahren Leuten gebrauchen

Ich habe da nicht all zu viel Erfahrung (also überwiegend Hobby) und bin auf dem Gebiet eher Theoretiker als Praktiker. Dennoch:

• Du wirst keine Performancevorteile haben
• Du schaffst dir selbst sehr viel mehr Arbeit und Fehlerpotenzial
  • SQL-Injections fängst du dir so keine, dafür aber ganz andere Probleme. Stichwort ACID: https://de.wikipedia.org/wiki/ACID#Atomarität_(Abgeschlossenheit)

 

[BTCStorage]

Danke fuer eure Tipps. Generell ratet ihr alle davon ab ohne Datenbank das auf zu bauen. Das ist schon mal gut zu wissen das meine Einschaetzung nicht gestimmt hat.

Ich hatte gedacht das es vielleicht ein Vorteil sein koennte, wenn ich auf eine Mysql Datenabnk verzichte. Aber ich wurde nun von euch eines besseren belerht.

Wie ist es eigentlich wenn man eine Community Seite baut und Kommerzielle verschiedene Sachen anbiete, muss man dann fuer das Benutzen der Mysql Datenbank eine Lizen kaufen oder bleibt es trotzdem kostenlos?

 

[elix]

Daten persistieren ohne Datenbank ist eine Idee, mit der dein Projekt von vornherein dem Untergang geweiht ist. Es gibt viel zu viel Wichtiges zu beachten und bestehende Lösungen kümmern sich um das meiste davon mit built-in Lösungen.

SQL-Injection ist außerdem nur bei falscher Implementierung möglich, wer SQL-Abfragen mit User-Input zulässt, hat was falsch gemacht und sollte die Finger vom Thema lassen. Stichwort SQL-Parameter.

 

[Hancock]

Ok, du willst die Daten in einer Datei speichern.
Format: JSON
OK, wie etwas darin updaten?
Alles lesen, ändern speichern.
OK, wie Nebenläufigkeit?
File locking
OK, was mach ich, wenn ich nicht genügend RAM habe, um die JSON zu laden?
Dynamisch parsen
OK, das bietet die Möglichkeit für Fehler im Parser
Skalierung: Beschissen
OK, wie machen das andere?
Datenbanken
OK, ich will aber kein Client-Server-Ding
Dann nehm SQLite. Das skaliert aber nicht
OK, dann nehm MySQL
Das ist aber das, was alle machen.
Dito.

PS: SQL Injektions sind kein problem heutzutage (Prepared statements), das Problem heutzutage sind eher XSS, Information Disclosure und klassische Strukturfehler (also dass jemand mehr kann als er sollte) sowie klassische Programmierfehler.

Ergänzung (12. Mai 2020)

Ich hatte gedacht das es vielleicht ein Vorteil sein koennte, wenn ich auf eine Mysql Datenabnk verzichte.

es gibt viele Alternativen zu MySQL, aber die Idee ist quasi immer die gleiche.

muss man dann fuer das Benutzen der Mysql Datenbank eine Lizen kaufen oder bleibt es trotzdem kostenlos

Kostenlos, MySQL ist GPL, daher darfst du es einsetzten wie du willst.

 

[Dalek]

Die Idee gibt es so ähnlich bei manchen Content Management Systemen. Es spart die Administration und Wartung einer DB, aber diese Methode bringt einige drastische Einschränkungen mit sich.

Du kannst nicht suchen oder filtern außer du baust praktisch eine Datenbank selbst, du musst immer wissen welche Dateien du genau lesen willst. In einem Forum könntest du z.B. eine JSON Datei pro Thread schreiben. Zur Anzeige eines Threads wäre das effizient und einfach, wenn du jetzt aber die neuesten Beiträge anzeigen willst musst du das komplett zu Fuß selbst implementieren, was ansonsten 2-3 Zeilen SQL wären. Wenn jetzt noch Filter oder komplexere Sachen dazu kommen, wirst du die Datenbank wirklich vermissen.

Eine relationale Datenbank ist die Standardantwort für fast alle Fälle, und das hat auch seinen Grund. Die funktionieren einfach, und man kann die meisten häufigen Problemstellungen mit ihnen einfach lösen. Wenn man viel mehr Performance braucht gibt es natürlich spezialisiertere Methoden, aber dann sollte man auch wirklich wissen was man macht, und die Einschränkungen verstehen.

Meine erste Wahl wäre fast immer Postgres als Datenbank. Performance ist auch wirklich kein Problem wenn man das halbwegs vernünftig macht und es jetzt nicht Millionen von Benutzern gibt. Ich hab vor kurzen einen kleinen Test auf einem ASP.NET web service mit Postgres gemacht, eine Anfrage mit ~3 relativ trivialen DB queries, und das schafft ~2000-5000 requests per second auf meinem Desktop. Die Datenbank macht dabei 4000 Transaktionen pro Sekunde im Hintergrund. Das sind wirklich triviale queries, aber viele unterschätzen wie schnell so eine Datenbank sein kann. Und das ist kein besonders optimierter Fall, sondern komplett Standard mit vollem ORM dazwischen.

 

[Suxxess]

JSON wird von MongoDB genutzt...also so dumm ist die Idee nicht.
Schau dir das hier an: https://cmsstash.de/empfehlungen/flat-file-cms

 

[Dalek]

JSON wird von MongoDB genutzt...also so dumm ist die Idee nicht.
Schau dir das hier an: https://cmsstash.de/empfehlungen/flat-file-cms

Nicht als Storage Format, das ist BSON. Ich kenne mich mit MongoDB nicht aus, aber ich nehme an da ist dann noch eine ganze Menge drumherum an Indices und ähnlichem um Suchen zu ermöglichen. Das ist nicht vergleichbar mit einfach Daten in JSON auf die Festplatte zu werfen.

 

[Suxxess]

Es ging nur darum, dass Hancock es als Unsinn hngestellt hat, ist es halt nicht. Natürlich brauchst du halt diese Datenbank MangoDB z.B. nur JSON Dateien reichen nicht.

 

[Bodennebel]

Btw. nach diesem Post würde ich dir keine Bitcoins anvertrauen

Ey, die liegen sicher auf meinem USB-Stick. Mehr als 100.000 Kunden können nicht irren

 

[Hancock]

@Suxxess: Du kannst gerne in deiner DB JSON speichern (ist mittlerweile in vielen DBs mit drin inkl. MySQL) aber eine DB mit JSON als Speicherformat bringt nur Probleme.

 

[konkretor]

Ihr empfiehlt immer eine relationale Datenbank. Das muss nicht immer das Beste sein.

Ich würde erstmal klären welche Daten überhaupt gespeichert werden müssen.

Dann nochmals schauen

 

[BTCStorage]

Was ist den von der Performance her schneller, wenn man beispielweise ein Forum Topic in einer Json Datei speichert oder wenn man das in einer datenbank speichert?

Wenn man die Daten in der datenbank speichert wird das dann nicht auch im Datenbanksystem irgendwo als Datei gespeichert?

Irgendwie hatte ich die Idee diese ganzen Umwege vielleicht zu vermeiden und dann bessere Performance zu bekommen. Und wegen Suchabfragen koennte man eine Json Datei erstellen wo alle Forumbeitraege grob zusammen gefast gespeichert werden, also einzelne Stichworte aus jedem Topic.

Vom Aufbau her weis ich das es etwas umstaendlicher ist wenn man Json Dateien benutzt und ich weis auch das man MySQL Injection irgendwie gut genug vermeiden kann. Aber die groeste Frage die ich mir stelle ist, ob ich eine bessere Performance erreichen kann, so das alles schneller funktioniert auf der Webseite, wenn man keine datenbank benutzt. Den ich kann mich irgendwie grob daran erinnern das jemand mal sagte, mit der Zeit waechst die Datenbank und alles wird langsamer. Ich bin da leider auch kein Experte, man kann ja nicht in jeden Bereich alles wissen.

Ergänzung (12. Mai 2020)

SQL-Injection ist außerdem nur bei falscher Implementierung möglich, wer SQL-Abfragen mit User-Input zulässt, hat was falsch gemacht und sollte die Finger vom Thema lassen. Stichwort SQL-Parameter.

Wenn man beispielweise ein Forumbeitrag vom User in der Datenbank speichert, wie wuerdest du es dann machen, da kann man ja keine prepared statement benutzen, weil der User ein eigenen Text verfast hat welchen man abspeichert?

Soweit ich ich mich erinnern kann benutzt man dann in dem Fall die PHP Funktion "mysqli_real_escape_string" und speichert dann den Input vom User in der datenbank.

 

[Dalek]

Irgendwie hatte ich die Idee diese ganzen Umwege vielleicht zu vermeiden und dann bessere Performance zu bekommen. Und wegen Suchabfragen koennte man eine Json Datei erstellen wo alle Forumbeitraege grob zusammen gefast gespeichert werden, also einzelne Stichworte aus jedem Topic.

Sag mal so ganz grob welche Performance du erreichen willst? Wie viele Beiträge gibt es im Forum, und wie viele Nutzer greifen gleichzeitig darauf zu?

Datenbanken sind nicht so langsam wie du denkts, die haben da manchmal auch einfach einen unverdient schlechten Ruf weil gerade Webanwendungen wie Wordpress, Drupal und vermutlich auch viele Foren sehr ineffizient mit ihnen umgehen. Viele dieser typischen Webanwendungen sind sehr flexibel, aber machen dadurch viele unnötige Anfragen an die Datenbank und verbrauchen nebenbei auch noch anständig CPU.

Was du da vorschlägst ist praktisch das du eine eigene, spezialisierte Datenbank schreiben willst. Das kann man theoretisch machen, aber das ist viel, viel schwieriger als du es darstellst. Und ich würde wetten das es am Ende nicht schneller als eine gute Datenbankimplementierung wäre.

Ganz grundsätzlich, wenn man bei dieser Art Webanwendung mehr Performance braucht dann ist Caching das wichtigste. Wenn man ganze Seiten, oder auch einfach Beiträge cached, dann wird die Datenbank deutlich weniger belastet.

Wenn man beispielweise ein Forumbeitrag vom User in der Datenbank speichert, wie wuerdest du es dann machen, da kann man ja keine prepared statement benutzen, weil der User ein eigenen Text verfast hat welchen man abspeichert?

Bei parametrized bzw. prepared queries kann man die Parameter separat übergeben, das ist genau die Idee die auch die SQL injection verhindert. Die Query selbst ist statisch, aber man kann sie mit verschiedenen Werten als Parameter aufrufen, wie z.B. dem Text für einen Beitrag.

 

[Hancock]

Wenn man die Daten in der datenbank speichert wird das dann nicht auch im Datenbanksystem irgendwo als Datei gespeichert?

Ja, natürlich. Meist eine große Datei.

Den ich kann mich irgendwie grob daran erinnern das jemand mal sagte, mit der Zeit waechst die Datenbank und alles wird langsamer.

Und wie findest du deine Daten? Nehmen wir mal an, du speicherst einen Thread in einer JSON Datei. Da kommentieren 10k Leute. Jetzt willst du den Thread anzeigen. Was musst du tun:
1. Die JSON einlesen (1 fopen, 1 fread, 1 fclose)
2. In users/ alle JSONs lesen, damit du den Namen, die Beiträge, und die Signatur für die Leute anzeigen kannst. (10k fopen, 10k fread, 10k fclose)
Problem: Das ist echt viel für eine Webseite, und jetzt das Beste: normalerweise werden nur 20 Beiträge angezeigt, du musst aber immer die ganze JSON in Schritt 1 lesen.
Ergo: Overhead und zwar massiv.

Wie lösen das Datenbanken: 1. Caching, 2. Indizes, 3. Optimizer

Kannst du das Besser: Wohl eher nicht.

Vor allem, vergess nicht, dass das Dateisystem auch eine Datenbank ist, die nicht unbedingt auf das Zugriffspattern von Webseiten optimiert ist.

Wenn man beispielweise ein Forumbeitrag vom User in der Datenbank speichert, wie wuerdest du es dann machen, da kann man ja keine prepared statement benutzen, weil der User ein eigenen Text verfast hat welchen man abspeichert?

Der Text solltest du als BLOB behandeln, das wird in deinem Prepared Statement als "?" oder ":text" abgehandelt. Wenn du mit prepared statements irgendwo user input an $db->prepare übergibst, hast du Mist gebaut.

$db=get_db();
$prep=$db->prepare("insert into posts(text,user)(?,?)");
$prep->execute(array($_POST["text"],$userid));

($_POST["text"] auf XSS abklopfen oder so.)

 

[BTCStorage]

Sag mal so ganz grob welche Performance du erreichen willst? Wie viele Beiträge gibt es im Forum, und wie viele Nutzer greifen gleichzeitig darauf zu?

Im Moment ist noch nichts gebaut, ich bin noch bei der Planung und will mich Momentan fuer den Einsatzt der verschiedenen Techniken entscheiden. Aber ich denke wenn ich mal sowas wie 10K User erreichen sollte, dann bin ich schon weit ueber meine Ziele heraus. trotzdem will ich alles von Anfang an so optimal wie moeglich bauen.

Performance ist mir deswegen wichtig, weil Webseiten die sich schnell aufbauen sind beliebter. Wer hat schon Lust eine halbe Minute jedesmal zu warten bis sich eine Seite aufgebaut hat, da laufen einen die User doch davon. geschweige den von solchen nervigen Cookie Meldungen oder anderen Popup Fenster.

Im Prinzip will ich nicht mal ein richtig grosartiges Forum dort mit einbauen, aber Leute sollen schon miteinander chatten koennen, wenn alles nach Plan laeuft sollten mit der Zeit schon einige Daten zusammen kommen.

Also insgesamt denke ich sprechen eure Argumente schon fuer sich, es wird empfohlen eine Datenbank zu benutzen und dann diese datenbank lernen zu optimieren.

Ich frage mich zawr immer noch warum richtig grose Seiten wie Facebook keine Mysql Datenbank benutzen, ich kann mich nur noch ganz grob dran erinnern das ich dort was gelesen hatte, das die im Prinzip auch irgendwie die Daten so verteilen in einzelne Dateien, beziehungsweise mehr Richtung Mongo Datenbank und auch aehnlich wie meine Idee mit Json Dateien, wo man dann nur die Daten aufruft welche in der aktuellen Seite noetig sind.

2. In users/ alle JSONs lesen, damit du den Namen, die Beiträge, und die Signatur für die Leute anzeigen kannst. (10k fopen, 10k fread, 10k fclose)

Also sowas wie 10K fopen ist natuerlich voll daneben, wenn dann wuerde ich das irgendwie so versuchen auf zu bauen das in einer Json Datei alle Daten der aktuell aufgerufenen Seite stehen und dann vielleicht wenn noetig noch eine zweite Json Datei mit einer Art index Infos ueber einzelne User.

Naja ich sollte mir wohl ganz genau ueberlegen wie ich das aufbaue, und ich sage mal so im Nachhinein dann wieder auf eine datenbank das ganze um zu bauen sollte auch nicht ein Ding der unmoeglichkeit sein. Ich suche im Moment nur irgendwie infos die mich davon ueberzeugen koennten gar nicht erst mit datenbank das auf zu bauen, sondern doch mit json Dateien, aber aktuell sieht es mehr danach aus das die tipps dahin gehen eine Datenbank direkt zu benutzen.

 

[Hancock]

Für 10k Users reicht ein normales Forum wie man es überall bekommt.

Facebook verwendet verteilte Datenbanken. Das kann MySQL auch, aber ist für deine Ansprüche.

Das Problem bei deinem neuen Vorschlag, alles User in einer JSON zu halten: Ein Nutzer ändert etwas: Alle 10k User einlesen, ändern, speichern.
Oder Startseite anzeigen: 10k User einlesen und parsen.
Jedes Mal, wenn ein Nutzer sich anmeldet, hängt für alle anderen die Seite.

Falls du mal testen willst: Nextcloud lässt SQLite als Backend zu (das ist quasi eine durchoptimierte JSON Variante mit Binärformat und Indizes und eine echte ACId Datenbank), das läuft scheiße ab 5 Nutzer gleichzeitig. Eine richtige Datenbank packt locker 20 auf einem schwachen Rechner.

Ahh, fällt mir gerade ein, kennst du https://wiki.c2.com/?RulesOfOptimizationClub ? Du reißt Regel 1-4