Forum Datenbank

In meinem Spiel funktioniert die Datenbank des Forums nach dem folgenden Prinzip:
Es gibt eine Zentrale Datei, in Der alle Foren samt Name und letztem postdatum gelistet sind. Für jedes Forum gibt es jetzt ein eigenes Verzeichnis, in dem es eine Zentrale datei gibt , in der die Threads in der richtigen Reihenfolge gelistet sind. Ausserdem hat jeder Thread eine eigene Datei, in dem die posts gespeichert sind. Wenn ein neuer thread eröffnet wird, dann wird einfach eine neue Datei erstellt und wenn ein neuer post gemacht wird, so wird dieser Text (samt dazugehöriger Structvariable) unten drangehängt. Indizes verwende ich in dieser Datenbank nicht.
Alle Dateien sind binärdateien.
Nun habe ich gehört, dass so viele Dateien sehr schlecht für die Performance sind. Und da ich das Forum eh etwas reformieren will, hab ich mir überlegt, ob ich vielleicht gleich auch noch die Struktur dieser Datenbank ändere.
Zum beispiel die folgende Möglichkeit:
Es gibt nur 3 Dateien: Eine für die Forumsübersicht, eine in der die Threads gespeichert sind (samt der Angabe in welchem Forum sie sind) und eine Datei mit den ganzen Posts.(wo auch bei dem post der dazugehörige Thread angegebn wird.
Und bei Programmstart werden alle dateien eingelesen und Indizes erstellt, welche posts in welcher Reihenfolge in welchen Thread gehören. Diese Indizes werden dann persistent im Ram gehalten. Und wenn ein post editiert wird, dann werden nicht mehr die ganzen anderen posts in der Datei verschoben. (Das können ja mehrere MB sein) sondern der alte psot wird einfach als gelöscht markiert und der editierte hinenangehängt.
Währ das so wirklcih besser? Oder habt ihr noch einen anderen vorschlag? (bitte nicht vorschlagen, dass ich mir PHPBB oder so installieren soll. Ich will das ganze weiterhin als stand - alone Applikation benutzen.)

Nur mal zum Verständnis - redest Du von "Dateien" oder einer "Datenbank"?

Eine eingebettete Datenbank wie SQLite oder die Microsoft Jet-Engine (falls Windows) wäre keine Lösung?

Deine Lösung mit nur 3 Dateien ist meiner Meinung nach definitiv fast die schlechteste, die man machen kann. Ein kleiner Blick auf meine phpBB-Datenbank zeit mir, dass bei mir allein die beiden Tabellen mit den Posts (einmal Posts und einmal die Texte dazu) ca. 70 MB sind (bei ca. 100.000 Beiträgen). Wenn du also ein relativ grosses Forum hast, dann lass die Finger davon.
Auch alle Beiträge zentral in einer Datei zu speichern (ob die nun im RAM liegt oder nicht, ist egal), ist sehr langsam, da dann ja immer die komplette Beitragsliste durchsucht werden muss, wenn du dir ein Thema anschaust (Verhältnis Thema zu Beitrag genauso wie Forum zu Themen, nur nicht ganz so schlimm). Lösung wären dabei Indizies.
Mein Vorschlag:
Lass es bei deinem bisherigen System mit den vielen Dateien für die Foren, Themen und Beiträge und hole die Themen und Beiträge der letzten zwei Wochen (oder so ähnlich) persistent in den Speicher. Dann hast du nicht so viele HardDrive-Zugriffe (Performance steigt) und hast aber auch nicht den ganzen Kram im RAM.

Also dein engagment in ehren, aber da reibst du dich an ner völlig falschen stelle sinnlos auf wenn du mich fragst.
Ich mein kein vorgefertigtes forum zu nutzen schön und gut kann ich noch ganz verstehen aber nun ne eigene Datenbank noch zusätzlich zu entwickeln, ist vergebene Liebesmühe.
Ich mein ich kann verstehen das du kein Datenbankserver nutzen willst.. aber es gibt genügend alternativen schon. Die das ziemlich sicher sicherer&performanter gelöst haben als du es werden wirst.
Und ja wenn ich grad mal kurz über schau 13k threads nur im .de forum bei uns.. da wirst du bei deiner lösung auch probleme bekommen von wegen freie inode nummern usw denk ich mal auf *nix systeme.
Dein 3 Datei ansatz ist wesentlich sinnvoller wenn du mich fragst. Allerdings würde ich da noch gleich zusätzlich einmal indiziert die indezes in ein seperates file schreiben so wie auch mysql. Warum willst das jedesmal beim start neuindizieren müssen? Der indizier vorgang wird ab einer gewissen zeit eine nicht gerade vernachlässigbare Zeit benötigen.
Für die Performance ist es wichtig das du deine Indezes im Ram behälst dann. Und nur zurückschreibst. Somit solltest du annähernd an die geschwindigkeit einer normalen db kommen ( das cachen der datei übernimmt normalerweise das *nix system von alleine) bis auf das dir die ganzen späße der schlüsselsuche fehlen usw.
Das öffnen vieler kleiner dateien ist alleine schon deswegen zu vermeiden weil du jedesmal x syscalls benötigst, rechteprüfungen, kernelmode switch etc... das ist nicht gerade vernachlässigbarer overhead.

Ich mein ich kann verstehen das du kein Datenbankserver nutzen willst..

Echt? Also mit indexsequentiellen Dateien und so einem Schrott hab ich das letzte mal vor 10 Jahren gearbeitet - dann hab ich die Vorzüge eines DBMS kennengelernt und kann mir nicht vorstellen, nocheinmal irgendsoeinen Käse wie DBase oder Betrieve einzusetzen...

Nur mal zum Verständnis - redest Du von "Dateien" oder einer "Datenbank"?

Wenn man Daten auf einer Festplatte abspeichert kann man doch schon von einer Datenbank sprechen. Oder wie würdest du das nennen?

Eine eingebettete Datenbank wie SQLite oder die Microsoft Jet-Engine (falls Windows) wäre keine Lösung?

Das ganze läuft auf Linux, ich möchte es aber auch mit Hilfe von cygwin auf Windows laufen lassen. Deshalb möchte ich nur ANSI-C und Standard gcc libraries verwenden. Und mit SQL währe das ganze ja kein Standalone Programm mehr.

Lösung wären dabei Indizies.

Dass Indizes bei der grosse Dateien Lösung unbedingt dabei sein müssen hab ich in meinem Post ja auch schon geschrieben.

Warum willst das jedesmal beim start neuindizieren müssen? Der indizier vorgang wird ab einer gewissen zeit eine nicht gerade vernachlässigbare Zeit benötigen.

Wenn der Programmstart 30 Sekunden länger dauert so ist das relativ egal, da das Programm ja Tage- wenn nicht sogar Wochenlang laufen soll. Aber das ständige Indizes auf der Festplatte speichern verlangsamt das ganze ja während dem Betrieb.
Ihr seid euch also nicht ganz einig, ob die vieldateien oder die 3 Dateien Lösung besser ist. Dann werde ich wohl einfach beim alten bleiben, da das weniger Arbeit ist.
Was vielleicht auch noch eine Idee ist ist, dass man bei Programmstart das komplette Forum in den Ram lädt und nur noch alle 24 Stunden alles auf die Festplatte speichert. Allerdings würde das ne Menge Ram Brauchen und ausserdem währe dann alles weg, wenn zwischendurch mal das Programm abstürzt oder so.

> Und mit SQL währe das ganze ja kein Standalone Programm mehr.
SQLite ist eine eingebettete Datenbank. Diese benötigt keinen weiteren Dienst, sondern läuft direkt mit.
Eine andere Möglichkeit wäre die BDB (Berkeley Database), aber die ist meines Wissens GPL.