Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: Webgamers. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

DaBu

Fortgeschrittener

  • »DaBu« ist der Autor dieses Themas

Beiträge: 524

Danksagungen: 68

  • Nachricht senden

1

Mittwoch, 11. Januar 2017, 11:22

Kampfberichte richtig speichern

Ich dachte mir, jetzt wo Holland sowieso in Not ist und hier im Forum ein kleiner Kampf um das Dateisystem entbrannt ist, stelle ich mal wieder eine Frage.

In meinem Spiel entstehen regelmäßig Kampfberichte. Wie der Name schon sagt, immer dann, wenn ein Kampf stattgefunden hat.

Erst einmal ein paar allgemeine Dinge zum Kampfbericht.

Es gibt immer folgende Werte:

- ID (int)
- RANDOM (string)
- Angreifer Spielername (string)
- Angreifer Koordinate (string)
- Angreifer Allianz (string) (keine Pflicht)
- Verteidiger Spielername (string)
- Verteidiger Koordinate (string)
- Verteidiger Allianz (string) (keine Pflicht)
- CKK Angreifer vorher (double)
- CKK Angreifer nachher (double)
- CKK Verteidiger vorher (double)
- CKK Verteidiger nachher (double)

Damit haben wir den simplen Teil des Kampfberichtes. Die genannten Felder sind immer mit Werten bestückt, mit der Ausnahme der Allianz, die könnten ggf. leer sein.
Diese Werte in der Datenbank zu speichern ist an sich keine dumme Idee, aber kommen wir zum Rest vom Bericht.

Der Rest des Berichts ist ein Array (in dem Fall als JSON) in welchem sehr variable Daten drinnen stehen. Zum Beispiel die Schiffe des Angreifers vor und nach dem Kampf sowie die Schiffe des Verteidigers vor und nach dem Kampf. Wenn Rohstoffe geplündert wurden, dann auch diese und wenn ein Spionagebericht erstellt wurde befindet sich eine Liste der Gebäude und Forschungen mit im Array.

Man sieht, der Teil ist sehr variable. Bis jetzt wurde dies alles immer in der Datenbank gespeichert, was ich inzwischen für keine gute Idee halte.

Man kann die Kampfberichte wie die Rechnungen in einem Onlineshop sehen, sie sind ohne jede Abhängigkeit gültig und können niemals mehr verändert werden.
Laut meiner Kenntnis speichert man Rechnungen eher nicht in der Datenbank sondern eher als einzelne Dateien irgendwo auf der Platte.

Deswegen war nun meine Idee, auch weg von der Datenbank zu gehen und das ganze in einzelne Dateien auszulagern.
Um Speicherplatz zu sparen würde ich dann lediglich alle Werte zusammen als JSON (oder ähnliches) in die jeweilige Datei schreiben.


Kommen wir nun zu meiner Frage.

Jeden Tag gibt es über 80.000 Berichte, es können auch mal 100.000 sein, also eher mehr wie weniger.

Aktuell werden diese wie oben beschrieben in die Datenbank geschrieben.

Wie sollte man diese am besten im Dateisystem ablegen?
Könnte es dabei zu Problemen kommen, also z.b. dass die Festplatte nicht mehr hinterher kommt?

Natürlich habe ich mir selbst auch schon Gedanken dazu gemacht, in der Theorie kann ich eine sehr große Menge an Dateien auf einer Ebene liegen haben,
allerdings macht dies eher weniger Spaß wenn man doch mal über die Konsole in einen der Ordner geht.

Deswegen könnte ich mir vorstellen anhand des RANDOM (der oben erwähnt wurde) eine Ordnerstruktur anzulegen, zum Beispiel könnte man die ersten 6 Zeichen nehmen und da dann jeweils ein Unterordner anzulegen.

Wenn man nur mal die Buchstaben von A bis Z nimmt, dann hätten wir auf der obersten Ebene die Ordner A bis Z und auf der zweiten Ebene in jedem Ordner noch einmal die Ordner A bis Z.... und so weiter.

Was sagt ihr dazu?
GigraWars - Dein nostalgisches Free2Play-Weltraum-Science-Fiction-Spiel.

simbad

Profi

Beiträge: 870

Wohnort: Berlin

Beruf: Software Entwickler

Danksagungen: 64

  • Nachricht senden

2

Mittwoch, 11. Januar 2017, 11:32

Kann man so machen.
Gerade wenn du die Notwendigkeit hast die Liste der Dateien mal anschauen zu müssen. Im Filesystem macht es keinen nennenswerten Unterschied wieviele Dateien da drin stehen. Eine Belastung für das Filesystem entsteht nur beim schreiben, da du aber im Schnitt 2 Files pro sekunde schreibst, ist das kein Problem.

Eine Frage, die man vielleicht noch schauen müsste, wie oft pro Sekunde wird denn so ein Bericht abgefragt. Wenn das auch eher im 2-3 mal pro Sekunden Bereich liegt, dann sollte das auch kein Problem sein.

Ein Zerlegen in Unterverzeichnisse ist sinnvoll weil zum Beispiel bei einem "rm *" alle Dateinamen auf die Kommandozeile des rm-Befehls gelegt werden. Den '*' wertet die Shell aus, nicht das Programm.

Ich erwarte also eher Probleme von diversen Tools als vom Filesystem.
„Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher.“Albert Einstein
Das Entwickler BLOG
Pierre-Romain Main Page

DaBu

Fortgeschrittener

  • »DaBu« ist der Autor dieses Themas

Beiträge: 524

Danksagungen: 68

  • Nachricht senden

3

Mittwoch, 11. Januar 2017, 11:48

Richtig, das rm Problem ist mir bekannt, hätte ich ruhig noch erwähnen sollen. (musste ich vor ein paar Monaten schmerzhaft selbst erfahren).

Die Berichte werden nur ganz selten abgerufen, d.h. im schnitt wird jeder Bericht ca. 2 mal aufgerufen.

Verstehe ich das richtig? Im Moment speicher ich die Berichte in der Datenbank und dies belastet doch im Endeffekt das Dateisystem genau so sehr wie ein Schreiben direkt auf die Festplatte.
GigraWars - Dein nostalgisches Free2Play-Weltraum-Science-Fiction-Spiel.

simbad

Profi

Beiträge: 870

Wohnort: Berlin

Beruf: Software Entwickler

Danksagungen: 64

  • Nachricht senden

4

Mittwoch, 11. Januar 2017, 11:57

Das nimmt sich nix. Eine DB hat ihre Stärken beim zusammenführen von unterschiedlichen Tabellen-Daten.
Sie hat auch einen hervorragenden Selektionsmechanismus. Das fehlt dir im File-System völlig, obwohl man auch das nachstellen kann.
Aber der Aufwand der betrieben werden muss um den SQL-Befehl auszuwerten, dann einen Plan erstellen wie man am effektivsten an die Daten kommt, Daten zusammensuchen und dann ausliefern, ist doch entschieden größer als wenn man an das OS nur ein fopen() schickt.
Solange du mit deinem Key direkt die Datei öffnen kannst, bist du wahrscheinlich schneller als die DB.
„Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher.“Albert Einstein
Das Entwickler BLOG
Pierre-Romain Main Page

BlackScorp

Moderator

Beiträge: 1 112

Wohnort: 127.0.0.1

Danksagungen: 179

  • Nachricht senden

5

Mittwoch, 11. Januar 2017, 12:00

Solange du mit deinem Key direkt die Datei öffnen kannst, bist du wahrscheinlich schneller als die DB.
Genau aus diesem Grund speichere ich statische Daten direkt als Datei ab und am besten auch noch so dass PHP es direkt versteht ohne hin und her zu konvertieren. Ein Kampfbericht ist gelaufen, kein Grund ihn in der DB zu haben
Qualität eines Codes misst man in WTF/Sekunde

simbad

Profi

Beiträge: 870

Wohnort: Berlin

Beruf: Software Entwickler

Danksagungen: 64

  • Nachricht senden

6

Mittwoch, 11. Januar 2017, 12:03

Man kann das Zeug auf einer eigenen Partition lagern und da dann die access-time einschalten.
MIt einem Cron-Job kann man dann alle Files die ein paar Tage nicht mehr zugegriffen worden sind zippen oder löschen oder sowas.
Das geht mit dem find Kommando und nem -exec super
„Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher.“Albert Einstein
Das Entwickler BLOG
Pierre-Romain Main Page

DaBu

Fortgeschrittener

  • »DaBu« ist der Autor dieses Themas

Beiträge: 524

Danksagungen: 68

  • Nachricht senden

7

Mittwoch, 11. Januar 2017, 12:04

danke euch. Zum Bericht kenne ich immer die ID und den RANDOM, damit sollte sich die Datei ja wieder finden lassen. Ich habe das "Design" für die Kampfberichte quasi einfach aus Faulheit oder Dummheit damals so übernommen. Ewig kann man die Fehler nicht mit sich schleppen und genau deswegen will ich das ganze jetzt Überarbeiten.


Wie würdest du den das Array in der Datei speichern?
GigraWars - Dein nostalgisches Free2Play-Weltraum-Science-Fiction-Spiel.

simbad

Profi

Beiträge: 870

Wohnort: Berlin

Beruf: Software Entwickler

Danksagungen: 64

  • Nachricht senden

8

Mittwoch, 11. Januar 2017, 12:07

Nimm doch HTML. Das dürfteste doch schon haben.
Wenn das angezeigt werden soll ist der Aufwand dafür gering. 10k pro Seite mal 11Mio sind 110GB Speicher.
„Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher.“Albert Einstein
Das Entwickler BLOG
Pierre-Romain Main Page

DaBu

Fortgeschrittener

  • »DaBu« ist der Autor dieses Themas

Beiträge: 524

Danksagungen: 68

  • Nachricht senden

9

Mittwoch, 11. Januar 2017, 12:17

Wir sind im Moment bei 44 Millionen Berichten, dass wären dann laut deiner Aussage 440GB Speicher, was dann doch etwas zu viel ist.

Ich benötige aber weiterhin die Möglichkeit die Daten auszulesen um sie z.b. über eine API weiter zu geben. (Es gibt die Möglichkeit einen Bericht im sogenannten KB Tool hochzuladen)

Deswegen brauche ich schon sowas wie JSON, XML, serial, array....

Da es recht wenig Speicherplatz brauch hatte ich mich bis jetzt immer für JSON entschieden.
GigraWars - Dein nostalgisches Free2Play-Weltraum-Science-Fiction-Spiel.

simbad

Profi

Beiträge: 870

Wohnort: Berlin

Beruf: Software Entwickler

Danksagungen: 64

  • Nachricht senden

10

Mittwoch, 11. Januar 2017, 12:24

Die 10k waren geraten. Aber ich denke mir das das in etwa so hinkommt.
Wie gesagt. Man kanns auch bei nicht Nutzung zippen. Dann reduzierst du das wahrscheinlich enorm.

Das nächst komplexere wären vielleicht JSON files. Aber da würde ich dann den kompletten Bericht als JSON speichern. Kann deine Datenbank das vielleicht bereits konvertieren? Bei PostgreSQL geht das glaube ich.
„Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher.“Albert Einstein
Das Entwickler BLOG
Pierre-Romain Main Page

DaBu

Fortgeschrittener

  • »DaBu« ist der Autor dieses Themas

Beiträge: 524

Danksagungen: 68

  • Nachricht senden

11

Mittwoch, 11. Januar 2017, 12:39

Zum testen kann ich auch einfach ein Script schreiben, was alle Berichte aus der DB ausließt und entsprechend so wie überlegt im Dateisystem als JSON hinterlegt.
Hatte eigentlich auf Erfahrungswerte gehofft.
GigraWars - Dein nostalgisches Free2Play-Weltraum-Science-Fiction-Spiel.

BlackScorp

Moderator

Beiträge: 1 112

Wohnort: 127.0.0.1

Danksagungen: 179

  • Nachricht senden

12

Mittwoch, 11. Januar 2017, 13:34

nicht array

Quellcode

1
2
3
4
5
6
7
$data = "<?php namespace OgameCloneXD\Reports".$userId.";
 class Report".$reportId." extends AbstractReport{

public $field1 = '".$someData."';
//even more fields
}";
file_put_contents("src/Reports/".$userId."/Report".$reportId.".php", $data);


nun kannst du deinen normalen autoload sogar nutzen, dein HTML kann sich verändert wie es will, du hast alles als php datei ablegegt und mit einem einfachen include hast du die Daten. ich würde aber in deiner composer.json sowas schreiben

Quellcode

1
2
3
4
"autoload": {
  "psr-4": {
	"OgameCloneXD\\Reports": "reports/",
  },


also zusätzlich den ordner reports für das Autoloading bereitstellen.

Mit php 7 wird es noch schneller.

EDIT: in die abstrakte base Report klasse kannst du sogar irgendwelche methoden einbauen die etwas berechnen oder so

die Ordner Struktur kannst du ja wie du es am Sinnvollsten will einsortieren, kannst <userId>/<Y-m-d>/Report1234 machen um die dateien schneller zu finden
Qualität eines Codes misst man in WTF/Sekunde

DaBu

Fortgeschrittener

  • »DaBu« ist der Autor dieses Themas

Beiträge: 524

Danksagungen: 68

  • Nachricht senden

13

Mittwoch, 11. Januar 2017, 13:46

Nette Herangehensweise, aber ein nicht so netter Namespace ?( .

Ich werde die Unterordner allerdings anhand des RANDOM Strings erstellen, da ich hoffe so eine bessere Verteilung zu bekommen.
Die Nutzer fliegen ja nicht gleichmäßig oft in der Woche und die Menge pro Nutzer ist auch sehr unterschiedlich.

Ich glaube gerade aber ich habe in meinem RANDOM so unpassende Zeichen wie z.b. einen Punkt.

Gibt es einen Grund warum du eine Klasse statt einem array bevorzugst? Aus meiner Sicht sprechen nur zwei Dinge dafür
1. Die von dir schon erwähnte abstrakte Klasse
2. Wenn man darauf zugreift ist es schöner damit zu arbeiten, weil die IDE entsprechend die "Felder" kennt.

Danke.
GigraWars - Dein nostalgisches Free2Play-Weltraum-Science-Fiction-Spiel.

BlackScorp

Moderator

Beiträge: 1 112

Wohnort: 127.0.0.1

Danksagungen: 179

  • Nachricht senden

14

Mittwoch, 11. Januar 2017, 13:52

Nette Herangehensweise, aber ein nicht so netter Namespace ?( .

Ich werde die Unterordner allerdings anhand des RANDOM Strings erstellen, da ich hoffe so eine bessere Verteilung zu bekommen.
Die Nutzer fliegen ja nicht gleichmäßig oft in der Woche und die Menge pro Nutzer ist auch sehr unterschiedlich.

Ich glaube gerade aber ich habe in meinem RANDOM so unpassende Zeichen wie z.b. einen Punkt.

Gibt es einen Grund warum du eine Klasse statt einem array bevorzugst? Aus meiner Sicht sprechen nur zwei Dinge dafür
1. Die von dir schon erwähnte abstrakte Klasse
2. Wenn man darauf zugreift ist es schöner damit zu arbeiten, weil die IDE entsprechend die "Felder" kennt.

Danke.

Ja der Namespace war halt ein Scherz :D,

wegen Random string, wir nutzen zb $subfolder = substr($randomString,-1,1);

quasi wir nehmen vom Random string den letzen buchstaben und verteilen dadurch dann die statischen daten.

PHPs arrays sind nicht wirklich Optimiert weil die sehr flexibel sind, du hast aber x felder die du mit eigenschaften in der Klasse einfach definieren kannst.

Aueßerdem hast du Opcodecache in PHP sprich beim zweiten include wird das Filesystem nicht angefasst
Qualität eines Codes misst man in WTF/Sekunde

DaBu

Fortgeschrittener

  • »DaBu« ist der Autor dieses Themas

Beiträge: 524

Danksagungen: 68

  • Nachricht senden

15

Mittwoch, 11. Januar 2017, 14:03

Ja genau diese Art von Unterordnern würde ich auch nutzen, nur mit ein paar mehr Ebenen.

Was mir jetzt noch fehlt ist eine Aussage ab wann ich Probleme mit der Anzahl an Dateien pro Ordner bekomme.
Also am besten Erfahrungswerte, das Dateisystem kann locker alle 44mio Berichte auf eine Ebene packen, aber ich denke mehr wie 5-10k Berichte sollten es wohl nicht pro Ebene werden.

Hat jemand Zahlen?
GigraWars - Dein nostalgisches Free2Play-Weltraum-Science-Fiction-Spiel.

BlackScorp

Moderator

Beiträge: 1 112

Wohnort: 127.0.0.1

Danksagungen: 179

  • Nachricht senden

16

Mittwoch, 11. Januar 2017, 14:11

leider habe ich keine Erfahrung mit der Anzahl wir haben gerade mal 500+ ordner pro hauptordner.


also da du ja schon die Daten in der DB hast, wärst du prädestiniert dafür uns mal paar Zahlen zu nennen;) vielleicht im nächsten Blog eintrag?

am besten du machst ein test in dem du auf dem server "ls -a" ausfürhst, dauert das "gefühlt" zu lange, mach noch mehr unterordner
Qualität eines Codes misst man in WTF/Sekunde

DaBu

Fortgeschrittener

  • »DaBu« ist der Autor dieses Themas

Beiträge: 524

Danksagungen: 68

  • Nachricht senden

17

Mittwoch, 11. Januar 2017, 14:33

Ich werde es dann mal mit 2 Ebenen und mit 3 Ebenen testen. Infos gibt es dann die Woche irgendwann in meinen Blog, auch gerne mit Zahlen.
Freu mich, dass du da mitließt, außer es war jetzt wieder ein scherz :D
GigraWars - Dein nostalgisches Free2Play-Weltraum-Science-Fiction-Spiel.

simbad

Profi

Beiträge: 870

Wohnort: Berlin

Beruf: Software Entwickler

Danksagungen: 64

  • Nachricht senden

18

Mittwoch, 11. Januar 2017, 14:36

nee machmal Zahlen.Ich glaub ich werd mir da ein Bookmark drauf machen.
„Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher.“Albert Einstein
Das Entwickler BLOG
Pierre-Romain Main Page

BlackScorp

Moderator

Beiträge: 1 112

Wohnort: 127.0.0.1

Danksagungen: 179

  • Nachricht senden

19

Mittwoch, 11. Januar 2017, 14:57

Ich werde es dann mal mit 2 Ebenen und mit 3 Ebenen testen. Infos gibt es dann die Woche irgendwann in meinen Blog, auch gerne mit Zahlen.
Freu mich, dass du da mitließt, außer es war jetzt wieder ein scherz :D

natürlich lese ich mit;) bei mir wird es was ähnliches im Gladiator spiel geben, nur komplexer. Alle generierten Kämpfe werden bei mir Gespeichert so dass ich immer wieder es mir ansehen kann.

Vielleicht wäre es sogar interessant zu wissen was besser ist (RAM nutzung, Speichernutzung, ladezeiten etc.).

DB vs JSON vs PHP Array vs PHP Klasse :D
Qualität eines Codes misst man in WTF/Sekunde

DaBu

Fortgeschrittener

  • »DaBu« ist der Autor dieses Themas

Beiträge: 524

Danksagungen: 68

  • Nachricht senden

20

Mittwoch, 11. Januar 2017, 20:48

Ich merke gerade, mein Testsystem hat nur 100 GB Speicherplatz.... es ist unwahrscheinlich, dass ich da sehr viel Zeit reinstecken werde, d.h. es wird wohl nicht passieren, dass ich die Formate alle ausprobiere. Das wäre eine Menge Code der für die Tonne ist.
GigraWars - Dein nostalgisches Free2Play-Weltraum-Science-Fiction-Spiel.

Ähnliche Themen

Social Bookmarks

Thema bewerten