Sven Rautenberg: Perfomance (Datenbank oder Datei)?

Beitrag lesen

Moin!

Also, es handelt sich um Benutzerinformattionen dei gespeichert werden sollen. Hierbei würde ich diese Informationen entweder in einer Datenbank, oder in einer Datei speichern.

Welche Benutzerinformationen? Gib mal ein aussagekräftiges Beispiel. Und gib auch an, was du an Verarbeitung damit vorhast. Und insbesondere, warum da jede Sekunde neue Daten dazukommen, und warum 3 bis 4 Mal pro Sekunde der Zustand abgefragt werden soll.

Alle Benutzerinformationen von allen Benutzern in einer Datei oder einer Datenbank.

Es ist immer noch relevant, von welcher Datenmenge wir absolut sprechen (in Gigabyte), und wieviele Datensätze es ungefähr werden.

Die Datenbank oder Datei wird von allen Benutzern alle ca. alle 10 Sekunden auf Updates geprüft, bei einer hohen Benutzeranzahl käme da denke ich mal einiges an traffic und Zugriffen zusammen.

was denkt ihr?

Dateizugriffe sind langsam. Datenbankzugriffe sind langsam. Netzwerkzugriffe sind noch langsamer. Zugriffe auf RAM sind schnell.

Solange du nicht mehr Infos rausrückst, welche Aufgabe zu bewältigen ist, wie die näheren Umstände sind und was an Datenmenge zu erwarten wäre, kann man dir nichts raten - außer: Mache selbst einen Performancetest.

Nur mal so als Ideengebung, was performancerelevant ist: Angenommen, du speicherst die neuen Datensätze als CSV-Datei immer hinten dran, mußt aber zum einen die Anzahl der Datensätze und zum anderen die Summe der einzelnen Werte eines Feldes wissen.

Das bedeutet für jeden Lesezugriff: Die gesamte Datei muß für Schreibzugriffe gesperrt werden, sie muß komplett durchgelesen, jede Zeile gezählt und das Datenfeld summiert werden, und am Ende wird die Datei dann wieder freigegeben.

Das bedeutet: Lesezugriffe können parallel von mehreren Prozessen stattfinden, Schreibzugriffe allerdings behindern die gesamte Aktion dermaßen, weil der Schreibprozeß erst darauf warten muß, dass niemand mehr die Schreibsperre aktiviert hat, dann schreibt er (während dieser Zeit kann kein Prozess mehr lesen), und gibt erst dann die Datei wieder frei.

Die Erkenntnisse aus dem alten Self-Forum, bei dem XML-Dateien auf der Festplatte genutzt wurden, haben gezeigt, dass solch ein Verfahren von zu häufigen Schreibzugriffen extrem negativ beeinflußt wird - und in diesem Forum wird nicht jede Sekunde ein Posting abgesetzt - zumal damals für jeden Thread eine eigene Datei existierte.

Mit einer Datenbank muß man sich um das Locking der Dateien nicht mehr selbst kümmern, das übernimmt die Datenbank für einen. Diese kann, wenn sie gut ist, auch feineres Locking vornehmen (also beispielsweise nur die Spalten exklusiv sperren, die gerade aktualisiert werden sollen), als es bei einer Datei möglich ist. Außerdem kann sie mit Sicherheit intelligentere Caching-Mechanismen anwenden, indem sie die am häufigsten nachgefragten Datenbankinformationen im RAM behält. Trotzdem hast du Overhead alleine durch SQL und die Datenbank selbst.

Egal, welche Speicherart gewählt wird: Immer besteht natürlich die Möglichkeit, Schreibprozess und Leseprozess voneinander zu trennen. Das bedeutet, dass es eine Datei oder Datenbank gibt, in die nur geschrieben wird, und von der von Zeit zu Zeit eine Kopie gezogen wird, welche dann ausschließlich zum Lesen verwendet wird.

Diese ganzen Möglichkeiten sind aber extrem von der Aufgabenstellung abhängig. Konkret in deinem Fall: Warum und was kommt jede Sekunde zum Datenbestand hinzu? Warum müssen ALLE Clients alle zehn Sekunden eine Aktualisierung abfragen? Kann man die nicht auch im Bedarfsfall vom Server aus benachrichtigen? Und so weiter.

- Sven Rautenberg