Rolf b: 50 Mio Datensätze Zuordnung, Abfragen, Performance

Beitrag lesen

Hallo 1up :)

ich meinte auch nicht die Übertragung vom Gameserver zum Handy, dorthin schickt man natürlich nur die Fragen. Es ging mir um die Interaktion zwischen Gameserver und SQL Server.

Natürlich ist es kein Thema, 5000 Rows von einem SQL Server zu laden, wenn man allein auf der Welt ist. Aber wenn das eine Million Leute parallel tun, sieht die Sache schon anders aus. Dann braucht der SQL Server einen fetten Cache oder kommt recht schnell ins Schwimmen. Natürlich kann ich die Datenbank partitionieren und den SQL Server clustern (den Cluster brauche ich eh für Ausfallsicherheit) und damit das Problem durch Hardware erschlagen.

Das Problem, wie man am effizientesten prüft ob eine Frage schon gespielt wurde, kann man dann natürlich auch unterschiedlich lösen. Bei der von mit genannten Bitmap-Methode hat man deterministischen Aufwand und eine klar definierte Datenmenge.

Bei Verwendung einer Spielernummer-Fragenummer Relation kann ich einen Monte-Carlo Algorithmus probieren, d.h. drei Fragen zufällig bestimmen und per

SELECT frageId FROM SpielerFrage 
WHERE spielerID = :spielerID AND frageId IN (:frage1, :frage2, :frage3)

feststellen, ob eine Frage schon mal gestellt wurde. Mit einem Index auf (spielerID,frageID) ist das vermutlich eine schnelle Abfrage. Aber - wenn die Spieler viele Rows hat, wird sie eher nicht mehr auf eine Indexpage passen und daher doch zusätzlichen Leseaufwand im SQL Server auslösen. Bei Kollision würfele ich die kollidierenden Fragen neu aus und wiederhole die Query. Das klappt alles ganz gut, wenn die Quote bisher gespielter Fragen klein ist, aber das wird schnell schlechter (bei 10000 Fragen und 100 gespielten Fragen ist die Doublettenchance 3%, bei 1000 gespielten Fragen schon 27%, bei 2000 sind es 49% und bei 3000 sind es 66%. Sowas kann man natürlich per stored procedure rein im SQL Server abfackeln, ohne den Gameserver damit aufzuhalten, oder man kann gleich mehrere Fragen pro Kategorie erwürfeln und versuchen, die Query so geschickt zu gestalten dass sie pro Kategorie die erste ungestellte Frage zurückgibt.

Habe ich 3 ungestellte Fragen, muss ich sie in die Tabelle inserten. Jetzt wird es langsamer, weil ich einen ständigen Strom von INSERTs habe und daher regelmäßig unter Lese-Last die Knoten im Indexbaum spalten muss. Das ist bei meinem Bitmap-Vorschlag nicht der Fall, hier wird der Index im Wesentlichen nur gelesen, gespielte Fragen gelangen als Update in die entsprechende Row.

Aber letztlich hilft wohl nur eine Probeimplementierung und Lasttest :)

Rolf