Welches DBMS für Browsergame?

[Montgomery C Burns]

Hi :D

In die engere Auswahl haben es (welch Überraschung *g*) MySQL und PostgreSQL geschafft, da andere Produkte entweder zu teuer, oder zu Feature-arm (bzw. zu exotisch) waren.

Falls jemand mit dem Begriff "Browsergame" nichts anfangen kann hier eine kleine Beschreibung der Eigenschaften:

1. nicht selten viele, gleichzeitige, schreibende DB-Zugriffe (Updates) auf die selben Daten (wenn es zum Krieg zw. den Parteien kommt) - blöderweise ist es gerade in solchen Zeiten wichtig schnelle Antwortzeiten zu haben wegen Punkt 4.
-> 1.1 dafür gibt es nicht selten aber auch Wochenlang kaum Belastung

2. Anzahl der Datensätze ändert sich kaum (selbst über einen längeren Zeitraum) (d.h. großteils select und update Abfragen)

3. es gibt eine Tabelle mit den Daten eines Users auf die so ziemlich jede andere Tabelle verweist + bei dieser Tabelle werden (voraussichtlich) oft row-level Locks mit anschließendem Update notwendig sein(*)

4. eine gewisse Ausfallsicherheit sollte gegeben sein, da eine Browsergame Community sehr unangenehm werden kann wenn das Spiel nicht geht, oder gerade während eines Kampfes "lahm" ist, daraus ergibt sich auch:
-> 4.1 einfache Möglichkeit automatisiert Backups anzulegen (DB kann dabei ruhig in einen nur-lese-Modus gestellt werden, da in der Nacht bzw. den Morgenstunden nur wenige aktiv sind - es sind ja fast alle in der selben Zeitzone)
-> 4.2 das DBMS sollte sich soweit möglich selbst wiederherstellen können

5. Transaktionen wären wünschenswert, da nicht selten Güter von A nach B bewegt werden

6. folgendes wird permanent geloggt, aber nicht automatisiert abgefragt d.h. falls etwas gelesen wird dann nur "händsich" (auch wenn über diverse Tools) + es gibt keine Updates
-> 6.1 bezüglich welcher User sich wann und wo angemeldet hat
-> 6.2 was ein User wann angestellt hat

(*) Es hängt ganz davon ab wer im Falle eines Kampfes, das austragen vom Kampf übernimmt:
-> Die DB (über stored procedures - sind die atomar? in dem Fall kann man auf Locks verzichten)
-> der Webserver (mod_php + apc, Locks sind notwenig)
-> der User selbst ("ajax", Locks sind notwendig + eine Fallbacklösung falls keine Antwort mehr kommt)
oder ob die Attribute dieser Tabelle  vllt. nicht doch besser auf mehrere Tabellen aufgeteilt werden sollten (in Benutzer Daten, und ingame Daten)

ich hoffe mal ich hab nichts übersehen...

Was könnt ihr mir empfehlen?

Ich würde mehr zu PostgreSQL tendieren:
1. wegen MVCC (damit ist Punkt 1 nur halb so schlimm - oder?)
2. Transaktionen und Fremschlüsselbeziehungen sind kein Problem (und falls notwendig kann der Kampf auch von der DB übernommen werden)
3. Punkt 4 ist auch kein Problem, wegen WAL

Der Grund warum ich mich noch nicht für pg entschieden habe ist letztendlich eigentlich nur weil Leute im IRC immer wieder sagen ich soll MySQL nehmen, weil das so schnell ist, und ein Browsergame genau das braucht - deswegen würde ich mir gern nochmal die Meinung von Experten einholen :D

Falls die Wahl auf MySQL fällt wird wohl unweigerlich InnoDB zum einsatz kommen, und da stellt sich eben die Frage inwiefern es Sinn macht MySQL + InnoDB zu verwenden, weil in dem Fall der Geschwindigkeitsvorteil von MySQL dahin ist - oder?
Außerdem dürfte Punkt 4. mit MySQL ein Alptraum sein (zumindest wenn man sich diverse Zwischenfälle bei Wikipedia ansieht) - oder?

Und noch eine Frage zum WAL von pg:
kann man den von Zeit zu Zeit entsprechend leeren, oder muss der immer vom anfang an vollständig vorhanden sein damit er auch nützt? (oder ist der nicht so groß das man sich diesbezüglich Gedanken machen muss?)

noch eine Kleinigkeit:
Irgendwelche vorschläge bezüglich welches Dateisystem in so einem Fall zu empfehlen wäre?

ohh, und bevor ich's Vergesse... THX! :D

[Alexander Brock]

Hallo Forum,

1. nicht selten viele, gleichzeitige, schreibende DB-Zugriffe (Updates) auf die selben Daten (wenn es zum Krieg zw. den Parteien kommt) - blöderweise ist es gerade in solchen Zeiten wichtig schnelle Antwortzeiten zu haben wegen Punkt 4.

Dann würde ich so wenig Indexe wie möglich verwenden, weil die bei Updates Zeit fressen.

-> 1.1 dafür gibt es nicht selten aber auch Wochenlang kaum Belastung

Mir ist leider kein DBMS bekannt, das während Phasen geringer Last häufige Abfragen vorberechnet (gibt es so was?).

2. Anzahl der Datensätze ändert sich kaum (selbst über einen längeren Zeitraum) (d.h. großteils select und update Abfragen)

Mit wie vielen Datensätzen rechnest du? Denke auch daran, dass die Community übelst krass wachsen könnte.

4. eine gewisse Ausfallsicherheit sollte gegeben sein, da eine Browsergame Community sehr unangenehm werden kann wenn das Spiel nicht geht, oder gerade während eines Kampfes "lahm" ist, daraus ergibt sich auch:
   -> 4.1 einfache Möglichkeit automatisiert Backups anzulegen (DB kann dabei ruhig in einen nur-lese-Modus gestellt werden, da in der Nacht bzw. den Morgenstunden nur wenige aktiv sind - es sind ja fast alle in der selben Zeitzone)
   -> 4.2 das DBMS sollte sich soweit möglich selbst wiederherstellen können

PostgreSQL erfüllt AFAIK ACID, d.h. bei einem Stromausfall (o.ä.) macht der Server nach dem Starten genau da weiter, wo er aufgehört hat.

6. folgendes wird permanent geloggt, aber nicht automatisiert abgefragt d.h. falls etwas gelesen wird dann nur "händsich" (auch wenn über diverse Tools) + es gibt keine Updates
   -> 6.1 bezüglich welcher User sich wann und wo angemeldet hat
   -> 6.2 was ein User wann angestellt hat

Dann würde ich möglichst wenige Indexe verwenden (eigentlich nur die notwendigen unique-constraints).

(*) Es hängt ganz davon ab wer im Falle eines Kampfes, das austragen vom Kampf übernimmt:
-> Die DB (über stored procedures - sind die atomar? in dem Fall kann man auf Locks verzichten)

Eine stored procedure kann bei PGSQL AFAIK problemlos eine Transaktion sein, also ja.

ich hoffe mal ich hab nichts übersehen...

Was könnt ihr mir empfehlen?

Ich würde mehr zu PostgreSQL tendieren:

1. wegen MVCC (damit ist Punkt 1 nur halb so schlimm - oder?)
2. Transaktionen und Fremschlüsselbeziehungen sind kein Problem (und falls notwendig kann der Kampf auch von der DB übernommen werden)
3. Punkt 4 ist auch kein Problem, wegen WAL

Der Grund warum ich mich noch nicht für pg entschieden habe ist letztendlich eigentlich nur weil Leute im IRC immer wieder sagen ich soll MySQL nehmen, weil das so schnell ist, und ein Browsergame genau das braucht - deswegen würde ich mir gern nochmal die Meinung von Experten einholen :D

MySQL ist nicht per se schneller als PostgreSQL, aber MySQL kann von mehreren Prozessoren und/oder Rechnern profitieren. PostgreSQL kann das AFAIK nicht.

Ich würde bei so einem großen Projekt zunächst ein Datenbank-Design für beide DBMSe machen, mit massenhaft Zufallsdaten füllen und Stresstests machen.

Gruß
Alexander Brock

[Montgomery C Burns]

1. nicht selten viele, gleichzeitige, schreibende DB-Zugriffe (Updates) auf die selben Daten (wenn es zum Krieg zw. den Parteien kommt) - blöderweise ist es gerade in solchen Zeiten wichtig schnelle Antwortzeiten zu haben wegen Punkt 4.

Dann würde ich so wenig Indexe wie möglich verwenden, weil die bei Updates Zeit fressen.

naja, die indizierten Felder werden (mal abgesehen vom Fremdschlüssel zur User Tabelle) kaum geändert

-> 1.1 dafür gibt es nicht selten aber auch Wochenlang kaum Belastung

Mir ist leider kein DBMS bekannt, das während Phasen geringer Last häufige Abfragen vorberechnet (gibt es so was?).

Darauf wollte ich nicht hinaus, wollte nur anmerken das es eben nicht dauernd so dahin geht...

2. Anzahl der Datensätze ändert sich kaum (selbst über einen längeren Zeitraum) (d.h. großteils select und update Abfragen)

Mit wie vielen Datensätzen rechnest du? Denke auch daran, dass die Community übelst krass wachsen könnte.

Die User kann man Notfalls begrenzen, geplante Zahlen:
ca. 200-300 User insgesamt aufgeteilt in jeweils ca. 50 User pro "Spielplatz" (man kann zw. den einzelnen Spielplätzen reisen)

• ca. 900k Gegenstände um die gekämpft wird, die nachher (Schrittweise) auf 1,2M erweitert werden (also von 150k für jeden Spielplatz am Anfang, und später 200k)

• ca. 4-6M Items ("Kampfinstrumente und Rüstung") (100 items pro User, pro Itemkategorie, pro Level, bei voraussichtlich 20 Leveln)

• ein Forum, das wird dann aber ein anderer DB-Server (MySQL) übernehmen

4. eine gewisse Ausfallsicherheit sollte gegeben sein, da eine Browsergame Community sehr unangenehm werden kann wenn das Spiel nicht geht, oder gerade während eines Kampfes "lahm" ist, daraus ergibt sich auch:
   -> 4.1 einfache Möglichkeit automatisiert Backups anzulegen (DB kann dabei ruhig in einen nur-lese-Modus gestellt werden, da in der Nacht bzw. den Morgenstunden nur wenige aktiv sind - es sind ja fast alle in der selben Zeitzone)
   -> 4.2 das DBMS sollte sich soweit möglich selbst wiederherstellen können

PostgreSQL erfüllt AFAIK ACID, d.h. bei einem Stromausfall (o.ä.) macht der Server nach dem Starten genau da weiter, wo er aufgehört hat.

aber MySQL nicht :,(

6. folgendes wird permanent geloggt, aber nicht automatisiert abgefragt d.h. falls etwas gelesen wird dann nur "händsich" (auch wenn über diverse Tools) + es gibt keine Updates
   -> 6.1 bezüglich welcher User sich wann und wo angemeldet hat
   -> 6.2 was ein User wann angestellt hat

Dann würde ich möglichst wenige Indexe verwenden (eigentlich nur die notwendigen unique-constraints).

Hierfür wäre MySQL mit MyISAM genau das richtige - oder?

Ich hatte mir auch überlegt hierfür Textdateien zu verwenden, aber das ist dann doch zu umständlich um es zu handhaben :\

(*) Es hängt ganz davon ab wer im Falle eines Kampfes, das austragen vom Kampf übernimmt:
-> Die DB (über stored procedures - sind die atomar? in dem Fall kann man auf Locks verzichten)

Eine stored procedure kann bei PGSQL AFAIK problemlos eine Transaktion sein, also ja.

Hmm? Transaktionen sind aber nicht Atomar...

MySQL ist nicht per se schneller als PostgreSQL, aber MySQL kann von mehreren Prozessoren und/oder Rechnern profitieren. PostgreSQL kann das AFAIK nicht.

Wieso Soll pg nicht mehrere Prozessoren sinnvoll verwenden können? Außerdem gibt es für pg auch Replikationslösungen (aber ich hoffe stark auf diese verzichten zu können)

Ich würde bei so einem großen Projekt zunächst ein Datenbank-Design für beide DBMSe machen, mit massenhaft Zufallsdaten füllen und Stresstests machen.

Ich hatte anfangs überlegt PEAR::DB bzw. ADOdb zu verwenden, hab die Idee dann aber wieder verworfen, weil viele gesagt haben das ist nur unnötiger Overhead und bringt im ernstfall nichts...

Aber gut, ein Testscript 2 mal verfassen dürfte nicht so viel Aufwand sein :>

[Rouven]

Hi,

Eine stored procedure kann bei PGSQL AFAIK problemlos eine Transaktion sein, also ja.
Hmm? Transaktionen sind aber nicht Atomar...

Transaktionen sind atomar, das ist ihr Sinn. Eine Menge von Befehlen abarbeitungstechnisch zu einem großen zusammenzufassen. Also entweder alle oder keiner. Wenn also das System eine SP als Transaktion auffasst, hast du das gesuchte erreicht.

MfG
Rouven

[Montgomery C Burns]

Transaktionen sind atomar, das ist ihr Sinn. Eine Menge von Befehlen abarbeitungstechnisch zu einem großen zusammenzufassen. Also entweder alle oder keiner. Wenn also das System eine SP als Transaktion auffasst, hast du das gesuchte erreicht.

Sicher?
Transaktionen werden zwar ganz oder gar nicht ausgeführt, aber atomar sind sie nicht, atomar heißt doch das die Transaktion nicht unterbrochen wird - und das muss man bei pg extra einstellen (siehe auch 12.2. Transaction Isolation) oder hab ich was falsch verstanden?

[Rouven]

Hi,

Transaktionen werden zwar ganz oder gar nicht ausgeführt, aber atomar sind sie nicht, atomar heißt doch das die Transaktion nicht unterbrochen wird - und das muss man bei pg extra einstellen (siehe auch 12.2. Transaction Isolation) oder hab ich was falsch verstanden?

Äh, jein, oder ja, oder nein, oder such dir was aus.
Also für die eigentliche Transaktion gilt: Ganz oder gar nicht, soweit ist sie atomar. Atomar hat NICHTS mit Unterbrechung oder Nicht-Unterbrechung zu tun, dafür ist der Scheduler zuständig. Atomizität garantiert dir lediglich, dass entweder alle oder keine Änderung ankommt.
Das andere ist wirklich die Isolation: Durch die von dir verlinkten Einstellungen bestimmst du das Verhalten vom Rest des Systems während deine Transaktion läuft. Soll heißen: Darf eine andere Transaktion schon Daten lesen während deine eine kurz unterbrochen ist (und damit möglicherweise auf Daten arbeiten, die nach einem ROLLBACK nicht mehr da sind) und wenn sie das darf auf welche Datensätze darf sie denn eigentlich.
Am sichersten ist natürlich Serialisable, damit kommt es nicht zu inhaltlichen Unterbrechungen weil man keine Transaktion an die Daten einer anderen dran lässt. Aber das bremst das System enorm aus, weil man Satz 1 nicht lesen darf während man Satz 5 aktualisiert.

MfG
Rouven

[Sven Rautenberg]

Moin!

Der Grund warum ich mich noch nicht für pg entschieden habe ist letztendlich eigentlich nur weil Leute im IRC immer wieder sagen ich soll MySQL nehmen, weil das so schnell ist, und ein Browsergame genau das braucht - deswegen würde ich mir gern nochmal die Meinung von Experten einholen :D

Experten meinen: Postgres kann auch schnell sein, aber egal welche Datenbank du wählst: Features kosten Performance.

MySQL ist deswegen in den Ruf gelangt, so schnell zu sein, weil sie seinerzeit kaum "echte Datenbankfeatures" angeboten hat, Dinge wie referentielle Integrität, Fremdschlüssel, Stores Procedures, Transaktionen, Subselects, Prepared Statements - alles Fehlanzeige, das durfte sich der DB-Programmierer alles selber machen, wenn er es denn brauchte, und oftmals war es unrealisierbar.

Tatsächlich aber dürften Aussagen wie "MySQL ist schneller als Postgres" oder umgekehrt sehr fragwürdig sein. Denn es kommt immer konkret auf die tatsächliche Anwendung an, welche Datenbank tatsächlich schneller ist. Du wirst also vermutlich selbst nachmessen müssen, wenn du es wirklich wissen willst.

Und darüber hinaus geht es nicht unbedingt nur um Schnelligkeit, sondern auch um einfache Programmierung. Und bei der Programmierung selbst kann man natürlich auch noch einiges falsch machen und damit tausendmal mehr Zeit verschenken, als mit einer optimierten Datenbank jemals hereingeholt werden kann.

Nimm die Datenbank, die du selbst am besten für den Job brauchen kannst.

noch eine Kleinigkeit:
Irgendwelche vorschläge bezüglich welches Dateisystem in so einem Fall zu empfehlen wäre?

Eines, welches bei großen Dateien schnell ist. Allerdings sehe ich keine wirklich großen Auswirkungen des Dateisystems. Bei dem geht Zeit vor allem durch das Öffnen von Dateien drauf. Wenn der DB-Server seine Datenbankspeicher aber erst mal gefunden und geöffnet hat, dürfte der Rest nur noch ein Spiel zwischen HD, HD-Cache und DB-Server sein, bei dem HD-Cluster durch den Speicher geschickt werden.

- Sven Rautenberg

[Montgomery C Burns]

Experten meinen: Postgres kann auch schnell sein, aber egal welche Datenbank du wählst: Features kosten Performance.

Im Prinzip hat MySQL mit InnoDB alle Features die ich brauche, stellt sich aber eben die Frage inwiefern MySQL mit InnoDB Sinn macht

Tatsächlich aber dürften Aussagen wie "MySQL ist schneller als Postgres" oder umgekehrt sehr fragwürdig sein.

Deswegen frag ich ja nochmal nach, vor allem weil MySQL kein MVCC hat

Denn es kommt immer konkret auf die tatsächliche Anwendung an, welche Datenbank tatsächlich schneller ist. Du wirst also vermutlich selbst nachmessen müssen, wenn du es wirklich wissen willst.

Das mit dem selbst nachmessen ist so ne Sache, weil man Last so wie sie in der Realität vorkommt, und Jahrelange Erfahrung nicht mit wenigen Tests in ein paar Tagen nicht nachholen kann :\

Und darüber hinaus geht es nicht unbedingt nur um Schnelligkeit, sondern auch um einfache Programmierung. Und bei der Programmierung selbst kann man natürlich auch noch einiges falsch machen und damit tausendmal mehr Zeit verschenken, als mit einer optimierten Datenbank jemals hereingeholt werden kann.

Wenn man etwas verkehrt schreibt kann man es im Nachhinein ja nochmal umändern, ein Wechsel des DBMS ist allerdings etwas komplizierter

Nimm die Datenbank, die du selbst am besten für den Job brauchen kannst.

Das wäre PostgreSQL wegen dem WAL

noch eine Kleinigkeit:
Irgendwelche vorschläge bezüglich welches Dateisystem in so einem Fall zu empfehlen wäre?

Eines, welches bei großen Dateien schnell ist. Allerdings sehe ich keine wirklich großen Auswirkungen des Dateisystems. Bei dem geht Zeit vor allem durch das Öffnen von Dateien drauf. Wenn der DB-Server seine Datenbankspeicher aber erst mal gefunden und geöffnet hat, dürfte der Rest nur noch ein Spiel zwischen HD, HD-Cache und DB-Server sein, bei dem HD-Cluster durch den Speicher geschickt werden.

ok, also bleib ich bei ext3 :)