nicht angemeldet
MySQL-Tabellenstruktur für Spielstatistiken
Glück auf!
Ich speichere Spielstatistikdaten aus einer API in einer MySQL-Tabelle. Diese ist aktuell wie folgt aufgebaut.
Spalten:
- id = Primärkey
- wbbid = Key des Spielers in Benutzerliste des Forums
- idSpielerSpiel = Redundanter Key aus Spielername und Spiel (hat mir die Ausgabe erleichtert)
- spielername = Spielername
- spiel = Name des Spiels (aktuell werden Daten aus 4 Spielen eingelesen)
- plattform = ps3/ps4 (für Playstation 3 oder 4)
- ... = einige grundlegenden Statistikwerte (wie spielzeit, siege usw.)
- j_rangfolge = Hier speichere ich ca. 500 Statistikwerte im json-Format (darum dreht es sich gleich)
- statsUpdate = Datum des letzten Updates der API
- tabUpdate = Datum des letzten Updates dieser Tabelle
- fehlgUpdates = Anzahl der aufeinanderfolgend fehlgeschlagenen Updates
Bei aktuell 4 Spielen und ca. 50 Spielern je Spiel habe ich so ca. 200 Datensätze.
Nun würde ich gerne in die Tabelle auch historische Werte aufnehmen. Bei einem täglichen Update würden die Datensätze somit um den Faktor 365 steigen = 73.600 Datensätze. Langfristig kommen auch noch neue Spiele hinzu und die Spielerzahl steigt auch langsam.
Im Zuge der Überarbeitung der Datenbankstruktur würde ich darüberhinaus gerne die Spalte mit den json-Werten abschaffen. Ich hatte mir das so vorgestellt, dass ich die obige Tabelle um die Statistikwerte (...) und die json-Spalte (j_rangfolge) bereinige und dafür eine neue Tabelle erstelle, die wie folgt aufgebaut ist:
- id = Primärkey
- sid = ID aus der Tabelle oben
- bez = Bezeichnung des aktuellen Wertes (z.B. spielzeit, siege usw.)
- kat = Kategorie des Wertes (z.B. Spieler, Fahrzeuge, Aufträge usw.)
- art = Art des Wertes z.B. prozent, boolean, kills ...
- wert = Wert (= der eigentliche Wert)
Ich weiß noch nicht, wie ich mit der Programmierung der Ausgabe am Ende klar komme, aber ich glaube das dürfte ich hinkriegen.
Was mir jedoch Sorgen bereitet ist die Anzahl der Datensätze. Denn je Datensatz aus der obigen Tabelle (73.000 DS) hätte ich jetzt noch ca. 500 Einzelwerte aus der neuen Tabelle => 36.500.000 (Datensätze!!!).
Wegen den 36.500.000 Datensätzen hab ich mich erstmal total erschrocken und bin dann zu der Erkenntnis gekommen, dass ich ja auch nur die letzten 10 Updates je Spieler abspeichern könnte.
Das macht dann (wenn ich mich jetzt nicht selbst verwirrt habe):
4 Spiele x 50 Spieler x 10 Datenstände x 500 Einzelwerte = 1.000.000 Datensätze
Fragen:
-
Sind 1.000.000 Datensätze (langfristig vlt. 2 - 3 Mio.) ein Wert mit dem man grds. (normalerweise) performant arbeiten kann?
-
Sollte ich die aktuellen und historischen Werte in zwei unterschiedlichen Tabellen speichern, um die häufige Abfrage der aktuellen Werte zu beschleunigen? Die Abfrage der historischen Werte bzw. der Entwicklung wird vmtl. weniger abgefragt und für die Standardausgabe nicht benötigt.
-
Wäre eine Tabelle je Spiel sinnvoll (bzw. bei obigen Aufbau zwei Tabellen je Spiel), wenn zwar der Aufbau der gleiche ist, aber die Daten eigentlich nie zusammenhängend abgefragt/benötigt werden?
-
Ist der angedachte Tabellenaufbau ansonsten ok oder stich euch direkt etwas ins Auge?
Wie immer gilt, dass ich versucht habe, nach besten Wissen und Gewissen, wesentliche Dinge zu erwähnen und unwesentliche Dinge rauszukürzen. Sollten mehr Informationen benötigt werden, reiche ich die gerne nach.
Freundliche Grüße Kackfohgel
-
Tach,
- Sind 1.000.000 Datensätze (langfristig vlt. 2 - 3 Mio.) ein Wert mit dem man grds. (normalerweise) performant arbeiten kann?
ja
- Sollte ich die aktuellen und historischen Werte in zwei unterschiedlichen Tabellen speichern, um die häufige Abfrage der aktuellen Werte zu beschleunigen? Die Abfrage der historischen Werte bzw. der Entwicklung wird vmtl. weniger abgefragt und für die Standardausgabe nicht benötigt.
Dafür sollte der Query-Cache selber sorgen.
- Wäre eine Tabelle je Spiel sinnvoll (bzw. bei obigen Aufbau zwei Tabellen je Spiel), wenn zwar der Aufbau der gleiche ist, aber die Daten eigentlich nie zusammenhängend abgefragt/benötigt werden?
nein, das klingt nicht nach einer guten Idee
- Ist der angedachte Tabellenaufbau ansonsten ok oder stich euch direkt etwas ins Auge?
Ich würde Lookuptabellen (gibt es dafür einen Fachbegriff?), wie du sie angedacht hast, vermeiden, wenn es geht. Sind die 500 Werte je Spiel gleichartig? Dann kannst du sie in eine Tabelle mit 500 Spalten tun. Brauchst du die 500 Einzelwerte in der Datenbank wirklich (z.B. zum suchen, sortieren, etc.)? Falls nein, dann lass sie im JSON.
mfg
Woodfighter-
Hallo woodfighter,
vielen Dank für deine Antworten.
Ich würde Lookuptabellen (gibt es dafür einen Fachbegriff?), wie du sie angedacht hast, vermeiden, wenn es geht. Sind die 500 Werte je Spiel gleichartig? Dann kannst du sie in eine Tabelle mit 500 Spalten tun. Brauchst du die 500 Einzelwerte in der Datenbank wirklich (z.B. zum suchen, sortieren, etc.)? Falls nein, dann lass sie im JSON.
Die Gleichartigkeit ist leider nicht durchgängig gegeben und betrifft nur einige wenige Spalten (etwa 20 der 500). Diese habe ich in meiner derzeitigen Konstellation als eigene Spalte (die ... Werte aus meinen Ursprungspost). Leider sind mittlerweile auch diesen festen Spalten im letzten Spiel vereinzelt nicht mehr verfügbar und leer.
An und für sich brauche ich die Werte aktuell nicht zwingend einzeln, aber es würde bspw. den Vergleich einzelner Spieler oder das Ermitteln eines Maximal-, Minimal-, Durchschnittswertes, Median o.ä. vereinfachen. Aktuell nicht vorgesehen, aber ich könnte mir gut vorstellen, entsprechende Ausgaben einzubauen.
Grundsätzlich bin ich aber erstmal froh, dass du mein grds. Vorgehen mit den json-Werten in einer Spalte nicht von vorneherein verurteilt hast; womit ich gerechnet hatte. Vlt. bewegt mich dies dazu, diesen Ansatz doch bei zu behalten.
Nochmal vielen Dank für deine Antwort; hat mir schonmal sehr geholfen.
FG Kackfohgel
-
Tach,
An und für sich brauche ich die Werte aktuell nicht zwingend einzeln, aber es würde bspw. den Vergleich einzelner Spieler oder das Ermitteln eines Maximal-, Minimal-, Durchschnittswertes, Median o.ä. vereinfachen. Aktuell nicht vorgesehen, aber ich könnte mir gut vorstellen, entsprechende Ausgaben einzubauen.
dann solltest du zumindest diese auslagern oder zusätzlich als Spalten anlegen. Wenn die dann pro Spiel immer noch unterschiedlich sind, kannst du entweder eine Tabelle für alle Spiele anlegen, wo dann halt häufiger null-Werte vorkommen oder je Spiel eine eigene Tabelle, die dann allerdings nicht mehr so einfach joinbar sind bei der Abfrage.
Grundsätzlich bin ich aber erstmal froh, dass du mein grds. Vorgehen mit den json-Werten in einer Spalte nicht von vorneherein verurteilt hast; womit ich gerechnet hatte. Vlt. bewegt mich dies dazu, diesen Ansatz doch bei zu behalten.
Grundsätzlich ist es sinnvoll Daten in einer Datenbank atomar zu halten, aber man muss halt auch wissen, wann Regeln gebrochen werden sollten (aber das ist dann halt keine Anfängerleistung mehr). Wenn ich also weiß, dass ich die Daten in den JSON-Strings immer nur als JSON-Strings brauchen werde, ist es sinnvoll den JSON-String als atomares Datum zu betrachten.
mfg
Woodfighter
-